Solaris: ioctl() causing app lock-up

Solaris: ioctl() causing app lock-up

Post by Bill Bumgarne » Fri, 17 Jul 1998 04:00:00



I walked into the middle of a particularly * mess of socket code while
maintaining a client's application.

Symptoms:

        Occasionally, the production applications (Apple's WebObjects
middleware apps served via the web) "spin".  That is, their CPU usage goes
to 100% and the app stops responding to all requests.

        Unfortunately, core files are useless in the current environment
[on my todo list, trust me] and gdb is not installed on the production
servers.

        "pstack" indicates that the app is typically spinning in ioctl().

Details:

- on almost every request, the app opens yet-another-TCP/IP stream or two
or three or four or five to grab more information.  All streams SHOULD be
closed by the time the response is generated.

- some of the read-data-from-the-stream code is really ineffecient.  For
example, some of it looks like:

do {
        read(socket, ... args to read ONE BYTE AT A TIME ...);
while (bufPtr != \n);

i.e. some of the read code actually reads a single byte at a time from the
receive buffer.   I'm not totally sure of the internals of how read()
works, but this strikes me as being asoundingly ineffecient.

- The ioctl() call that caused the most recent spin was:

     if (ioctl(curQCore->socket, I_NREAD, &avail) < 0) return NULL;    

Solutions:

I don't know-- that's why I'm asking the community at large... :-)

To give an idea of the scope of an answer that I could believe, some
details:

- it may be that a patch is required?  Where there any patches released in
the last year that fix problems with the socket stuff on Solaris?

- could it simply be that all the opening/closing of the data streams is
enough to cause the socket substrate to explode under high load
situations?

- could an additional stress factor be the presence of the
read-a-byte-at-atime style of grabbing data out of the receive buffer?

thank you,
b.bum

 
 
 

1. Kingston Fast Ethernet Switch causing lock-ups

I am networking three systems with a Kingston Fast Ethernet Switchbox: Unix,
NT and Windows 98.  The Unix system starting locking up about 1 to 2 times a
day after it was networked and has not done so since it was unplugged from
the Kingston box.
    Can anyone help me debug this situation?
Chuck

2. Implicit GNU Licence?

3. pcmcia causes lock-ups -- nec versa 6030h

4. pte_chain leak in rmap code (2.5.31)

5. PCI to PCMCIA adaptor causing lock-ups (4.2)

6. How do you see your Win Network puters from linux box?

7. Lock ups with SCO and Caps lock

8. nagging registration

9. How to find cause of system lock-up

10. hot temp causes lock-up

11. Q: power_saver option sometimes causes system lock-up

12. Shape Ups,Men's Shape Ups,Men's Skechers Shape Ups - new styles!

13. name to lock file problem - solaris 7 & Oracle Web App