| |||||||||||||
|
| |||||||||||||
Our bloat problemOur bloat problemPosted Aug 7, 2005 21:59 UTC (Sun) by hp (subscriber, #5220)In reply to: Our bloat problem by oak Parent article: Our bloat problem
Of course you can figure this out painstakingly. What you can't do though is get all that info aggregated for 1) each process and 2) a current snapshot of all processes, in an easy way.
Aggregating this stuff into a snapshot of the whole system at a point in time would let you really point fingers in terms of bloat and figure out where to concentrate efforts.
It's not easy enough now, which is why people just use "top" and its misleading numbers.
Even better of course would be to take multiple snapshots over time allowing observation of what happens during specific operations such as log in, load a web page, click on the panel menu, etc.
A tool like this would probably be pretty handy for keeping an eye on production servers, as well.
(Log in to post comments)
Our bloat problem Posted Aug 18, 2005 20:10 UTC (Thu) by oak (guest, #2786) [Link] > Aggregating this stuff into a snapshot of the whole system at a point in> time would let you really point fingers in terms of bloat and figure out > where to concentrate efforts. If the patch Robert mentioned is the same which results I have seen (post-processed), you can already get that information from Linux kernel by patching it a bit. The results I saw included machine wide statistics and process specific stats of how many pages reserved for the process were ro/rw/dirty, how much each linked library accounts for the process memory usage (relocation table sizes etc., not how much each library allocates heap for the process[1]). This is quite useful for system overview, whereas valgrind/Massif/XResTop/top tell enough of individual applications. [1] that you can get just with a simple malloc wrapper that gets stack traces for each alloc and some data post-processing heuristics to decided which item in the stack trace to assign the guilt. The hard part is actually the post-processing, deciding who in e.g. the allocation chain of App->GtkLabel->Pango->Xft2->FontConfig->Freetype should be blamed for the total of the allocations done at any point in the chain as you don't know whether the reason for the total allocations is valid or not without looking at the code... Best would be an interactive allocation browser similar to Kcachegrind with which one could view also the source along with accumulated allocation percentages.
|
|
||||||||||||