Re: Solaris 2.6 high pages scans
From: Darren Dunham (ddunham_at_redwood.taos.com)
Date: 05/17/04
- Next message: Sarah Tanembaum: "Sun Freeware - all gnu tools"
- Previous message: Chris Morgan: "Re: XVR-600 vs. XVR-1200 in single-head -OpenGL- mode on an SB2K?"
- In reply to: Mothra: "Solaris 2.6 high pages scans"
- Next in thread: Mothra: "Re: Solaris 2.6 high pages scans"
- Reply: Mothra: "Re: Solaris 2.6 high pages scans"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 17 May 2004 15:32:17 GMT
Mothra <mothra@mothra.com> wrote:
> I have a Solaris 2.6 server (E6500) with 11GB main memory and 11GB swap
> and have recently noticed (using sar -r) that the page scanning daemon
> is consistently running at around 3,200 scans per second. I can't
> account for this (unless I'm missing something) because if I run sar -g,
> I can see the the amount of free memory rarely dips below 230MB and the
> lotsfree param is 180MB.
Do you have priority_paging enabled? If so, it would kick in at
CACHEFREE, which should be LOTSFREEE * 2. It could also be that the
scanner is predicting the amount of memory that will be left in the
future. Is the 'de' field non-zero?
> The only thing I can think of is that sar -g (like vmstat) is vastly
> overestimating the amount of free memory left - I seem to remember that
> before Solaris 8, it does not take into account the size of the segmap
> cache when making this calculation.
> Does this mean that the high page scanning rate does not necessarily
> mean I'm short of memory?
In Solaris 7 and earlier, the disk cache is accumulated from the free
list and is seen by the page scanner as in use. This causes memory
pressure. In other words, all disk I/O in 7 and earlier must be sent
into the free list, which must be enlarged by the page scanner. Because
of this, you cannot (easily) separate the effects of high I/O (normally
good) with insufficient RAM (normally bad). Both cause high scan rates
(which affect performance).
Because of the way the scanner works, the more RAM available, the more
work that it has to do to actually free memory.
Not until 8 is the file cache redone so that it does not induce memory
pressure. On a stable system, I/O causes no page scanning at all. This
can be a huge performance win at high I/O rates. It also means that
page scanner operations are a more decisive indication of insufficient
RAM.
-- Darren Dunham ddunham@taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >
- Next message: Sarah Tanembaum: "Sun Freeware - all gnu tools"
- Previous message: Chris Morgan: "Re: XVR-600 vs. XVR-1200 in single-head -OpenGL- mode on an SB2K?"
- In reply to: Mothra: "Solaris 2.6 high pages scans"
- Next in thread: Mothra: "Re: Solaris 2.6 high pages scans"
- Reply: Mothra: "Re: Solaris 2.6 high pages scans"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|