Re: Need help analyzing (kernel?) memory usage and reclaiming RAM (Debian Stretch)
On Wed, Apr 17, 2019 at 01:14:36AM +0200, Peter Wiersig wrote:
> Reco <recoverym4n@enotuniq.net> writes:
>
> Hi Reco,
>
> > On Tue, Apr 16, 2019 at 04:39:32PM +0200, Peter Wiersig wrote:
> >> VSZ is the Virtual Memory Size. (...),
> >>including memory that is swapped out,
> >> memory that is allocated, but not used,
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> and memory that is from shared libraries.""
> >
> > Given this:
> >
> > == cut ==
> >
> > One can expect the process to "consume" 4Gb of VSZ, and about 700kb of
> > RSS.
> >
> > Do you really suggest to treat all this VSZ as a "used memory"? A hint -
> > compile the sample, run it a hundred times.
>
> No, but that is all in the explanation above albeit tersely. I
> underlined the part which comes into play with your example code.
That was the whole point. If it's allocated, but ain't used - one should
not account it.
> If Martin wants to find out what's using his memory during timespans
> with degraded performance, it will not be helpful to list the processes
> and sort by thenot swapped amount.
To quote the original e-mail:
root@rad-m2m-srv02:~# free -thwl
total used free shared buffers cache available
Mem: 987M 910M 59M 0B 704K 16M 13M
Low: 987M 927M 59M
High: 0B 0B 0B
Swap: 2,0G 345M 1,7G
Total: 3,0G 1,2G 1,7G
root@rad-m2m-srv02:~# smem -uktr
User Count Swap USS PSS RSS
root 39 332.8M 10.4M 12.4M 44.7M
msch 6 7.0M 0 607.0K 8.3M
_chrony 1 360.0K 4.0K 20.0K 572.0K
messagebus 1 580.0K 4.0K 17.0K 480.0K
postfix 2 1.6M 0 13.0K 568.0K
daemon 1 208.0K 4.0K 6.0K 72.0K
---------------------------------------------------
50 342.5M 10.4M 13.0M 54.7M
A host has 1Gb of RAM and 3Gb swap.
Both "free" and "/proc/meminfo" show that there's no free memory left.
"smem" output shows us that this memory ain't used by userspace.
The question was - where all this memory has gone?
> If the system is thrashing due to swapping in and out, I always look
> at the VSZ values to find out where I should direct my attention to.
Thanks for sharing. In this particular case, swapping is a consequence,
not a root cause.
But, just in case, how exactly your method is superior to "top -o SWAP"?
Reco
Reply to: