Scott Bennett wrote:
>>
>> anonymizer2:~# hugeadm --pool-list
>> Size Minimum Current Maximum Default
>> 2097152 100 319 1000 *
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
>> 21716 debian-t 20 0 2075m 1.1g 25m R 95.2 29.4 2020:29 0 tor
> ^^^^
> That CPU usage looks pretty high to me, but I still don't know what
> you were accustomed to seeing tor use before, so is it higher so far?
> Lower?
cpu usage is always near 100% as long as being swamped by new circuits.
Cpu load seems to rather depend on the number of established tcp
connections than on the provided bandwidth. With openbsd-malloc resident
process size usually has been far below 1gb even after one or two weeks.
Process now with glibc malloc is still eating up memory and I'm sure it
will crash within the next days. Total memory is 4 gb:
anonymizer2:~# hugeadm --pool-list
Size Minimum Current Maximum Default
2097152 100 344 1000 *
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
21716 debian-t 20 0 2702m 1.6g 26m R 88.5 41.8 3383:56 1 tor
> Okay. But, again, I'd still like to know whether the hugepages are
> helping tor's CPU load or hurting it, and I would need some historical
> clues, even if just estimates, to know the answer to that.
in any case it doesn't hurt with respect to cpu load. I'm lacking
programming skills to make hugepages work with OpenBSD_malloc_Linux
coming with the tor sources. So hugepages might reduce load be roughly
about 20% with the side effect of getting a memory leak from glibc malloc.
@tor developers: Is there any good news for better scalability regarding
multiple cores?
regards Olaf
***********************************************************************
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
