1829924 Members
2515 Online
109997 Solutions
New Discussion

socket.h

 
Dave La Mar
Honored Contributor

socket.h

We are tuning oracle 8.1.7 with reference to allowable ftp connections.
Being ignorant in the HP-UX 11.0
environment, I have been looking at increasing the SOMACONN value in socket.h.

Can anyone shed some light here?
1. I would like to increase the number of ftp connections allowed.
2. What values have you used?
3. Will changing this value accomplish what I am asking on the OS side or are there other parms to consider?

It looks as though this file is used in a kernel rebuild as well as C compiles (from other posts). Thus, I do not have a level of comfort in changing the value.

Appreciate any and all input.

Thanks.

dl
"I'm not dumb. I just have a command of thoroughly useless information."
13 REPLIES 13
Mike Hassell
Respected Contributor

Re: socket.h

Dave,

Are you reaching the maximum number of ftp sessions allowed? Are ftp sessions being refused? The default ftp that ships with HP-UX 11.0 determines the maximum number of ftp connections via the kernel parameter "NPROC". NPROC by default is based on "maxusers". To change these the easy way, you can use SAM to edit the kernel paramters to meet your needs and then let it rebuild the kernel and reboot the box.

Now lets make sure we're on the same page here. Are you referring to the amount of outgoing ftp connections using the ftp client that ships with HP-UX 11.0 or are you referring to the amount of incoming ftp connections via the ftpd server?

The above refers to the amount of ftp traffic outgoing. I'm a bit confused on how Oracle comes into play here, other than it running on the server where these ftp connections are taking place.

Hope that helps.

-Mike
The network is the computer, yeah I stole it from Sun, so what?
Dave La Mar
Honored Contributor

Re: socket.h

Mike -
The problem, rare as it is, affects incoming ftp connections.
I believe our nproc setting is tuned correctly as I see no outgoing problem.

I am basing my questions on documentation from metalink.oracle.com and on the occasional failure to connect we see on mainframe jobs opening a connection to the HP-UX server.
We have found no reason for the failure to connect as when the mainframe job is re-run all is fine.
Currently, SOMAXCONN is at the default of 20.
I am looking for input on ramifications of upping the value.

Thanks for the input Mike.
dl
"I'm not dumb. I just have a command of thoroughly useless information."
Mike Hassell
Respected Contributor

Re: socket.h

Dave,

Ok, then we're looking at the ftpd server itself accepting connections from clients. If you're using HP-UX 11.0, I think it ships with wu-ftpd, running from inetd. Check the following:

1. Check your /var/adm/syslog/syslog.log for errors from ftpd.

2. Check to ensure that you have ftpd logging errors and such to your syslog via:

/etc/inetd.conf

Which should contain a line similar to:

ftp stream tcp nowait root /usr/lbin/ftpd ftpd -l


The -l tells it to log information to the syslog. You can also add a -v to tell ftpd to log even more information for troubleshooting purposes.

Note - if you make changes to /etc/inetd.conf you'll need to have inetd re-read it's configuration:

inetd -c

3. Verify the port that ftpd is running on:

more /etc/services

The above should contain a line for ftp on port 21.

4. If all else fails do a:

man ftpd

This should give you all the related configuration files.

How many users are trying to connect at one time? Do you have a rough estimate?

Hope that helps.

-Mike
The network is the computer, yeah I stole it from Sun, so what?
Mike Hassell
Respected Contributor

Re: socket.h

Dave,

I forgot to mention the /etc/ftp/ftpaccess file that might contain a limit statement in it, such as:

limit all 10 Any /etc/msgs/msg.dead

Where 10 equals amount of concurrent connections allowed.

Here is a good resource for more wu-ftpd information:

http://www.landfield.com/wu-ftpd/

Good luck.

-Mike
The network is the computer, yeah I stole it from Sun, so what?
Dave La Mar
Honored Contributor

Re: socket.h

Very good Mike. But my concern is the tuning to oracle documentation specificly noting SOMAXCONN.

I have a good feel for this being the problem when it does occur which, as mentioned, is seldom.

