There is a discrepancy between the web GUI and the API, I think.
The web shows this
API shows this
How are buffer and cache calculated on the web then?
Hi mickey, thanks for the detailed screenshots.
Good news first: nothing is wrong with your device. Both the web page and the API pull their numbers from the same place (psutil, which reads /proc/meminfo), and both report in MiB. The mismatch comes down to what the “buffers/cache” figure means in each spot.
On the web System Info page, the “Buffers / cache” row is a combined figure. We calculate it as total minus used minus free, so it includes the kernel buffers AND the page cache AND shared memory all rolled into one slice. We do it that way so the pie chart adds up cleanly to your total RAM. That is why it tends to be a large number.
The API’s buff field is narrower. It only reports the raw “Buffers” value from the kernel, which is
usually small, and it does not currently include the page cache at all. So you are not looking at the same quantity in the two places, which is why they don’t line up.
In short, the web “Buffers / cache” is roughly buffers + page cache + shared, while the API buff is
just buffers on its own. Both are accurate for what they are measuring.
I agree this is confusing, and the API arguably should expose a cached value (and/or a combined field) so you can reconstruct what the web shows. I’m going to raise this internally so we can make the two consistent, and I’ll link the fix back here once there’s a PR.
Out of interest, what are you using the API memory figures for? That’ll help me make sure whatever we change actually fits your use case.
This is perfect thanks. I assumed it was just the way I was summing the values up but also thought it looked off. Glad to hear you agree haha.
Use case it’s pretty straightforward. In a previous thread here I was having some memory leak issues so I’ve got a Python script that pulls these values on a rolling basis just so I can keep tabs on it to make sure it doesn’t crop back up again.