tor-webwml.git

@@ -53,6 +53,7 @@ have a virus or spyware?</a></li>

 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 @@ or specified on the command line:

 </dl>

 <p>

 <em>We recommend you do not use these</em> 

+— 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 @@ The <tt>EntryNodes</tt> and <tt>ExitNodes</tt> config options are treated as a r

 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 

 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 @@ a little bit of bandwidth, then flip a coin. Thanks for volunteering!

 <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 — 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 — 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>