<div dir="ltr">Hmm.  That's definitely high for a system with 8G of ram.  Diagnosing this is a bit messy.<div><br></div><div>The first thing to do is to look at the buffer cache space used in systat -vm 1.  It's the 'buf' element.  on an 8GB machine it should be lower than 1.5 GB.</div><div><br></div><div>The next thing you can do is look at the summary memory total at the end of the 'vmstat -m' output.  However, that number does not accurately convey kernel memory use because it doesn't include the kernel's caching of free memory.</div><div><br></div><div>After that you can compile the kmapinfo debug utility:</div><div><br></div><div>cd /usr/src/test/debug</div><div>make kmapinfo</div><div><br></div><div>And then run it as '/tmp/kmapinfo'.   This is for low level debugging and interpreting the output is not easy because many of the memory zones reported are virtual allocations and not physical allocations.  However, you can determine the actual amount of memory allocated by the kernel by observing the 'KMALLOC' line in the summary at the end.</div><div><br></div><div>There are a few other elements at the end of the kmapinfo output that are useful.  PVENTRY and PML4 are useful.  Note that SYSMAP and ZALLOC are not because those are mostly virtual reservations.</div><div><br></div><div>See how all of that adds up for you.   Buffer cache memory from the systat -vm 1, then KMALLOC + PVENTRY + PML4 from kmapinfo.  If some of those are blown out beyond reason it will give me a place to start looking.</div><div><br></div><div>-Matt</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 17, 2019 at 4:22 AM Daniel Bilik <<a href="mailto:ddb@neosystem.org">ddb@neosystem.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi.<br>
<br>
After recent update (from 5.5.0.56.g5c117 to 5.5.0.129.g9ea75) my system<br>
regularly runs out of swap space during daily periodic(8) (which is<br>
shifted to 1pm as the system doesn't run 24/7). Sometimes the system runs<br>
out of memory and kills processes, most often chrome, but X also got hit<br>
at least one time.<br>
<br>
When inspecting the system during this unpleasant situation, I've noticed<br>
quite high numbers under "wired memory" in top(1). It's a little above<br>
1000M when the system boots and desktop is launched, it gets to around<br>
3500M after cca 5 hours of "normal" desktop usage, but I've seen more then<br>
6000M after periodic(8). What's remarkable, when "wired" gets that high, it<br>
doesn't drop significantly even after periodic(8) is done.<br>
<br>
The system has 8G of memory, and it hasn't been utilizing it's 512M of swap<br>
such heavily before the mentioned update. In fact, it's been barely touching<br>
the swap.<br>
<br>
Is there a way one can inspect the content of "wired memory" (and<br>
potentially identify most hungry consumer)? (I know it's _wired_ but) is<br>
there a way a system can be forced to release some of this memory?<br>
<br>
Thank you.<br>
<br>
--<br>
                                                Daniel<br>
</blockquote></div>