Re: swapfile query

On Sat, 19 Aug 2017 15:38:15 -0700
Cy Schubert <Cy.Schubert_at_komquats.com> wrote:

> In message <20170819213149.GA34140_at_raichu>, Mark Johnston writes:
> > On Sat, Aug 19, 2017 at 02:24:19PM -0700, Cy Schubert wrote:  
> > > In message <201708192100.v7JL0vFk003935_at_slippy.cwsent.com>, Cy Schubert 
> > > writes:
> > >   
> > > > (On my -CURRENT laptop I see a scan rate in the hundreds on a totally idl  
> > e   
> > > > laptop and in the teens of my idle firewall. IMO this doesn't seem right,  
> >    
> > > > at least not compared to previous releases of FreeBSD or from the days wh  
> > en   
> > > > I worked on Solaris. You shouldn't see a scan rate on an idle system.)  
> > > 
> > > It appears that on an idle system with many pages in use, i.e. a laptop 
> > > running X and not really doing anything else, pages are scanned though the 
> > > system is idle. This is likely an artifact of r308474.  
> > 
> > It's an intentional consequence of r254304. The page daemon performs a
> > slow and steady scan of the queue of active pages and will gradually
> > move unreferenced pages to the inactive queue.  
> 
> This is certainly better.
> 
> It's probably good idea to remove scan rate from vmstat output as it's not 
> meaningful in the traditional sense any more. For example on a 
> traditionally scanning VM system (Solaris or z/OS) the number of pages 
> scanned per second (or unreferenced interval count -- the inverse of the 
> scan rate) is the first indication that you need to look at your vm 
> subsystem. As of r254304 rate cannot be used used as a metric any more 
> except when one sees it deviate wildly from previous observations. (Not 
> that I'm complaining.)
> 
> See below:
> 
> procs  memory       page                    disks     faults         cpu
> r b w  avm   fre   flt  re  pi  po    fr   sr ad0 da0   in    sy    cs us 
> sy id
> 0 0 0 3.9G  292M     4   0   0   0   193  125   0   0  434   773   588  0  
> 0 100
> 1 0 0 3.9G  292M    55   0   0   0   181  123  22   0  460  2467  1402  0  
> 1 99
> 0 0 0 3.9G  290M   969   0   0   1   316  124   1   0  490 12571  4004  3  
> 1 95
> 0 0 0 3.9G  289M   261   0   0   0   160  124  21   0  505 20426  7751  2  
> 2 97
> 0 0 0 1.5G  755M  3481   0   1   1 60951   74  18   0  463 19918  6576 13  
> 4 82
> 
> At this point I closed firefox. Pages are freed and scan rate decreases. We 
> now have a new normal.
> 
> 0 0 0 1.5G  752M    10   0   0   0     0   24   1   0  409   595   365  0  
> 0 100
> 0 0 0 1.5G  754M     1   0   0   0   403   23  49   0  478   609  1321  0  
> 1 99
> 0 0 0 1.5G  754M    19   0   0   0   171   24   0   0  402   655   382  0  
> 0 100
> 0 0 0 1.5G  754M     0   0   0   0   170   24   0   0  423   568   463  0  
> 0 100
> 0 0 0 1.5G  754M     0   0   0   0   174   12   0   0  403   627   359  0  
> 0 100
> 0 0 0 1.5G  754M     0   0   0   0   172   35   4   0  425   625   474  0  
> 0 100
> 0 0 0 1.5G  754M     1   0   0   0   170   24   4   0  416   651   398  0  
> 0 100
> 0 0 0 1.5G  754M     0   0   0   0   163   23   1   0  426   655   490  0  
> 0 100
> 0 0 0 1.5G  754M     0   0   0   0   176   23   0   0  429   663   384  0  
> 0 100
> 0 0 0 1.5G  754M     0   0   0   0   163   23   0   0  445   661   482  0  
> 0 100
> 
> Should we consider removing scan rate from vmstat output? It doesn't really 
> mean anything in relation to tuning any more.
> 

Depends.  I have vm.pageout_update_period=0 in /etc/sysctl.conf
and scan rate (sr) really does reflect the true scan rate.  On
my system sr is 0 while the system is idle.

As an aside, my system (8GB RAM) hardly ever swaps, even under
heavy memory load.

Perhaps the output of sr could be somehow scaled based on the setting
of the sysctl?  Just a thought, I haven't looked at the source.

-- 
Gary Jennejohn