I have added support to wspy for the –memstats option.

This option periodically samples /proc/meminfo and then dumps a *.csv file with these values. So far, I’ve chosen the following fields to sample:

MemTotal
MemFree
Buffers
Cached
Active(anon)
Inactive(anon)
Active(file)
Inactive(file)
SwapTotal
SwapFree
Dirty
Writeback
AnonPages
Mapped
Shmem
Slab
CommitLimit
Committed_AS

While some of these like MemTotal shouldn’t change, it is easier to just sample and then dump into the CSV file with everything else than to special case them.

I ran the tests below on a run of OpenFOAM motorbike with 4 and 8 threads. The latter case has a significantly higher amount of system time and hence I’m looking to see if this might be reflected in memory graphs

Running snappyHexMesh in parallel on /home/mev/openfoam-motorbike/bench_template/run_4 using 4 processes

real	14m41.509s
user	58m22.617s
sys	0m12.798s

Running snappyHexMesh in parallel on /home/mev/openfoam-motorbike/bench_template/run_8 using 8 processes

real	15m24.120s
user	85m54.951s
sys	20m29.949s

An example of each of the six plots created is shown below. Still need to see how various workloads come out to calibrate what is most useful here.

This first plot is a simple plot of the free memory (MemFree).

This next plot brings in file buffers and caches (contributors to free memory) and traditional fields for the “free” command output.

One can ask for active(anon) and Inactive(anon) for normal pages. For now an inverse of the free values.

Swap space is somewhat boring, both because a small amount is configured and there is enough memory that none is used.

The CommitLimit and Committed_AS fields are interesting, particularly to understand what might be going on as those limits are being exceeded. Is this contributing to the larger amount of system time?

The scale will be important to calibrate this one, but shows the dirty pages as they are being written out to disk. I would expect this to be a bigger issue if the disk falls behind.