| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Our bloat problem
Our bloat problem
Posted 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 (subscriber, #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.