Re: system hangs
Ken, Cindy,
I notice this from time to time on my taughtly stretched SCO Unix
3.2.4.2 server, which is running two Online 7.10 instances - one for real,
one for development, with a total of 5 databases (one SE). It's a server
with 64M Ram, running other Unix applications, plus TCP/IP..
There are NO messages, as you say, and NO problems, it is just
impossible to start up any more user connections, say, onmonitor, ontape,
dbaccess, and though no more memory has been allocated by IDS, everything
just hangs ... including user sessions. The only cure is to stop
everything, shut down the instance having the problem, and restart. Looking
at CPU usage in onstat and Unix sar, I see a lot of time being spent in
user CPU and very low CPU idle. My guess: I need more of everything. And I
suppose I'll also hear the familiar words, "upgrade", and agree.
Let me know if you discover anything else that may be causing the problem.
Yours,
Nick
At 09:23 AM 11/13/98 -0400, Ken Ketchum wrote:
>T> >
>> >System Specs:
>> > Sun Enterprise 5000
>> > 1 Gb RAM
>> > IDS 7.24.UC5
>> >
>> >Earlier this week, our database engine hung. There was no error
>> >message,
>> >users could not connect, and we could not shut the database down. We
>> >finally did a 'kill -9' on the processes, rebooted the server, and then
>> >did
>> >an index check. We have no idea what is causing this problem. Informix
>> >support hasn't been able to give us any good clues.
>> >
>> >Anyone have any ideas?
>> >
>> >Thanks,
>> >
>> >cindy
>> >
>> >
>> >==========================
>> >cindy_alford@ymd.yamaha-motor.nl
>> >Yamaha Motor Distribution
>
>
>Are you using all or mostly shared-memory access; and had the
>system been up for a long time? We had very similar behavior
>from 7.24UC5 on a Sparc 1000E runing Solaris 2.5.1. Tech support
>mentioned a bug that wiggled under heavy shared memory use.
>We are working around it by using TCP connections, until we get
>a chance to install 7.30, which supposedly fixes it.
>
>-Ken Ketchum
>Etak, Inc
>
*********************
Nick Nobbe
NLS/BPH
Library of Congress
nnob@loc.gov