Pipes and Kernel Tuning - 11.0

[OldSchool]

We've been having issues w/ UniVerse database application that occasionally reports that it can't open a pipe. (Users that used to login via terminal emulator now access the system via uvnet sockets)

My first thought was insufficient tmp space, but that doesn't seem to be the case.

What kernel parms (if any) should I be looking at
-or-
is there a way to determine where this is failing.

[James R. Ferguson · Accepted solution]

Hi:

What information can you find in logfiles? Is there an error (particularly an 'errno') reported anywhere?

Regards!

...JRF...

[Pete Randall]

A quick review of the pipes man page suggests looking at:

[EMFILE] NFILE-1 or more file descriptors are currently open.

[ENFILE] The system file table is full.

[ENOSPC] The file system lacks sufficient space to create the pipe.

[ENOSR] Could not allocate resources for both Stream heads (STREAMS-based pipes only).


Pete

[OldSchool]

well....nothing jumps out at me.

seems this is 1) intermittent and 2) they didn't bother to say anything until the logs had rotated off to tape.

vendor has noted some file permission issues that may be a problem.

I'll get back w/ more as it develops

thx...scott

[A. Clay Stephenson]

Universe eats files descriptors for lunch. It's very common on those boxes to need to set nfile in the 100000+ range. You might also need to increase maxfiles (and maxfiles_lim).

When you see problems issue some sar -v 2 2 commands and see if you are near the file-sz limit. If so, increase nfile; if not increase maxfiles and maxfiles_lim and make maxfiles_lim > maxfiles.

[Steven E. Protter]

Shalom,

http://www.hpux.ws/system.perf.sh

Maybe if you have glance check high water mark on kernel parameters.

Increase nfile,nproc and maxuprc

If the app uses shared memory, check shmmax shemseg

SEP

[OldSchool]

sooo....

monitored the system tables most of yesterday. Rebooted server last night, and monitoring continues.

As far as the monitoring goes, none of the high-water marks exceeded 50% (so far) and are usually <25%.

Application vendor supplied a list of directories to clean out. One of them had several *thousand* pipes, some dated as old as 2004. Given the permissions and the naming scheme for the pipe, it seems likely that the application attempted to make a pipe that already existed for another user.

Since the problem is intermittent, we are still waiting to determine if it is resolved.

I'll update this and assign points later (when I've got something more conclusive).

In the mean time, me and my baseball bat may be paying a visit to some (cough) application developer

Thanks for the responses to date

[A. Clay Stephenson]

So this thing is using named pipes? If so, clearly the cleanup routine is not being called in all cases which is probably the result of either the developer never being told there was something called a signal handler or someone has a habit doing kill -9's.

[OldSchool]

it gets the *ahem* occassional "floating point exceptions" in some locally written code, and procedes to bail out w/o clean-up.

now, where did I put that bat?

[Dennis Handly]

>it gets the *ahem* occassional "floating point exceptions"

These are typically integer divide or remainder by zero.

[OldSchool]

">it gets the *ahem* occassional "floating point exceptions"

These are typically integer divide or remainder by zero."

yep, I know. The developer "can't be bothered with it. It doesn't happen very often"

oh, well. it's been a week since i cleaned out the mess and rebooted. user's haven't complained. I'm going to close this.

thanks for all the responses!

scott

[OldSchool]

i appears to be related to trash left behind when the app crashes.