General discussion

Locked

sar -m shows high # semop calls on HPux

By JeffreyMangan ·
I run a warehouse management system app on HP-UX 10. The app uses Oracle DB.
When users report the application is very slow I can almost always do a sar -m and find the # of semop calls is over 600. This seems to be the magic #, When it goes over 600 as high as 1200, the application grinds to a halt. The OS,App and DB do not report any errors during these periods of high semop calls. Nothing is starving for a semaphore. What exactly does # of semop calls mean? Who is making those calls? Is this something I can adjust or did I need to find out what's making the calls and make it stop?

This conversation is currently closed to new comments.

5 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Comments

Collapse -

sar -m shows high # semop calls on HPux

by Shanghai Sam In reply to sar -m shows high # semop ...

A semop call is made by a program, most likely in your case, the back end of an Oracle query. If you are getting over 600 of these when you don't think you should then either there are a lot of users accessing the database, a query intensive routine is running or you have a corrupted program that is running away with an unending loop of calls and other commands. The later is not as likely but is possible. The later may also be caused by a user passing incorrect parameters into a query or statement. With that being said 600 shouldn't be considered terribly high for an HP-UX server (depending on available RAM and CPU). If you want to know if the root cause is a run away program you may consider using ps -ef when users the value is over 600. Record what database processes are running (orcale, sql, etc. - anything that hits the database) and record what users are controlling these processes. After a few times you may find a common thread and you can work with the DBA to resolve it.I don't think this is really the problem, but it is worth a little effort to be sure.

There are kernel parameters that can be adjusted to allow a much smoother flow of the Oracle instances. You should work with your Oracle DBA when adjusting these and he should have some recommended settings, but here is what is most common for Oracle on HP-UX 10.

Note that these are only baseline recommendations.
I received them at a Uix and Oracle Performance Tuning class.

I'll list the parameter settings in a separate answer. It is too long for this one.

Collapse -

sar -m shows high # semop calls on HPux

by JeffreyMangan In reply to sar -m shows high # semop ...

Poster rated this answer

Collapse -

sar -m shows high # semop calls on HPux

by cpfeiffe In reply to sar -m shows high # semop ...

Here are the kernel paremater settings

shmmax - At least 60% of RAM. Must be bigger than total SGA for all instances. Also must allow shmseg to divide into it. If 60% (or more if needed to allow shmseg to divide into it) of RAM is less than the total SGA then work with the DBA to reduce SGA allocations or increase RAM in the server

shmmin - 1. minimum size (bytes) of a shared memory segment.

shmseg - around 25 X number_of_instances. Should be divisible into shmmax.

shmlba - 5X number_of_instances. Controls the alignment of shared memory segments. All segments must be attached at multiples of this value

For the following parameters proc is the sum of all "processes" values in each instance's initSID.ora file.

semmns - should be greater than (2 X proc) + (10 X number_of_instances) + 15%

semmsl - round figure no smaller than the smallest "processes" value in any initSID.ora file.

semmni - proc / semmsl + 15%.

As values are changed in Oracle configurations (initSID.ora files) it may be necessary to change these parameters as well. Oracle needs to maintain a very close and comfortable working relationship with the underlying OS for optimal performance. The differences between a properly tuned system and one that is not are overly magnified when databases are involved. You may be surprised at how much better your performance is (even under the 600 threshold) after adjusting these parameters.

I hope this all helps.

Collapse -

sar -m shows high # semop calls on HPux

by JeffreyMangan In reply to sar -m shows high # semop ...

I took this info to our Unix guys and it lead to the solution. Thanks. This has plagued us for months.

Collapse -

sar -m shows high # semop calls on HPux

by JeffreyMangan In reply to sar -m shows high # semop ...

This question was closed by the author

Back to Linux Forum
5 total posts (Page 1 of 1)  

Related Discussions

Related Forums