Re: (FWD) Problems with Tor in user-mode-linux

[Roger Dingledine <arma@xxxxxxx>]

On Sat, Jan 22, 2005 at 01:27:27PM +0100, Bernhard Wiedemann wrote:
> This is running as server (bmwanon), but not serving directory.
> I retried it without UML on a SuSE-2.4.21 kernel.
> After 60 hours there were 11 processes using 140MB RAM and additional 
> 33MB of swap, with 258 connections and transferring about 350kb/s
> 
> the first (parent) process using 56220kb alone.

Using 56 megs of memory for Tor is not un-heard of, for a very active
Tor server. I typically find leaks by using valgrind periodically,
but it's crazy slow so it doesn't work well for long-running servers.
Do you know any run-time leak-checkers that work and aren't too slow?

As for the other processes beside the first one, I believe all of those
are using roughly zero memory. When linux does a fork, all of the memory
pages are inherited in a copy-on-write fashion, and Tor doesn't change
most of them. So I think the other processes are sharing the same memory.

(Do you have reason to believe otherwise? We might have a bug there.)

> Unluckily I dont know enough about why and when tor forks and processes 
> stop... but for the curious I recorded some outputs of

Tor forks a cpuworker when it starts (well, one cpuworker per cpu you
have configured in 'NumCpus', defaulting to 1), and the other workers
are dnsworkers. They just do a very simple loop in dnsworker_main() in
src/or/dns.c, which just reads stuff off their socket, calls gethostbyname
on it, and writes back the answer. We fork 3 dnsworkers to start, and we
make a new one when the others are busy, and if there are too many idle
(more than 10) we kill off the excess ones.

> Giorgos Pallas problem seems to be related to this.

Yeah. Hm. Maybe we should put out a bounty on this one. :) Let me know
if you encounter any more hints.

Thanks,
--Roger