Jeff,
I have a couple of questions.
What version of MPE/iX are you on?
Are you current with all reactive patches?
What type of NIC card do you have 10MB or 100MB?
Thanks,
-Craig
--- Jeff Stothart <[log in to unmask]> wrote:
> Hello all -
>
> I'm having a problem with one of our hp3000's and I'm a little stumped.
> Our company uses Tivoli to check to see if a system is 'up' (which I think
> to Tivoli that means it responds to a ping or a series of pings). I have
> an hp3000 that occasionally does not respond. When this happens, our
> trouble ticket and paging mechanism is triggered, and the support folks are
> in a state of nervousness until someone actually logs onto the system and
> sees it's still humming along.
>
> I initially thought it must be a network problem, but I've found something
> that has me questioning that. We use the Lund product to gather
> performance data, and it takes its performance 'snap shot' every 5
> minutes. It's pretty good about being on time...sometimes the timestamp on
> one collection cycle is 6 minutes after the last one, but most of the time
> it's every 5 minutes. Well, during the time we're having the problem, it
> skips its collection cycle completely, so there's 10 minutes between
> cycles. This leads me to believe that there's something going on on the
> system that may be causing the problem.
>
> Does anyone have any ideas as to what to look at?
>
> Here's some more info:
>
> The problem has happened 4 times in the month of January, and 3 times in
> the month of December. The first occurrence was 12/8. I'm guessing the
> problem lasts for maybe 3 minutes (based on console history). The console
> does not show any messages during this time. The messages right before the
> problem starts are 'normal'. Same with the messages after the problem is
> cleared up. It looks like normal processing picks right back up.
>
> We put one patch on on 12/6 which looks unrelated to this problem.
>
> ODIMXE9B Online Diagnostics version A.75.03 - xt and fwu disk enclosure
> support
>
> This is a test system and the problem has only occurred during the evening
> hours or early morning hours. During the evening we run a Veritas network
> backup, and I can tell one was running during each occurrence of the
> problem when it happened in the evening. However, it's processes are
> always in the cs queue. I'm assuming that the Lund collection process
> fires off in the linear queue (need to verify that with Lund however), so
> it should get cpu time over the backup. Also, we've been running the
> Veritas backup for years without these problems occurring.
>
> For the morning problems, the one constant that I see in the performance
> data (the '10 minute snapshot performance data') is the NFT process. It's
> in the linear queue (bs), but it never shows up as a 'hog process'. In the
> mornings we do a lot of dscopying to this system, and also a lesser amount
> from this system to another hp3000. But again, we've been running these
> processes for a long time without problems.
>
> I've looked through the network logs and the system logs, and I don't see
> anything unusual compared to when the system was not having a problem.
>
> I've also noticed that on occasion it takes longer than normal to get to
> the initial Logon Prompt for this system.
>
> Any ideas would be greatly appreciated! Thanks- Jeff
>
>
> Jeff Stothart
>
> Visit LCI on the Web: www.lci-online.com
>
> Lawinger Consulting, Inc.
> 106 Central Ave, Suite A
> Osseo, MN. 55369-1243
> Tel: (763) 425-9284
> Office Fax: (763) 425-5483 Lotus Notes Fax: (651) 732-8212
> Email: [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 *
__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
