darren wrote: > > Thanks. > > > > My concern is more with whether top can accurately keep track of the > actual memory used by my app. I read somewhere that it sometimes > tracks what the memory manager reserves for that process instead of > the actual memory used. In such cases, the memory used field often > reflects a value higher than what is actually consumed by your app. Is > there any truth to this? >
Yes. You need to understand the difference between RES ans VIRT. VIRT (sometimes known as VSZ - virtual size) shows the entire virtual memory size that is allocated to the process - it may not actually be used and in most circumstances isn't - in Linux, memory can be allocated by a user process but if the pages are not touched, then the kernel does not actually map real physical memory pages. The GLIBC malloc implementation always keeps a lot of unallocated virtual space in reserve to speed up allocation (so that mmap() or brk() don't need to be called for each allocation). RES (sometimes known as RSS - resident set size) shows the amount of memory that is really used at any one point in time - this is usually the important value to look at. It is all complicated by processes that fork and share pages. If your process forks, then some of the RSS pages will be shared between the parent and the forked child processes. So adding up the RSS of forked processes doesn't give you a true indication of the memory usage - i.e. shared pages will be double counted. Have you considered using valgrind? valgrind is similar to commercial tools like Rational 'Purify'. valgrind has become popular enough that the verb 'valgrinding' your code has emerged into common existence amongst open source developers. I could not live without this tool when doing C or C++ development. It is no good for running in production (slows down execution a lot) but may be useful in your testing phase to 'valgrind' your code for a few days. It will give you much more accurate information about the size of allocations from the various parts of your code, in addition to detecting memory leaks and other allocation or memory access errors (reading from free'd memory, double free, reading from unallocated memory,)... ~mc _______________________________________________ Slugnet mailing list [email protected] http://wiki.lugs.org.sg/LugsMailingListFaq http://www.lugs.org.sg/mailman/listinfo/slugnet
