[tahoe-dev] memory usage experiment

zooko zooko at zooko.com
Wed Jan 16 16:05:35 PST 2008


Folks:

Over the last couple of days I performed a memory usage experiment on  
my Toshiba linux laptop ("zaula") which has only 507 KB of RAM.

I turned off swap, and set sys.vm.overcommit_memory to "2", and  
sys.vm.overcommit_ratio to "90".  (Later I changed it to "99".)

Then I ran a small tahoe grid, with the introducer and one node on a  
different machine, and with a number of storage servers on zaula  
(between 3 and 8).  I used top to examine the total memory free as  
well as the virtual and resident memory usage reported by each process.

I determined that the "total memory free" would drop by between 17  
and 24 MB when I start up a node, which correlates exactly with the  
resident size reported by top for that process, but doesn't correlate  
well with the virtual size.
Then I determined that if I have about 247 MB of memory free, I can  
upload a file (400 MB in size) to this grid (from the client on the  
other machine), but that if I have only 235 MB of memory free, that I  
get MemoryErrors when attempting to do that upload.  This implies  
that it takes about 30 MB per node (in addition to the memory  
required to start the node) in order to use it as a storage server  
for this kind of upload.  This is also exactly correlates with the  
increased resident sizes of the python processes during the upload.

Then I learned that the "total memory free" would increase by between  
39 and 52 MB when I stop each node, which correlates exactly with the  
resident size but not with the virtual size.  This shows that each  
node was at about 22 or 28 MB above start-up weight, after the upload  
was finished.

This correlation of resident size with amount used and amount freed  
is what we expect when there is no swap -- resident size is exactly  
the amount of RAM actually used for that process.  Presumably there  
are some kinds of sharing of memory between processes which could  
cause the reported resident size to be greater than the "amount of  
change of total memory available when starting or stopping the  
process", but we apparently don't do that kind of sharing.

The bottom line is that resident size, not vmsize, is a good measure  
of what we care about (which is mostly "How many active storage  
server nodes can we run on a server with X MB of RAM?") but only if  
there is no swap and perhaps also if overcommit_memory=2.

We should adjust our automated memory usage measurement and graphing  
tools to have no swap, no overcommit, and to measure resident instead  
of virtual size.

My experiments suggest that it takes at most 24 MB to startup a node,  
a peak of at most 54 MB to let it serve as one out of 9 upload  
servers for a single large (400 MB) file upload, and then it rests at  
at most 52 MB after the upload is over.

Regards,

Zooko



More information about the tahoe-dev mailing list