<div dir="ltr"><div>I did push some significant changes to the low-memory pageout and kill code on August 20 to master.  I have MFC'd that to the release branch today (September 8th) so try building a new kernel.  The fix deals with an edge case that can occur when programs allocate large amounts of memory all at once in excess of cache+free can cause the process killer to prematurely activate.<br><br></div>-Matt<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 12:02 AM, YONETANI Tomokazu <span dir="ltr"><<a href="mailto:y0n3t4n1@gmail.com" target="_blank">y0n3t4n1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The wired pages stay at slightly less than 1.6G, but active and inactive<br>
keep growing until it starts killing some processes.  A silly workaround<br>
could be to run something as<br>
$ perl -e '$x="@";$x=$x x 1048576; $x x 1048576'<br>
so as the active count gets pushed back to something like 50M, which gives<br>
me a few to several days without OOM.<br>
<br>
Best Regards,<br>
YONETANI Tomokazu.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Aug 20, 2015 at 10:01:31AM -0700, Matthew Dillon wrote:<br>
> Continue monitoring the wired pages (from systat -vm 1) on your system with<br>
> the new kernel and see if those tick-up from day to day.<br>
><br>
> -Matt<br>
><br>
> On Tue, Aug 18, 2015 at 3:49 AM, YONETANI Tomokazu <<a href="mailto:y0n3t4n1@gmail.com">y0n3t4n1@gmail.com</a>><br>
> wrote:<br>
><br>
> > Hi,<br>
> ><br>
> > On Sun, Aug 16, 2015 at 05:09:27PM -0700, Matthew Dillon wrote:<br>
> > > There are numerous possibilities.  For example, tmpfs use.  You could<br>
> > check<br>
> > > if the wired page count has become excessive (could be an indication of a<br>
> > > leak).  There was a bug fix made in master related to a memory leak from<br>
> > > locked memory that was fixed on July 12 (a51ba7a69d2c5084f2 in master),<br>
> > you<br>
> > > could try cherry-picking that one into your local tree and see if it<br>
> > helps.<br>
> > ><br>
> > > You'll need to do some more investigation.  The most likely possibility<br>
> > is<br>
> > > tmpfs use.  The wired memory leak is a possibility too but depends on the<br>
> > > system workload.<br>
> ><br>
> > Thank you for the hints and cherry-picking the fix.  I updated the box<br>
> > with the new source this morning, and I'll come back with the new result<br>
> > later.<br>
> ><br>
> > On Sun, Aug 16, 2015 at 10:27:08PM +0800, Nuno Antunes wrote:<br>
> > > Any clue in vmstat -m ?<br>
> ><br>
> > On older kernel, it looked like this; mostly occupied by vfscache,<br>
> > then vnodes and HAMMER-inodes.  so I'm guessing either hammer cleanup,<br>
> > updating the locate db, or git pull may have increased the usage.<br>
> > tmpfs-related numbers were less than 100, on the other hand.<br>
> ><br>
> > $ sed -E 's/^(.{20})(.{7})(.*)$/\2&/' vmstat-m-before  |sort -nr |sed<br>
> > 's/^.......//' |head -n5<br>
> >            vfscache 881481  81743K      0K     764928K   1033104    0     0<br>
> >              vnodes 420508 170832K      0K  134203388K    420508    0     0<br>
> >       HAMMER-inodes 404482 353922K      0K  134203388K    416101    0     0<br>
> >       HAMMER-others   3994    720K      0K     764928K   3754450    0     0<br>
> >               devfs   3803    602K      0K     764928K      4382    0     0<br>
> ><br>
> ><br>
> > Best Regards,<br>
> > YONETANI Tomokazu.<br>
> ><br>
</div></div></blockquote></div><br></div>