Connections on I/O port

[Archana Prasad]

Hi,

We are running an Oracle database on a K460 server. How can I determine the maximum number of simultaneous connections on the I/O port? Is there an OS limit on this? Can this be configured? Any help is appreciated.

Thanks in advance,
Archana.

[Rick Garland]

There is a HP unsupported command called "lsof" that can give this information. The source is available from the HP pporting archive

[Andreas Voss]

Hi,

lsof is a tool to get all open I/O connections of all processes.
You can get it here:
http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.48/

Regards

Andrew

[Archana Prasad]

Hi,

Actually this question belongs to the database sub-group. I actually need to find out the maximum concurrent connections returned via the listen() system call. Also, is there a kernel parameter that can be configured (maxconn?) to increase this on HP-UX 10.20. What is the upper limit for this parameter?

Thanks a lot!
Archana.

[RikTytgat]

Hi,

Actually, you're talking about socket connections.

The number of systemwide socket connections is only limited by the nfile kernel parameter (the open files limit).

However, the server-end process (the daemon, in your case the listener) issues the listen(2) call, in which it specifies a queue depth, i.e. the number of unhandled connection request from clients. This does not mean that this limits your total number of connections with thge server. It only means that the number of 'hanging' connections is limited.

To find out the number of simultaneous connections to your listener, you can issue the command:

netstat -an | grep 1521 | wc -l

If your listener does not listen on the default port 1521, change the 1521 to whatever port it is listening on.

Hope this helps,
Rik

[Kofi ARTHIABAH]

Actually Rik, you might want to eliminate other entries that might be grepped such as entries with 11521 and so you might modify the construct to read:

# netstat -an | grep \.1521 | grep ESTABLISHED | wc -l

[Anthony deRito]

Be careful here. If you grep on ESTABLISHED you will not see the connections made over the local UNIX domain protocol. You will see all connections made over tcp. If you are doing local connections via SQLNet then this will be important to you. If not then don't worry about it. Hopefully you are not using the tcp protocol if you are doing local connections. Use the local UNIX protocol (type "man unix"). To use this you will need to make sure there is a entry in your listener.ora file for the IPC protocol. To see how your sockets are being established, install the lsof utility as mentioned and run the big_brother script that is in the scripts directory. It will show you real time socket connections. Then make a connection to the database. If you see a socket established over tcp and you are doing local connections, then you need to talk to your DBAs and introduce them to the local unix domain protocol. I cut database access times in half by changing this!!

Tony

[Archana Prasad]

Hi,

Thanks! Sorry I am unable to award any points (can't see the hypertext link).

nestat -an displayed the current active connections. However, what if 50 people simultaneously tried to connect to the listener. Is there any way resources can be pre-allocated in anticipation for such a request?

Thanks,
Archana.

[RikTytgat]

Hi,

There should be no need to pre-allocate resources. I don't even think it can't be done.

The only potential risk is that the odd connection gets refused because te listen queue depth has been reached, but there is little chanc that this will happen.

You might monitor the evolution of the number of open files on your system, so you can anticipate it filling up completely.

You can do this using glance or sar -v.

Bye,
Rik.

[Archana Prasad]

Hi,

I think that helps with most of my questions with the exception of the listen queue depth. Can the listen queue depth be configured manually via a kernel parameter? Thanks again!

Archana.

[RikTytgat]

No, the queue depth is passed as an argument to the listen call (man 2 listen).

From the listen(2) manpage:

"backlog defines the desirable queue length for pending connections. The actual queue length may be greater than the specified backlog . If a connection request arrives when the queue is full, the client will receive an ETIMEDOUT error."


So, it is not configurable by means of a kernel parameter.

The application might offer the possibility to configure it, but I can't see where this could be done in case of the Oracle listener.

Bye,
Rik

[Vikas Khator]

Hi Archana,

You might want to keep in mind that maxuprc might limit the number of connections .

As each user connecting using listner connects to the box as user oracle , you may run out of processes allowed for user oracle as defined in the kernel thru maxuprc.

Hope this helps.