On Thu, May 11, 2006 at 09:21:05PM +0200, Joerg Maschtaler wrote: > Hi, > > if it possible to add an option which allows to shrink memory buffers > immediatly if they are not full? [1] I don't think you would want that; the CPU usage would be *insanely* high. Every time you transmitted any information at all, you'd need to shrink the buffer, and then immediately re-grow the buffer the buffer when you had more data to transmit. Right now, Tor shrinks buffers ever 60 seconds, down to the next largest power of two above the largest amount of the buffer at any time in the last 60 seconds. A 60-second lag here probably does no harm memory-wise, but the power-of-two thing will, on average, make 25% of your buffer space unused. The only thing that would actually help trade cpu for RAM here won't be a more frequent shrinking; instead, we'd have to switch off the power-of-two buffers implementation. But if we're going to do *that*, we may as well move to an mbuf/skbuff-style implementation, and get improved RAM usage and improved CPU usage at the same time. (That approach will make our SSL frame-size uniformity code a little trickier, but I think we can handle that.) > I run an Tor server on a virtual server in which the amount of RAM is > the bottleneck of this system. > Since ~ 3 weeks i measure the "resident" memory allocation and the > corresponding traffic of the Tor server and the thing i realize is that > the allocation only shrinks if i shutdown (and restart) the Tor > server. [2] Hm. I should look at a breakdown of buffer size; I'll try to do that later tonight, once I've had my server running for a bit. It's probably important to know whether our real problem is wedged connections whose buffers get impossibly large, or buffers whose capacities are larger than they have to be. yrs, -- Nick Mathewson
Attachment:
pgpWvl1u5KsHV.pgp
Description: PGP signature