Page fault

[System Dude_1]

Dear friends,

I'm running oracle database 8.1.6 on n4000 with 8GB RAM and 8CPU. Total swapspace is 8GB. When I run vmstat the output as below :

# vmstat 5 100
faults cpu
in sy cs us sy id
2875 5036 940 15 3 82
2874 3065 876 13 2 85
2872 2135 911 16 2 83

The questions is, why in and sy is very high? is it good or bad. If it is bad, what cause the problem and how to resolve it. Thx in adv.

[Paula J Frazer-Campbell]

Hi
Have a look at these threads:-

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x82e95f260cafd4118fef0090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,1150,0x8a860cb17a32d5118fef0090279cd0f9,00.html

Paula

[System Dude_1]

I've done as below, what does the information tell? Is there anything that need to be tune?

$ vmstat -s
26014 swap ins
26039 swap outs
1122 pages swapped in
959 pages swapped out
20345072 total address trans. faults taken
6428595 page ins
99747 page outs
159475 pages paged in
355395 pages paged out
6543556 reclaims from free list
6371016 total page reclaims
977 intransit blocking page faults
32603024 zero fill pages created
26346793 zero fill page faults
1645106 executable fill pages created
94772 executable fill page faults
0 swap text pages found in free list
659262 inode text pages found in free list
105 revolutions of the clock hand
6345908 pages scanned for page out
905480 pages freed by the clock daemon
51145882 cpu context switches
162455369 device interrupts
29093446 traps
279377807 system calls
6035994 Page Select Size Successes for Page size 4K
5263349 Page Select Size Successes for Page size 16K
6035994 Page Select Size Failures for Page size 16K
16562396 Page Allocate Successes for Page size 4K
5355194 Page Allocate Successes for Page size 16K
17 Page Allocate Successes for Page size 64M
2221212 Page Allocate Failures for Page size 4K
1657915 Page Allocate Failures for Page size 16K
12120 Page Demotions for Page size 16K
9 Page Demotions for Page size 64M

[Paula J Frazer-Campbell]

Hi

From John's post in the second thread:-

You will always have page faults and page-ins when the system finds that something is not in memory that it needs.

Everything is good if you do not have many page-outs. Page-outs will occur if memory gets tight and if a job does a malloc and memory space is not available contiguously. After this page-out is done, page-ins will be needed when the paged-out process gets control.

Extra memory will be used for file buffering (caching) and will normally take most of the rest of what you have if a lot of file I/O is being done.

Your figures are low.

Paula

[Sridhar Bhaskarla]

Check your swapinfo -t and see how much swap you are taking apart from the reserve column. If there is some % (excluding the reserve), then you are going low on memory. Otherwise you don't have to worry with the page faults.

-Sri

[Bill Hassell]

Page faults have nothing to do with I/O, they refer to a hardware buffer called the TLB which is very fast but has limited capacity and serves as a pointer to a page of memory (normally 4k). If a program needs large amount of memory and begins accessing random locations, all the registers in the TLB may be used and if additional accesses are required, one of the addresses will have to be remapped, causing a page fault (this is measured in microseconds however).

Normally, page faults are common and don't occur at a very high rate (less than a few hundred per minute) which has no measureable effect on performance. However, if many thousand occur in a minute, compute speed will be lowered while the processor waits for the memory address to be made available.

Prior to 64-bit computing (PA-8000 chipset), the size of a memory page was 4k and could not be changed. Thus, massively large programs that were very compute-bound (like a complex differential equation solver) could incur thousands of page faults every minute and lowering the effective compute speed (due to memory address delays).

With the PA-8000 chips, the TLB was redesigned to handle large page sizes (4k to 64meg) and with appropriate compiler flags or by using the chatr command, programs could access much larger (contigous) areas of RAM with each TLB entry. So page faults are OK unless they are massive in number (thousands per minute). You'll need to clear the vmstat counters (vmstat -z) and then run vmstat as in:

vmstat -s | grep page

Page in/out is much more useful as far as performance: page in refers to pages returned from the swap area but also counts every page rolled into memory when a new program starts. In other words, page in rates are not too meaningful for RAM questions.

page outs are the most useful. A low number of page outs is desirable as this counter tracks every page rolled out to the swap area (usually due to memory pressure). A few page outs (less than 50) per minute is fine but 5000 per minute means RAM is way too small and processes are being be slowed by as much as 100:1.

[System Dude_1]

Hi,

If I have the output as below, what should the analysis would be. Is it ok?

Mon Sep 3 09:42:26 SST 2001
# vmstat -s | grep page
0 pages swapped in
0 pages swapped out
2054 page ins
6 page outs
33 pages paged in
6 pages paged out
2024 total page reclaims
0 intransit blocking page faults
9965 zero fill pages created
8496 zero fill page faults
431 executable fill pages created
0 executable fill page faults
0 swap text pages found in free list
192 inode text pages found in free list
0 pages scanned for page out
227 pages freed by the clock daemon

Mon Sep 3 09:43:24 SST 2001
# vmstat -s | grep page
0 pages swapped in
0 pages swapped out
17626 page ins
52 page outs
555 pages paged in
52 pages paged out
17274 total page reclaims
0 intransit blocking page faults
178991 zero fill pages created
167214 zero fill page faults
2723 executable fill pages created
20 executable fill page faults
0 swap text pages found in free list
1363 inode text pages found in free list
0 pages scanned for page out
1780 pages freed by the clock daemon

[Bill Hassell]

The numbers from vmstat look fine, almost no page outs. However, if you are experiencing performance problems, you will need information from many more areas such as disk and LAN I/O. However, classic Unix utilities such as vmstat, sar and top require a lot of work to interpret the results.

Rather than spend several days learning about these tools and how to use them, load a copy of GlancePlus from your Application CDROMs and use the statistics presented by Glance to track down any problems.

As many system administrators are discovering, performance issues with Oracle are not resolved with kernel changes but with SGA changes, better SQL procedures and a redesign of the database indexes. There are no quick answers since Oracle is a very general name for a highly customizable set of data management tools.