thomasvs - in flumotion-doc: . doc/manual

flumotion-commit at lists.fluendo.com flumotion-commit at lists.fluendo.com
Fri Mar 16 01:37:27 CET 2007


Author: thomasvs
Date: Fri Mar 16 01:37:21 2007
New Revision: 4661

Modified:
   flumotion-doc/ChangeLog
   flumotion-doc/doc/manual/configuration.xml
Log:
	* doc/manual/configuration.xml:
	  Add section on memory limits



Modified: flumotion-doc/ChangeLog
==============================================================================
--- flumotion-doc/ChangeLog	(original)
+++ flumotion-doc/ChangeLog	Fri Mar 16 01:37:21 2007
@@ -1,3 +1,8 @@
+2007-03-16  Thomas Vander Stichele  <thomas at apestaart dot org>
+
+	* doc/manual/configuration.xml:
+	  Add section on memory limits
+
 2007-03-01  Thomas Vander Stichele  <thomas at apestaart dot org>
 
 	* doc/manual/debug.xml:

Modified: flumotion-doc/doc/manual/configuration.xml
==============================================================================
--- flumotion-doc/doc/manual/configuration.xml	(original)
+++ flumotion-doc/doc/manual/configuration.xml	Fri Mar 16 01:37:21 2007
@@ -171,14 +171,14 @@
 Edit <filename>/etc/security/limits.conf</filename> as root.
 At the end of the file, add a line that reads
 <programlisting>
-fluendo    -    nofile    10000
+flumotion    -    nofile    8192
 </programlisting>
 Replace
-<computeroutput>fluendo</computeroutput>
+<computeroutput>flumotion</computeroutput>
 with the username (or group name, prefixed with @)
 that the server will run under.
 Replace
-<computeroutput>10000</computeroutput>
+<computeroutput>8192</computeroutput>
 with the maximum number of open file descriptors you want to allow.
             </para>
           </step>
@@ -187,8 +187,7 @@
             <para>
 Verify that this works by doing the following as root:
 <screen>
-<userinput>su - fluendo</userinput>
-<userinput>ulimit -n</userinput>
+<userinput>su -s /bin/bash -c "ulimit -n" flumotion</userinput>
 </screen>
 Which will show the number of allowed open file descriptors:
 <screen>
@@ -242,9 +241,9 @@
             <para>
 Verify that it works by trying to log in through ssh as the user:
 <screen>
-[fluendo at server fluendo]$ ssh localhost
-fluendo at localhost's password:
-[fluendo at server fluendo]$ ulimit -n
+[flumotion at server flumotion]$ ssh localhost
+flumotion at localhost's password:
+[flumotion at server flumotion]$ ulimit -n
 8192
 </screen>
             </para>
@@ -253,6 +252,79 @@
         </procedure>
       </sect3>
     </sect2>
+
+    <sect2 id="section-configuration-system-memory">
+      <title>
+        <indexterm><primary>memory limit</primary></indexterm>
+        Memory limits
+      </title>
+      <para>
+Software has bugs.  A lot of bugs are harmless or can be worked around.
+Some bugs have the potential to bring down your complete system.
+One class of bugs that GStreamer is vulnerable to is oversized memory
+allocations.  Due to a demuxing error or a programming error, GStreamer tries
+to allocate too much memory.
+      </para>
+      <para>
+If you're lucky, the number is sufficiently small and the buffer can be
+allocated from actual RAM.  If you're slightly less lucky, the number is
+so big that the machine just doesn't have enough RAM and swap to allocate,
+and the program terminates.  (6 hours of CD quality audio is more than 4 GB).
+If you're really unlucky, the number is huge, but inbetween your available
+RAM and your available RAM + swap.  In that case, the allocation will succeed,
+and this will drive your machine into a huge swap storm as soon as the
+buffer gets written to. 
+      </para>
+      <para>
+The same file that controls limits on number of file descriptors can also
+control the amount of memory a process of a user is allowed to take.
+The current virtual memory limit for your process can be inspected using
+<userinput>ulimit -v</userinput> in
+<command>bash(1)</command>.
+      </para>
+      <para>
+Most Linux distributions have this set to unlimited by default.
+      </para>
+      <sect3 id="section-configuration-system-memory-pam">
+        <title>Linux systems using PAM</title>
+        <para>
+On systems that use PAM, this limit can be changed:
+        </para>
+        <procedure>
+          <step>
+            <para>
+Edit <filename>/etc/security/limits.conf</filename> as root.
+At the end of the file, add a line that reads
+<programlisting>
+flumotion        -    as              512000
+</programlisting>
+Replace
+<computeroutput>flumotion</computeroutput>
+with the username (or group name, prefixed with @)
+that the server will run under.
+Replace
+<computeroutput>512000</computeroutput>
+with the maximum number of KB that you want to allow.
+            </para>
+          </step>
+
+          <step>
+            <para>
+Verify that this works by doing the following as root:
+<screen>
+<userinput>su -s /bin/bash -c "ulimit -v" flumotion</userinput>
+</screen>
+Which will show the number of KB that a process is allowed to allocate:
+<screen>
+<computeroutput>512000</computeroutput>
+</screen>
+            </para>
+          </step>
+
+        </procedure>
+      </sect3>
+    </sect2>
+
     <sect2 id="section-port-usage">
       <title>Device permissions needed by Flumotion</title>
       <para>


More information about the flumotion-commit mailing list