[or-cvs] r21750: {website} transcribe the RelayMemory faq entry (website/trunk/en)

[Roger Dingledine]

Author: arma
Date: 2010-02-24 05:59:32 +0000 (Wed, 24 Feb 2010)
New Revision: 21750

Modified:
   website/trunk/en/faq.wml
Log:
transcribe the RelayMemory faq entry


Modified: website/trunk/en/faq.wml
===================================================================
--- website/trunk/en/faq.wml	2010-02-24 05:09:24 UTC (rev 21749)
+++ website/trunk/en/faq.wml	2010-02-24 05:59:32 UTC (rev 21750)
@@ -53,6 +53,7 @@
 with abuse issues.</a></li>
 <li><a href="#RelayOrBridge">Should I be a normal relay or bridge
 relay?</a></li>
+<li><a href="#RelayMemory">Why is my Tor relay using so much memory?</a></li>
 <li><a href="#WhyNotNamed">Why is my Tor relay not named?</a></li>
 </ul>
 
@@ -742,7 +743,7 @@
 </dl>
 <p>
 <em>We recommend you do not use these</em> 
--- they are intended for testing and may disappear in future versions. 
+&mdash; they are intended for testing and may disappear in future versions. 
 You get the best security that Tor can provide when you leave the route selection to Tor; 
 overriding the entry / exit nodes can mess up your anonymity in ways we don't understand.
 </p>
@@ -751,7 +752,7 @@
 meaning if the nodes are down or seem slow, Tor will still avoid them. 
 You can make the option mandatory by setting 
 <tt>StrictExitNodes 1</tt> or <tt>StrictEntryNodes 1</tt> 
--- but if you do, your Tor connections will stop working 
+&mdash; but if you do, your Tor connections will stop working 
 if all of the nodes you have specified become unreachable. 
 See the <a href="https://www.torproject.org/documentation.html.en#NeatLinks">Tor status pages</a> 
 for some nodes you might pick.
@@ -899,6 +900,52 @@
 
 <hr />
 
+<a id="RelayMemory"></a>
+<h3><a class="anchor" href="#RelayMemory">Why is my Tor relay using so
+much memory?</a></h3>
+
+<p>There are three reasons for this.
+</p>
+
+<p>The first is that Tor uses threads, so many of the measurements (such
+as the output of top or ps) are inaccurate: they add up all the library
+memory used by each thread, so the total "virtual" memory size will be
+much larger than the actual amount of ram Tor is using. So this isn't
+actually a problem &mdash; looking at the "resident" memory size instead should
+be much more accurate (unless you're swapping a lot). (Note that on <a
+href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#RelayOS">OpenBSD,
+NetBSD, and old FreeBSD</a>, Tor uses a separate process for each thread,
+since threading is broken on these platforms, so in these cases it
+actually <i>is</i> using this much memory!)
+</p>
+
+<p>The second reason is that Tor relays really do use quite a bit of
+memory. Each connection that you hold open has a pair of memory buffers
+that it uses for reading and writing from the network, and when many
+connections are active at once, these buffers might grow quite large. We
+used to have them shrink again immediately once they weren't full, but we
+found that was using too much CPU &mdash; so now they stick around for a short
+amount of time in case we need to use them again soon after. It is not
+unusual for a fast exit relay to use several hundred megabytes of memory
+(i.e.: you need about 768 MB RAM for a 10 MBit connected dedicated exit
+node on Linux with Tor 0.1.2.14).
+</p>
+
+<p>The third reason is that we may have some bugs somewhere. They fall
+into the categories of "things we keep around in memory that are big
+and we should probably get rid of", and "actual memory leaks". We're
+working on these, but we'd love some help. We believe the 0.1.1.x stable
+release was pretty good about this, but 0.1.2.x and 0.2.0.x are so far
+quite bad. Please help!
+</p>
+
+<p>Many linux users have found that in the 0.2.0.x series, <tt>configure
+--enable-openbsd-malloc</tt> fixes many of the linux malloc fragmentation
+bugs.
+</p>
+
+<hr />
+
 <a id="WhyNotNamed"></a>
 <h3><a class="anchor" href="#WhyNotNamed">Why is my Tor relay not named?</a></h3>