This is the bug-tracker for Tor. There is a guide for reporting bugs. Tor is a connection-based low-latency anonymous communication system that protects TCP streams: web browsing, instant messaging, irc, ssh, etc. See https://www.torproject.org/ for more information. To report bugs in the Torbutton Firefox browser extension, select the Torbutton project on this tracker. To report bugs in the Vidalia front-end program, go to http://trac.vidalia-project.net/wiki/ReportingBugs . Thanks for your help!
Task #74 — Servers bloat memory from spawned children
Attached to Project— Tor
Opened by Roger Dingledine (arma) - Tuesday, 25 Jan 2005, 7:20am
Last edited by Roger Dingledine (arma) - Sunday, 30 Jan 2005, 11:57pm
Last edited by Roger Dingledine (arma) - Sunday, 30 Jan 2005, 11:57pm
| Bug Report | |
| Tor server | |
| Closed | |
| No-one | |
| All |
| Medium | |
| Normal | |
| unspecified | |
| 0.1.0.1-rc | |
 |
When we fork, our children inherit the memory from the main Tor process, which can be 50MB or more. Since it's copy-on-write, no problem so far. But when the main Tor process changes the memory, or frees it, then it gets copied so the child has a clean copy. So we end up using 50+MB per child. When we spawn a lot of dnsworkers, this becomes really bad. |
This task depends upon
This task blocks these from closing
Comments (1) | Attachments (0) | Related Tasks (0/0) | Notifications (1) | Reminders (0) | History |
Comment by Nick Mathewson - Friday, 28 Jan 2005, 6:41am
Possible solutions: - use threads on more platforms, like we do on windows. - Free all resources after forking, and hope that our platform knows to brk() down to a smaller size. (We *do* this with out buffers, where most of the memory is.) - Fork a DNS/CPU parent immediately on Tor startup, and have that process fork more DNS/CPU workers as needed.