Hi Art,
We're having a quiet afternoon here, so I put the process into the C
queue. It immediately dropped to the bottom of that queue, but it's
getting a healthy percentage of the CPU now. I'll leave it that way for
a few minutes and see if it does anything. If not, I'll move it back to
the bottom of the E queue so as not to get the rest of the box's users
mad at me :-).
We normally have PowerHouse set up to run at a lower queue, but I've
moved it around enough manually with SOS that the original designation
is moot by now.
Well, it's now been about 5 minutes, and the process still hasn't made
any apparent progress. The file markers reported by SOS haven't moved
even though it's done on average 180 - 200 i/o per second. I'll try
again around 5:00pm here, as that's another quiet time.
Thanks!
[log in to unmask] wrote:
> Hi John :)
> Ok... someone will correct me if I am wrong... and being Married?? Heck!
> I am used to being wrong :) Just kidding there are people on here who know
> my Better Half and know how awesome she is!
>
> First, E queue gets the least CPU Time... so that actually hurts the
> process' hope of getting a chance at the Executioner... but don't go above
> the C queue... B and A are OS queues... and usually upper one - third of
> the C queue will do the trick... B Queue, well... I have crashed a few
> boxes in my time putting processes up there... (Rich Trapp can tell those
> stories if he wants! hehe)
>
> Do you have time when there are no users on the box? You could try the
> queue changes then... worst you could do would be to crash the box... and
> you are already considering bringing it down... :)
>
> Cognos sometimes is forced to run it's process in lower queues to
> control use of the cycles by user's launching Cognos and hogging the box
> (Tim Ericson taught me that trick) and your situation does sorta sound like
> it is doing that sort of thing...
>
> Art "fishing for answers for John :) " Bahrs
>
> =======================================================
> Art Bahrs, CISSP Information Security The Regence Group
> (503) 225-4992 Cell 971-244-2459 FAX (503)
> 220-3806
>
>
>
> "John
> MacLerran"
> <[log in to unmask] To
> edu> [log in to unmask]
> cc
> 12/19/2006 [log in to unmask]
> 01:45 PM Subject
> |------------| Re: [HP3000-L] How to stop a
> | [ ] Secure | runaway process?
> | E-mail |
> |------------|
>
>
>
>
>
>
>
>
> Hi Art,
> Thanks for the definitive answer on the [3000-l] thingy. The raven page
> doesn't make it clear. :-)
>
> It doesn't appear to be waiting on a resource. The only wait states
> reported by SOS are preemption and quantum expiration, and a few 'file
> page fault' messages. I would expect the preemption and quantum wait
> states, because I have it nailed to the bottom of the E queue. I gave it
> about 30 minutes at the top of the D queue earlier today, with the
> intent to give it additional resources so it could 'wake up and die', so
> to speak, but that didn't help. I've checked dbutil for locks on the
> database it's using, and there are no locks held.
>
> It appears to be stuck in a sort -- the largest file it has open is
> QTPSORT (it's a PowerHouse QTP process), but that file is not getting
> larger and doesn't appear to have any i/o activity (at least that SOS
> reports -- it's a temp file so I can't see it with a listf or anything).
>
> I've pretty much given up hope of killing it without bouncing the box,
> but I was hoping to find a way to quiesce it so it wouldn't continue to
> consume i/o and cpu resources.
>
> Thanks!
>
> Art Bahrs wrote:
>
>> Hi John :)
>> The listserv will handle the 3000-L part for you :)
>>
>> Check the archives... lots of stuff in there about this kind of stuff
>> IIRC (and we all know about my memory!! hehe)
>>
>> Second, can you tell in SOS if the process is waiting on a resource
>>
> to
>
>> be freed up? I remember something waaaayyy back when where I used SOS
>>
> and
>
>> some other SRN Nuggets (Lund Toolbox Grandparents) to figure out what
>>
> other
>
>> process had a resource and then free up that resource so the abortjob
>>
> could
>
>> take effect or something like that ... Sorta killed another process to
>> execute the process I wanted dead... hey... the 3k has it's own built in
>> Morgue so it will clean up the mess just fine :)
>>
>> Art "bad humor goes with bad memory :) " Bahrs
>>
>> =======================================================
>> Art Bahrs, CISSP Information Security The Regence
>>
> Group
>
>> (503) 225-4992 Cell 971-244-2459 FAX (503)
>> 220-3806
>>
>>
>>
>>
>
>
>> "John
>>
>
>
>> MacLerran"
>>
>
>
>> <[log in to unmask]
>>
> To
>
>> EDU> [log in to unmask]
>>
>
>
>> Sent by:
>>
> cc
>
>> "HP-3000
>>
>
>
>> Systems
>>
> Subject
>
>> Discussion" [HP3000-L] How to stop a runaway
>>
>
>
>> <HP3000-L@RAVE process?
>>
>
>
>> N.UTC.EDU>
>>
>
>
>
>
>
>
>> 12/19/2006
>>
>
>
>> 12:50 PM
>>
>
>
>
>
>
>
>> Please respond
>>
>
>
>> to
>>
>
>
>> "John
>>
>
>
>> MacLerran"
>>
>
>
>> <[log in to unmask]
>>
>
>
>> EDU>
>>
>
>
>> |------------|
>>
>
>
>> | [ ] Secure |
>>
>
>
>> | E-mail |
>>
>
>
>> |------------|
>>
>
>
>
>
>>
>>
>> Hello everyone,
>> I apologize if you've received this twice, but I forgot to put [HP3000-L]
>> in
>> the header.
>>
>> We have a runaway process on our box (N4000 4-way 440MHz, mpe 7.5, PP2).
>> We've tried to do an abortjob on it, but that didn't kill it. Then, we
>> tried an abortproc on the specific PIN, and received the message: "There
>>
> is
>
>> already an ABORT pending for pin "902". (CIWARN 11015)". In SOS, the
>> process
>> that is still alive is the son process, and the father process is
>>
> reported
>
>> as not being active. Grasping at straws, I did a kill -9 on the son's PIN
>> in
>> the posix shell, but that didn't do anything.
>>
>> Is there anything else I can try, or do we need to reboot the box? Is
>>
> there
>
>> anything I can do to suspend that process so it won't consume resources?
>> I've already dropped it to the lowest it can go in the E queue, but it
>> still
>> consumes disc i/o and cpu cycles.
>>
>> Thanks!
>> John MacLerran
>> [log in to unmask]
>>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>>
>>
>>
>> ***IMPORTANT NOTICE: This communication, including any attachment,
>>
> contains information that may be confidential or privileged, and is
> intended solely for the entity or individual to whom it is addressed. If
> you are not the intended recipient, you should delete this message and are
> hereby notified that any disclosure, copying, or distribution of this
> message is strictly prohibited. Nothing in this email, including any
> attachment, is intended to be a legally binding signature.***
>
>> * To join/leave the list, search archives, change list settings, *
>> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>>
>>
>>
>
> --
> ----------------------------------------------------------------------
> John MacLerran
> IT Analyst, Senior email: [log in to unmask]
> Idaho State University V(208) 282-2954
> http://www.isu.edu/~macljohn F(208) 282-3673
> ----------------------------------------------------------------------
>
>
>
>
>
> ***IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.***
>
>
>
--
----------------------------------------------------------------------
John MacLerran
IT Analyst, Senior email: [log in to unmask]
Idaho State University V(208) 282-2954
http://www.isu.edu/~macljohn F(208) 282-3673
----------------------------------------------------------------------
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
