HP3000-L Archives

March 1997, Week 3

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:
"Michael D. Hensley" <[log in to unmask]>
Reply To:
Date:
Thu, 20 Mar 1997 07:27:55 +0000
Content-Type:
text/plain
Parts/Attachments:
text/plain (90 lines)
> Using SOS from LUND I found the culprit that was using 80-95 percent of the
> CPU. This process was not releasing the CPU at all, as far as I could tell.
> SOS was unable to tell me what program was doing this. I knew it was a
> program located down some hierarchical POSIX path, but SOS blamed it all on
> SH.HPBIN.SYS. This problem seems very strange to me however, we recently
> upgraded from a series 70 to a 969 and a 928. So I am not to experienced
> with MPE/iX (been working with Classic MPE V since 1984).

Technically, the Measurement Interface did the "blaming".

> Why can't SOS Identify the program that is doing this?

Unfortunately, the testing I've done so far seems to confirm that the
Measurement Interface is treated fork'ed process as if they were part of the
parent.  This isn't %100 certain yet, though.

> How am I going to find out what process is responsible for this?

Good question.  Until we get the MI and/or SOS (and GLANCE, it behaves
the same way) fixed, all I can think of is:

a) Track down the user whose "SH" is showing up as the hog, and ask what he
was doing;

b) Don't run programs under the shell.

(I prefer "a").

> Is the reason SOS can't find this Process name because SH.HPBIN.SYS is
> probably using the "fork" system call instead of the "CREATEPROCESS"
> intrinsic?

Jeff Kell posted a some good discussion and questions on this, but the short
answer is: "probably".

> Also, I have noticed when I use the shell (SH.HPBIN.SYS) to do a simple
> command like: "tail -f /usr/local/samba/var/log.nmb" It begins to use 80-90
> percent CPU. I think something is seriously wrong here. I use the tail
> command on other machines around here (Solaris 2.3) all the time, they don't
> demand those kind of resources from the machine.  Just as in the above
> scenario, SOS from LUND blames it on the SH.HPBIN.SYS  On more thing, I exit
> out the shell, and enter the following at the MPE command prompt:
>
>  RUN TAIL.HPBIN.SYS;INFO="-f /usr/local/samba/var/log.nmb"
>
> Then once again 80-90 percent of the CPU is being used only this time SOS
> shows it to be TAIL.HPBIN.SYS

Not only that, if from within the shell you do:

  $ callci "tail /SAMBA/PUB/var/log.smb"

a process named "TAIL" shows up.  I'm guessing "callci" createprocess'es
"CI.PUB.SYS" and passes it the command.

> Do I need run a program from MPE (COMMAND.PUB.SYS) so that SOS will
> recognize it?

(Or GLANCE, or SHOT, or...)
For now, that seems to be true, if you want to see the program as an
individual process.  It *looks like* the CPU is being "charged" to the sh
process which forks tail (which is *not* the sh that you typed the command
into; that one createprocess'ed another one).

Hmmm, I just realized that, since SHOT has the same "problem", it isn't the
MI (SHOT doesn't use the MI).  The cause must be elsewhere in MPE...

> I don't think these programs really require all the CPU they are getting,
> could something be seriously wrong with the MPE implementation of POSIX?

That's a whole 'nother question.  On my system, the tail command we've been
discussing uses 180-185 ms, and my total CPU used on an otherwise idle system
was less than 2%.

The shell is frequently unhappy unless your disc free space is pretty much
un-fragmented.  Could that be the problem?

> Maybe I should just do a linkedit "altprog sh.hpbin.sys;pri=ds" since I
> can't find the actual program names under the POSIX shell. Not the right
> solution, I know.
>
>
> I will greatly appreciate any insight in this area from absolutely anyone
> who knows.

---
Michael D. Hensley             |
Software Development Manager   | mailto:[log in to unmask]
Lund Performance Solutions     | http://www.lund.com

ATOM RSS1 RSS2