From: Dan Schatzberg <schatzberg.dan@gmail.com>
To: David Rientjes <rientjes@google.com>
Cc: Michal Hocko <mhocko@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>,
Balbir Singh <bsingharora@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-mm@kvack.org
Subject: Re: Tools for explaining memory mappings/usage/pressure
Date: Mon, 8 Jul 2024 09:50:49 -0400 [thread overview]
Message-ID: <ZovuuRqC2Plwfg2H@dschatzberg-fedora-PF3DHTBV> (raw)
In-Reply-To: <29c27dab-a590-5df2-c840-279bf9dff090@google.com>
On Sat, Jul 06, 2024 at 01:55:11PM -0700, David Rientjes wrote:
> Rather than hacky scripts that collect things like vmstat, memory.stat,
> buddyinfo, etc, at regular intervals, it would be preferable to hand off
> something more complete. Idea is an open source tool that can be run in
> the background to collect metrics for the system, NUMA nodes, and memcg
> hierarchies, as well as potentially from subsystems in the kernel like
> delay accounting. IOW, I want to be able to say "install ${tool} and send
> over the log file."
>
> Are thre any open source tools that do a good job of this today that I can
> latch onto? If not, sounds like I'll be writing one from scratch. Let me
> know if there's interest in this as well.
>
> Thanks!
>
Hi David,
At meta we have built and deployed Below[1] for this purpose. It's a
tool similar to `top` or others, but can record system state
periodically and allow for replaying. We run this on our production
fleet, periodically recording system state to the local disk. When we
need to debug a machine at a point in the past, we can log in and
replay the state. This uses a TUI (see the link for a demo) to make
navigating the data more natural.
I'm aware of a few other organizations who have also deployed Below,
but tend to run it more in the manner you suggest - have it record
data but then use the snapshot command to export the state (e.g. as if
it was a log file) that can then be viewed off-host. Some
organizations eschew the TUI altogether and export the data to
Prometheus/Grafana.
I'll caution though that having the data is one thing, being able to
interpret it is entirely different. While we try and put the most
useful and easily-understood metrics front-and-center in the TUI,
debugging an issue like you describe would probably require some
domain-expertise.
[1] https://github.com/facebookincubator/below
next prev parent reply other threads:[~2024-07-08 13:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-06 20:55 David Rientjes
2024-07-07 15:44 ` SeongJae Park
2024-07-08 13:50 ` Dan Schatzberg [this message]
2024-07-21 23:05 ` David Rientjes
2024-07-22 22:15 ` Dan Schatzberg
2024-07-22 9:05 ` Vlastimil Babka (SUSE)
2024-07-22 21:57 ` David Rientjes
2024-12-30 8:15 ` Raghavendra K T
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZovuuRqC2Plwfg2H@dschatzberg-fedora-PF3DHTBV \
--to=schatzberg.dan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bsingharora@gmail.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=peterz@infradead.org \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox