Question on Semaphore/Socket waits

[Tony Drake_2]

I have an N Class system running SAS and Oracle that I have been working on trying to resolve performance issues.

In Perfview, when I look at the statistics, I see a lot of SOCKT and SEM waits.

I have searched documentation and the forums, and can't seem to find the answer to the following question:

What is the meaning of a socket wait:
A) Process is waiting for a socket (the system does not have any sockets to assign, so one has to be "freed" from another process.
B) Process is waiting on a socket (the process has connected to another process/system via socket and now is waiting for a request sent over that socket to complete or be responded to before the waiting process can continues)
C) Either a or b with no way to tell the difference

I also see large numbers of SEM waits on Oracle processes. I have the same question:
is it
A) Waiting for a semaphore to be available to it can use it to lock something
B) Waiting on something that is semaphore locked to become available
C) either a or b, with no way to tell the difference

I have always noticed large numbers of sem waits on Oracle systems, but have never been able to find out what is "typical" sem wait percents, and what is "abnormal" indicating a problem.

Your responses appreciated. Points will be assigned.

Thanks.
Tony

[RAC_1]

About sockets.
System running out of sockets. Application should take care of it. If a socket does not get a response on a socket for a particular time, it should close the socket. There is also a ndd option as tcp_fin_wait_2_timeout.
which would close a tcp connection in fin_wait_2 after a certain period.

Look at the following thread.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=701847

About Semaphores.
there are certain kernel parameters that you can set to keep tak on max limit on sems. Also does'n oracle process make it free once it is done. Set the semaphores setting reasonably and check. If it still waits on semaphores, you can bump up the value.
Check following link to tune semaphore related kernel settings.

Anil

[Sridhar Bhaskarla · Accepted solution]

Hi Tony,

You got answers for yourself.

1. Modify B slightly. The process is waiting to get a response from the other end of the connection. To understand it better, run 'tusc' on the process and you will see the process waiting to get a response from the file descriptor corresponding to the socket.

2. B again.

There is no hard and thumb rule on typical wait percentages. It depends on how your application works. Remember that these are percentages. 9 of 10 is 90% and 9000 of 10000 is also 90%. Both are mostly dependent on your application behaviour.

Typically sockets are deemed file descriptors and are reflected in the 'number of open files'. So if you are running out of them, then you should be seeing 'filetable overflow' messages. Similarly you should see 'semaphore table full' in your perfview stats.

-Sri