[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Tor takes too much RAM
On Sat, 21 Jul 2007 01:30:46 -0700 Ben Wilhelm <zorba-tor@xxxxxxxxxxxxx>
wrote:
>Scott Bennett wrote:
>> Does LINUX have vmstat(8)? Or swapinfo(8)/pstat(8)? In any case,
>> it must have ps(1), which should give some sort of breakdown of what tor
>> is using.
>
>It does have vmstat. I should point out, however, that vmstat shows
>pretty much the exact same stuff that free does, only with less math
>done for you, a few important missing numbers, and a few added numbers
>which aren't really important in this case.
>
>(This is a different server, which is why it has more RAM)
>$ vmstat && free
>procs -----------memory---------- ---swap-- -----io---- -system--
>----cpu----
> r b swpd free buff cache si so bi bo in cs us sy
>id wa
> 0 0 2716 27472 143508 20876 1 1 1 3 3 3 3 12
^ ^
*Any* swapping is bad, definitely. The FreeBSD vmstat doesn't show
swapping, but it does show paging:
[hellas] 136 % vmstat
procs memory page disk faults cpu
r b w avm fre flt re pi po fr sr ad0 in sy cs us sy id
3 0 0 347452 320948 316 0 0 0 305 32 0 449 2026 1591 55 15 31
>77 7
> total used free shared buffers cached
>Mem: 385840 358368 27472 0 143508 20876
>-/+ buffers/cache: 193984 191856
>Swap: 369452 2716 366736
>
>Tor is currently disabled on that first server because I run other
>things on it that I'd rather stayed functioning :) My relatively small
>90mb usage is pretty meaningless compared to the 1.5gb usage of others,
Not so. A memory leak is a bad thing. It is likely to affect smaller
systems, like yours, sooner than larger systems, like Olaf's. Some programs
suffer from another problem that causes similar symptoms, namely, poor
garbage collection algorithms. The result is similar in that one ends up with
lots of memory allocated, very little of which is in use. What is in use ends
up scattered throughout the allocated memory, leading to access patterns that
are pathological in a virtual memory system. I don't know which might be the
problem in this case.
>though, and on my other computer it's using 136m RES according to top.
So 136 MB is probably a good approximation to the working set size, given
the page frame contention problem you've described.
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>24579 zorba 15 0 148m 136m 4724 S 5.3 36.3 278:10.78 tor
>
>> So how was your system affected? Was there heavy paging going on?
>> Or worse, swapping? Those are what one would expect when there is a lot
>> of contention for the available page frames.
>
>It's not a local system, so I didn't have an easy way of seeing a hard
>drive indicator. I can tell you that I was having literally
>thirty-second-long delays just trying to use the command line, which
>went away when I killed tor. So I suspect it was swapping like a mofo.
Well, a "vmstat 2", for example would print out a fresh line every two
seconds, which would show you the swapping activity, if any. Not sure how you
would display paging activity. FreeBSD also has systat(1), which has a number
of updating displays from which to choose, including its own idea of vmstat,
which shows all sorts of memory, paging, and swapping statistics, as well is
interrupt counts, namei() activity, and some baskic CPU and I/O statistics.
It's really invaluable for keeping track of what is going on inside a system.
>
>Version 0.1.2.14 - I'm just updating with Debian (unstable, I suspect.)
>
Very strange. Let us know how 0.1.2.15 acts.
Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet: bennett at cs.niu.edu *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good *
* objection to the introduction of that bane of all free governments *
* -- a standing army." *
* -- Gov. John Hancock, New York Journal, 28 January 1790 *
**********************************************************************