id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
227	our automated memory measurements might be measuring the wrong thing	zooko	zooko	"As visible in [http://allmydata.org/tahoe-figleaf-graph/hanford.allmydata.com-tahoe_memstats.html the memory usage graphs], pycryptopp increased the static memory footprint by about 6 MiB when we added it in early November (I think it was November 6, although [wiki:Performance the Performance page] says November 9), and removing pycrypto on 2007-12-03 seems to have had almost no benefit in reducing memory footprint.

This reminds me of the weirdness about the 64-bit version using way more memory than we expected.

Hm.  I think maybe we are erring by using ""VmSize"" (from /proc/*/status) as our proxy for memory usage.  That number is the total size of the virtual address space requested by the process, if I understand correctly.  So for example, mmap'ing a file adds the file's size to your VmSize, although it does not (by itself) use any memory.

Linux kernel hackers seem to be in universal agreement that it is a bad idea to use VmSize for anything:

http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html
http://lwn.net/Articles/230975/

But what's the alternative?  We could read ""smaps"" and see if we can get a better metric out of that.

By the way, if anyone wants to investigate more closely the memory usage, the valgrind tool named massif has been rewritten so maybe it will work this time."	defect	closed	major	eventually	dev-infrastructure	0.7.0	wontfix	memory performance unix	zandr