Re: page faults

Mohammed Hamed wrote:
>
> Hi,
> I'm using Linux 2.0.35 and squid 1.1.21, cache manager reports the
> ratio of number of tcp connection/page faults per physical io is
> around 0.5 and it's increasing by time. Due to the FAQ, this is a bad
> thing and an indicator of system doing a lot of swapping,

No. A high page fault ratio MAY indicate swapping.

You need to use other tools as vmstat, sar or whatever available on your
platform to find out it it is swapping or not.

And please remember: When measuring page fault ratio, do so using a
delta measure. Collect the walues, wait some time, collect another set
of values and calculate the ratio of the difference between the two. The
fact that the tcp/page fault ratio is increasing feels like you are
measuring the ratio using absolute values, which gives a false figure.

> however looking at the output of other system tools, like vmstat
> it indicates that the system is doing no swapping at all

Another cause to pagefaults is if your machine runs out of free memory
pages. I.e. squid is writing data faster than your OS sends the data to
disks. What is the output of the free column of vmstat in relation to
the values found in /prox/sys/vm/freepages multiplied by four?

See /usr/src/linux/Documentation/memory-tuning.txt for information about
what the freepages values are, and how you may tune them.

Other OS:es have similar knobs that you can tune. Usually kernel
parameters named min_free lots_free and max_free or similar.

If a application manages to push the free list down to min limit then
the application is blocked until the OS has managed to free some memory
by either flushing disk buffers or swapping out some pages.

A guideline is that a I/O intensive application needs to have a much
higher free_pages_hig (and _low) limit than a CPU/Memory intensive
application. A good sign that you need to tune these limits is if the
free list dips far below the middle limit.

---
Henrik Nordstrom
Spare time Squid hacker