gVisor Memory Accounting

[Sidh Kulkarni]

I want to be able to monitor the memory used by the application vs memory used by the sentry/gofer. Based on the docs it seems like application memory should be backed by the memfd and thus be mapped_file. https://gvisor.dev/docs/architecture_guide/resources/#memory

I'm trying to read the `mapped_file` out of the cgroup memory.stat file but the values don't line up with what I expect. (ie a workload that allocates a 10GB string shows ~1GB mapped_file bytes). Are these values expected, or where can I read more accurate stats from?

[Etienne Perot]

Hello,

runsc has a subcommand called `runsc usage` that should help here. It communicates with the Sentry to get data from its internal memory accounting of what the sandboxed application is using (although this excludes host page cache usage), and it will fstat() the memfd used to back application memory.

You can subtract these figures from the host kernel's cgroup memory data (in which the Sentry and Gofer processes are running) to get the memory usage attributable to the Sentry/Gofer alone.

On Mon, Jul 8, 2024 at 12:13 PM 'Sidh Kulkarni' via gVisor Users [Public] <gvisor...@googlegroups.com> wrote:

I want to be able to monitor the memory used by the application vs memory used by the sentry/gofer. Based on the docs it seems like application memory should be backed by the memfd and thus be mapped_file. https://gvisor.dev/docs/architecture_guide/resources/#memory

I'm trying to read the `mapped_file` out of the cgroup memory.stat file but the values don't line up with what I expect. (ie a workload that allocates a 10GB string shows ~1GB mapped_file bytes). Are these values expected, or where can I read more accurate stats from?

--
You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/d5e126fd-c32e-4325-a7ed-790246522215n%40googlegroups.com.

[Sidh Kulkarni]

I see, thanks for the reply! Is there any way to read that information from the host without using `runsc usage`, or is that intentionally abstracted away?

[Etienne Perot]

Not really; `runsc usage` is the API that `runsc` offers to read this data from the host, similar to how other parts of the OCI runtime interface works. The way `runsc usage` works (at least with the `--fd` flag) also involves a small mmap'd file which exposes internal details of the Sentry to the host, which is an implementation detail that would not be clean to expose outside of `runsc` subcommands.

If you want to read this information programmatically, you can keep running `runsc usage` and parse the JSON output. If that has too much overhead, we'd be happy to accept a patch that adds something like a `--every=<duration>` flag to `runsc usage` that repeatedly {gets usage information, prints it, and sleeps for <duration>} in a loop to avoid the overhead of repeatedly spawning `runsc usage`. Alternatively this data could probably be added to the `runsc metric-server`.

To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/68c2562e-0612-4b66-ad94-c80d43302aadn%40googlegroups.com.