Have you made a change to this include file?

Or, is the doc from Oracle all wet?

dl
"I'm not dumb. I just have a command of thoroughly useless information."
Dave La Mar
Honored Contributor

Re: socket.h

Sorry Mike, yes we are 11.0.

The access file shows the following three limit lines:
limit local 20 Any /etc/msgs/msg.toomany
limit remote 100 SaSu|Any1800-0600 /etc/msgs/msg.toomany
limit remote 60 Any /etc/msgs/msg.toomany
"I'm not dumb. I just have a command of thoroughly useless information."
Mike Hassell
Respected Contributor

Re: socket.h

Dave,

What Oracle documentation are you referring to in particular? I searched for "SOMAXCONN" on technet.orcale.com in the 8i documentation section and came up empty.

Please provide us with an excerpt of the documentation so we can put it into context for you. I would doubt that Oracle would reocmmend that you alter socket.h manually.

-Mike
The network is the computer, yeah I stole it from Sun, so what?
Dave La Mar
Honored Contributor

Re: socket.h

Attached, you will find the doc.
Note is note specificly HP-UX 11.0 but does address the problem with the same parm used in 11.0.

dl
"I'm not dumb. I just have a command of thoroughly useless information."
Patrick Wallek
Honored Contributor

Re: socket.h

The document you attach is talking about problems when trying to connect to the Oracle LISTENER process. This has NOTHING to do with FTP'ing to the machine.

Are you getting any errors on the machine that is doing the FTP when the connection fails?
Dave La Mar
Honored Contributor

Re: socket.h

Patrick -
That is correct but according to HP docs, as well, it does apply to ftp socket connections.
On the ftp note, all we see is a connection failure. It is extremely difficult to re-create since an immediate re-run works fine.
Our thought is it is tied to this
parm and the activity on the OS at the time.
For the oracle perspective we see it affecting process connections.

Am I making this any clearer?

dl
"I'm not dumb. I just have a command of thoroughly useless information."
Mike Hassell
Respected Contributor

Re: socket.h

Dave,

After reading your attached document and searching around the web for more info, I've come up with the following that might assist you.

First, lets look at each problem on it's own, since the ftpd and Oracle listener process are different processes accpeting incoming connections on the same TCP/IP stack.

FTPD:

1. If you are receiving error messages in /var/adm/syslog/syslog.log that state that ftpd has reached it's maximum number of connections, then alter:

/etc/ftp/ftpaccess

And change the limit parameter to allow more concurrent connections for each class (local/remote). This will ensure you're not reaching a barrier with the ftpd configuration itself.

Oracle listener:

1. The document discusses the listen() system call, being the root cause of the problem you may or may not be experiencing. Thus, one would assume you might be reaching a full listen queue from the OS side, but I don't know of any way to edit something like this as this is a hard coded part of the sockets and TCP/IP code. However this may be accomplished using 'adb', but I would wait before looking into that further.

2. I would start by looking at some samplings of the output of 'netstat -a' on the server in question and times when you are experiencing this problem. This should give you and idea of the sockets and their states with the various clients trying to connect.

3. I would also ensure that you have the latest patches for HP-UX 11.0 with regards to transport and steams.

Also, ensure that you feel confident that your underlying network is providing adequate response times from the HP-UX server and it's clients. I would also open up a support call with HP to provide them with this information, so they can escaliate it up the chain.

Someone like Rick Jones should be able to provide you with the right information about how to solve your problem, if indeed you are filling up the listen() queue.

Hope that helps, good luck!

-Mike
The network is the computer, yeah I stole it from Sun, so what?
Dave La Mar
Honored Contributor

Re: socket.h

All good advise. Thanks Mike.
When and if we have the direct cause and resolution, I will post.

dl
"I'm not dumb. I just have a command of thoroughly useless information."
Martin Johnson
Honored Contributor

Re: socket.h

I would also open a call with oracle. That way if HP says it is not their problem, you haven't wasted your time.

HTH
Marty < Who had to wait a week to be told his MeasureWare for AIX problem was IBM's problem>