Re: systemd memory usage
On Fri, 2011-06-10 at 15:55 -0400, Adam Jackson wrote: > On 6/10/11 9:07 AM, Denys Vlasenko wrote: > > > At the very least, I would like to see its memory consumption > > to go down substantially. > > Let's try to turn this into something constructive. I'll start with > David Malcolm's rather nifty, if unpolished, 'heap' plugin for gdb: > > https://fedorahosted.org/gdb-heap/wiki Woot! Fame at last! :) Various comments inline below... > Simply running the 'heap' command tells me that systemd is using 21M of > malloc'd data, and that about 11M of it is entirely within allocations > that are all 2064 bytes apiece. Everything else, in comparison, is > pretty insignificant: > > Domain KindDetailCount Allocated size > - --- --- -- > uncategorized 2064 bytes5,370 11,083,680 [...snip...] "uncategorized" means that gdb-heap doesn't know how to deal with bytes in question. If it's from a library, and you figure out what the above is, we could add a categorizer for it. > C string data 12,964 630,672 ... > TOTAL 127,119 21,934,576 > That's a pretty unusual size, 2064 bytes. That works out to 2048 + 16, > though, which are much more natural-sounding numbers. A quick > experiment with a demo program (allocate a 32-byte struct and then call > pause()) shows that the 16 is actually the overhead from malloc itself: > > Domain KindDetail Count Allocated size > - - -- > uncategorized48 bytes 1 48 > TOTAL 1 48 Yes: IIRC, the "size" is actually the offset to the next chunk. glibc's malloc allocates two size_t fields at the top of each chunk. > So now the problem is simply to find a 2048-sized allocation within > systemd, or one of its libraries. Anyone interested in a homework problem? gdb-heap has a search/querying feature: If you run : (gdb) heap select size == 2048 it will try to show addresses and partial hexdumps of the relevant buffers. (I _think_ so, but you might need 2064 instead). The addresses it reports are those of where the allocation begins (as seen by the program) i.e. it does the offset for you. Given an address, there's also a (gdb) hexdump ADDR command, which you can use to scroll through memory. If you stare at the hexdump you can sometimes figure out what the data is. If you think that an allocation is of some given type, you can also try casting the data, e.g.: (gdb) print *(some_struct*)ADDR and see if looks meaningful. Hope this is helpful. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd memory usage
On Fri, 10 Jun 2011 15:55:14 -0400 Adam Jackson wrote: > Domain KindDetailCount Allocated size > - --- --- -- > uncategorized 2064 bytes5,370 11,083,680 Probably the SELinux file labelling database, all the regexes. Related to https://bugzilla.redhat.com/show_bug.cgi?id=709014#c2 Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd memory usage
On 6/10/11 9:07 AM, Denys Vlasenko wrote: > At the very least, I would like to see its memory consumption > to go down substantially. Let's try to turn this into something constructive. I'll start with David Malcolm's rather nifty, if unpolished, 'heap' plugin for gdb: https://fedorahosted.org/gdb-heap/wiki Simply running the 'heap' command tells me that systemd is using 21M of malloc'd data, and that about 11M of it is entirely within allocations that are all 2064 bytes apiece. Everything else, in comparison, is pretty insignificant: Domain KindDetailCount Allocated size - --- --- -- uncategorized 2064 bytes5,370 11,083,680 uncategorized 32 bytes 70,788 2,265,216 uncategorized 1072 bytes1,503 1,611,216 uncategorized 96 bytes 11,420 1,096,320 C string data 12,964 630,672 uncategorized 528 bytes1,067 563,376 uncategorized 528384 bytes1 528,384 uncategorized 272 bytes1,894 515,168 uncategorized 64 bytes6,342 405,888 uncategorized 48 bytes8,446 405,408 /* a bunch of stuff in between omitted */ uncategorized 2272 bytes1 2,272 uncategorized 1568 bytes1 1,568 uncategorized 800 bytes1 800 TOTAL 127,119 21,934,576 That's a pretty unusual size, 2064 bytes. That works out to 2048 + 16, though, which are much more natural-sounding numbers. A quick experiment with a demo program (allocate a 32-byte struct and then call pause()) shows that the 16 is actually the overhead from malloc itself: Domain KindDetail Count Allocated size - - -- uncategorized48 bytes 1 48 TOTAL 1 48 So now the problem is simply to find a 2048-sized allocation within systemd, or one of its libraries. Anyone interested in a homework problem? - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
