Hi Jim

I'm guessing the disk figures you are quoting are the % busy figures from
WRKDSKSTS.

While your data and everything is in the IASP all temporary etc storage that
the system uses for jobs etc will come from the system asp, so the kind of
things that might explain this are:
-copying a file to a work file in qtemp
-something doing some sql requiring an index build
-weird intensive spool activity (depending where your outqueue are)

What percentage busy are the disk arms in the system asp normally ? This
might give you a clue and it also might just be a case of the arms are
normally busy enough and something pushes them over the edge.

You could also have something that required more memory that is causing a
lot of swapping to disk.

Hope this helps

Regards
Evan Harris



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of JDHorn@xxxxxxxxxxxxxx
Sent: Thursday, 27 March 2008 8:18 a.m.
To: midrange-l@xxxxxxxxxxxx
Subject: System asp disk arm utilization going crazy

Can someone give me a clue of where to start looking?

We have a 520 with 4 disks in the system asp and 4 disks in the iasp.
Pretty much only the "system" is on the system asp. all user programs
and
data are on the iasp.

Most of the time, during the day, the disk utilization is low - about 12%
on the system asp, about 8% on the iasp.

The system asp is about 54% full, the iasp about 84% (will go down to 60
in about 2 weeks).

Intermittantly the system asp utilization will just go crazy, going up to
90 to 100 percent on all disks for up to 20 minutes. The iasp goes up
also, but to 20 to 40% on all disks

during this time - based on the management central system monitors
machine pool faults go from about 5 to about 15,
user pool faults from about 10 to about 70
cpu utilization stays at 5 to 10%
disk iop utilization stays at about 2%
other monitors don't seem to change

I did not think to run a wrksyssts during the affected time.

From the cpu utilization monitor I try to find the jobs that are active
and see if they are doing a lot of disk access, but none of them are.

Since all the data that anyone could download is on the iasp, would
someone trying to download large amounts of data from the iasp drive up
the system asp usage?

I can't find any process that causes this.

Any thoughts or good places to look?


typical wrksyssts. qprfadj set to 2.

Work with System Status
03/26/08
13:53:34
% CPU used . . . . . . . : .8 Auxiliary
storage:
% DB capability . . . . : .0 System ASP . . . . . . :
246.9 G
Elapsed time . . . . . . : 00:00:01 % system ASP used . . :
53.9935
Jobs in system . . . . . : 19023 Total . . . . . . . . :
493.9 G
% perm addresses . . . . : .131 Current unprotect used :
14279 M
% temp addresses . . . . : .514 Maximum unprotect . . :
14728 M


Type changes (if allowed), press
Enter.


System Pool Reserved Max -----DB-----
---Non-DB---
Pool Size (M) Size (M) Active Fault Pages Fault
Pages
1 349.26 161.30 +++++ .0 .0 .9
.9
2 2238.99 5.91 243 .0 .0 1.8
2.7
3 2790.86 .39 71 .0 .0 .9
.9
4 277.63 .03 19 .0 .0 .0
.0




Jim Horn

This email is intended only for the person or entity
to which it is addressed and may contain information
that is privileged, confidential or otherwise protected
from disclosure. If you are not the named addressee
or an employee or agent responsible for delivering
this message to the named addressee, you are not
authorized to read, print, retain copy, and disseminate
this message or any part of it. If you have received this
message in error please notify us immediately by email,
discard any paper copies and delete all electronic files
of this message.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].