On 2014-12-15 19:43, Nick Mathewson wrote: > On Wed, Dec 10, 2014 at 2:31 AM, Roger Dingledine <a...@mit.edu> wrote: >> On Sun, Dec 07, 2014 at 01:43:46PM +0100, Logforme wrote: >>> To me it looks like an attacker that ramped up over a 6 hour period and >>> then stopped building new circuits. Since the tor process still uses all >>> available memory (more than 24 hours later) I guess the attacker still >>> holds some circuits open. >> Careful with your conclusion there -- because of memory fragmentation, the >> process can still hold the memory even when Tor has freed the memory. That >> happens because some part of the memory page is in use and some is freed, >> but since not all of it is freed the allocator doesn't take it back. >> >> Some quick searches point to >> https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_native_memory_fragmentation_and_process_size_growth >> as what looks like a nice summary of the issue. >> >> --Roger > If this *is* memory fragmentation, one possible reason why it would > have started appearing recently might be that we turned the freelist > code off by default in 0.2.5, on the theory that it should be safer to > do that than not. > > https://trac.torproject.org/projects/tor/ticket/11476 has more > background here. I don't think it's the likeliest explanation, but > it's worth examining. > > Are the people experiencing this issue using similar allocators? >
I don't build Tor myself, I use the latest debian package: 0.2.5.10-1~d70. No idea how that is built. I have not restarted Tor so it is still hogging all ram + swap (relay works fine so no reason to restart). If there is anything I can run to get more information about what has happened (code dump maybe?), I'm happy to do so. _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
