On Sat, 19 Aug 2017 15:38:15 -0700 Cy Schubert <cy.schub...@komquats.com> wrote:
> In message <20170819213149.GA34140@raichu>, Mark Johnston writes: > > On Sat, Aug 19, 2017 at 02:24:19PM -0700, Cy Schubert wrote: > > > In message <201708192100.v7jl0vfk003...@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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
