Operating System - HP-UX
1833017 Members
2130 Online
110048 Solutions
New Discussion

Re: how to check pagging problem

 
siva baskaran
Regular Advisor

how to check pagging problem

Dear(s),
what are the basic first activities and what are the basic steps how to find out pagging prolem? and is any log file or any file to find out pagging problem

actually cutomer facing some problem are

this is their's talk , so please go through that and provide me accordinly

Executive Summary:
==============
1. Cpu consumption is at peak.
2. The system has more paging due to which the Database Instance SGA is
getting swapped out.

Deatils
=======
1. Few sqls are using lot of cpu due Full table scans and latching
issue. Latching issue is due to system paging 2. The total memory in
system is 40GB, and memory usage is 98%. Database

Instance uses a total memory of 7GB only.
3. The "top" and "vmstat" command show available memory as 7GB. 4. 35%
of swap area is under use which indicates system paging. 5. Attached
document shows increase in cpu usage since last two days.

Action taken on 4-Jun-06 by onlinedba =========================== 1.
Fixed issue with cpu consuming process by creating index for workflow
related query.




thanks a lot
siva
2 REPLIES 2
Raj D.
Honored Contributor

Re: how to check pagging problem

Siva ,

For CPU consumption you can use :
i) sar
ii) glance

# sar -u -M 10 20


for paging check use vmstat and check for pi po values , a non zero value indicates high swap usuage.
# swapinfo -tm
# vmstat 10 20


Cheers,
Raj.
" If u think u can , If u think u cannot , - You are always Right . "
A. Clay Stephenson
Acclaimed Contributor

Re: how to check pagging problem

The first task is to determine if you are actually swapping by examining the pageout rate either with Glance or the vmstat command. 35% of swap area may mean absolutely nothing (especially if the 35% is "memory" (pseudo-swap). If you are seeing significant pageout rates (> ~15-20/s for periods of minutes or more) then you are under memory-pressure.

Without that metric nothing much can be known. If you are running dynamic buffer cache then I would disable it by setting bufpages to a non-zero value so that bufpages X 4KiB = 800-1600MB.

Also, while you are tuning make certain that timeslice has not been reduced to much below 10 (and especially not 1).

You may also be under memory pressure if there are a number of shared memory segments which are not attached to any processes. Done any kill -9's lately?
If it ain't broke, I can fix that.