HP3000-L Archives

December 2000, Week 1

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Chris Goodey <[log in to unmask]>
Reply To:
Chris Goodey <[log in to unmask]>
Date:
Thu, 7 Dec 2000 17:57:35 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
I believe Glance shows transaction logging I/O charged
to a blank process. When running big db update jobs,
I will see a large amount of I/O assigned to an unnamed process
as in 2 lines clipped from a Glance display below. Note the CNVSHIP2
program shows up, but has blank entry about it - I believe
this is either transaction logging I/O, or general memory
management overhead I/O.

JSNo  Dev Logon                 Pin Program     Pri  CPU%  Disc Trn  Resp
Wait
P11   SYS MANAGER.SYS            11            C152  5.7% 176.0   0   0.0
MEM
J51    10 CNVSHIP,JOBS.ECOMDMI   85 CNVSHIP2   D238  2.4%  11.4   0   0.0
DISC


-----Original Message-----
From: Stan Sieler [mailto:[log in to unmask]]
Sent: Thursday, December 07, 2000 5:28 PM
To: [log in to unmask]
Subject: Re: [HP3000-L] Disc Writes


Re:
> I ran a report showing disc write activity on our system (979/200) using
SOS
> from Lund.  The report was run for each day last week.  On the top of the
> list each day with 35% of disc writes is a program with a "blank" program
> name.  Number two on the list and on down are actual programs on our
system.
> The run count each day of this "blank" program is 64.  I'm guessing it is
> some sort of system process, but having identical run counts each day
makes
> no sense.  Any ideas on what this could be?

It depends upon where the data was collected from.  If it's from the
Measurement Interface (MI), then the question is: did some of the
entries have a PIN of 0?  If yes, then that may explain the blank.
Or, it may be that all entries had valid PINs, but that some were for
system processes ... and SOS didn't implement the code necessary to get
their names (trickier than for normal processes).  If this is the case,
lean on them :)  ... I gave them (and other people) the info on how to get
names for such processes years ago!

If the data comes from file-close log records, then ... hmm ... then the
explanation may be similar :)

Stan Sieler                                           [log in to unmask]
www.allegro.com/sieler/wanted/index.html          www.allegro.com/sieler

ATOM RSS1 RSS2