"free" in vmstat is not free memory page scanner sees, is it?

"free" in vmstat is not free memory page scanner sees, is it?

Post by Yong Huan » Wed, 07 Mar 2001 02:04:51



Recently there was a discussion on an Oracle database mailing list regarding
how to measure memory pressure or shortage based on vmstat output. Some say
sr (scan rate) is the only accurate metric (if priority paging is not
enabled). Some say po (paging out) and sr together. I understand that sr is
determined by how much free memory is available relative to kernel tunables
LOTSFREE, DESFREE, MINFREE etc., which determines how often page scanner
daemon runs. My question is, if you use sr as the metric for memory
pressure, why not directly look at the free memory available? But I think
the problem is that the free memory the page scanner sees is not the number
under the "free" column of vmstat. Is that true? If yes, is the real free
memory externalized in any UNIX command or a system call for which I can
write a short C program? Thanks.

Yong Huang

 
 
 

"free" in vmstat is not free memory page scanner sees, is it?

Post by Casper H.S. Dik - Network Security Engine » Wed, 07 Mar 2001 05:49:11


[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>Recently there was a discussion on an Oracle database mailing list regarding
>how to measure memory pressure or shortage based on vmstat output. Some say
>sr (scan rate) is the only accurate metric (if priority paging is not
>enabled). Some say po (paging out) and sr together. I understand that sr is
>determined by how much free memory is available relative to kernel tunables
>LOTSFREE, DESFREE, MINFREE etc., which determines how often page scanner
>daemon runs. My question is, if you use sr as the metric for memory
>pressure, why not directly look at the free memory available? But I think
>the problem is that the free memory the page scanner sees is not the number
>under the "free" column of vmstat. Is that true? If yes, is the real free
>memory externalized in any UNIX command or a system call for which I can
>write a short C program? Thanks.

There's no point in looking at free memory, especially not prior
to Solaris 8.  The system tries to keep freemem the same size
as desfree.

The "sr" column is actually a good measure in that it tells you how
many pages the system needs to examine in order to free sufficient
memory.  The higher sr, the higher the memory pressure.

But prior to S8, "sr" could also mean that you have a lot of memory pressure
due to filesystem I/O.

"po" is a measure of I/O, not just paging because of memory shortage.

There's no easy way to get this through C, though you could use
the kstat interfaces.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

 
 
 

"free" in vmstat is not free memory page scanner sees, is it?

Post by yhu.. » Thu, 08 Mar 2001 01:24:08


Thank you, Mr. Casper. That's very informative.

Just to satisfy my curiosity, I looked at man kstat. It doesn't look like giving us free memory. man kstat | grep -i free doesn't return anything.

It's interesting to know that freemem (you mean "free" under vmstat, right?) is trying to reach desfree. My netstat -k shows desfree 1967. I believe its unit is `pagesize`, so it's 1967*8192 = ca. 16MB. vmstat 2 5 => memory => free shows 3928, followed by 62032, 61976 etc. Not sure how to relate any of these numbers to 16MB desfree. Currently there's not much activity on the system (Solaris 2.6, no priority paging).

Yong Huang




>[[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]


>>Recently there was a discussion on an Oracle database mailing list regarding
>>how to measure memory pressure or shortage based on vmstat output. Some say
>>sr (scan rate) is the only accurate metric (if priority paging is not
>>enabled). Some say po (paging out) and sr together. I understand that sr is
>>determined by how much free memory is available relative to kernel tunables
>>LOTSFREE, DESFREE, MINFREE etc., which determines how often page scanner
>>daemon runs. My question is, if you use sr as the metric for memory
>>pressure, why not directly look at the free memory available? But I think
>>the problem is that the free memory the page scanner sees is not the number
>>under the "free" column of vmstat. Is that true? If yes, is the real free
>>memory externalized in any UNIX command or a system call for which I can
>>write a short C program? Thanks.

>There's no point in looking at free memory, especially not prior
>to Solaris 8.  The system tries to keep freemem the same size
>as desfree.

>The "sr" column is actually a good measure in that it tells you how
>many pages the system needs to examine in order to free sufficient
>memory.  The higher sr, the higher the memory pressure.

>But prior to S8, "sr" could also mean that you have a lot of memory pressure
>due to filesystem I/O.

>"po" is a measure of I/O, not just paging because of memory shortage.

>There's no easy way to get this through C, though you could use
>the kstat interfaces.

>Casper
>--
>Expressed in this posting are my opinions.  They are in no way related
>to opinions held by my employer, Sun Microsystems.
>Statements on Sun products included here are not gospel and may
>be fiction rather than truth.

_______________________________________________
Submitted via WebNewsReader of http://www.interbulletin.com
 
 
 

"free" in vmstat is not free memory page scanner sees, is it?

Post by Darren Dunha » Fri, 09 Mar 2001 02:22:16



> Thank you, Mr. Casper. That's very informative.
> Just to satisfy my curiosity, I looked at man kstat. It doesn't look like giving us free memory. man kstat | grep -i free doesn't return anything.
> It's interesting to know that freemem (you mean "free" under vmstat, right?) is trying to reach desfree. My netstat -k shows desfree 1967. I believe its unit is `pagesize`, so it's 1967*8192 = ca. 16MB. vmstat 2 5 => memory => free shows 3928, followed by 62032, 61976 etc. Not sure how to relate any of these numbers to 16MB desfree. Currently there's not much activity on the system (Solaris 2.6, no priority paging).

Hmm.. I don't know why it would tend toward desfree, since the page
scanner should be running at that point.

I think it should tend toward cachefree if you have priority_paging
enabled, or lotsfree if you do not.  Below those figures, the scanner
should run, above them it should not.

When using vmstat, ignore the first line..  Just use the subsequent
lines.

Memory may be significantly *above* that amount if your machine does
very little I/O (so few pages are loaded over time), and you have
"recently" closed a large application (thus freeing a large chunk of
memory).

--

Unix System Administrator                    Taos - The SysAdmin Company
Got some Dr Pepper?                           San Francisco, CA bay area
          < How are you gentlemen!! Take off every '.SIG'!! >