Semaphores operations

[David_246]

Hi,

As I still have to deal with a high systemload (15), I continue my search using this forum. My previous question about pages freed: http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=364995
Gave me an answer not a solution.

I also have a lot of Semaphore activity. Now I read the switch of processes may increase the number of semaphores. Our standards again tell me that 80 Semaphores operations are quiet the limit. Now sometimes we reach 4000 operations per second in certain times. Should I worry? Or is it just a program that's doing a great job.

Regs David

[Stuart Abramson_2]

Are you having performance problems?

I try not to worry unless someone says he's getting poor response - i.e. - someone is complaining.

[David_246]

Hi Stuart,

Yes indeed our server is really having a hard time when the load reaches 15. As an example Patrol should poll every 1 minute, the polls are during this load at least 2 minutes. Customers do not work at this time, but what if these high load moves to daytime :(

Regs David

[A. Clay Stephenson]

Without knowing your software, it's not possible to say what is a "good" sema4 operation rate and what is a "bod" rate. It truly depends upon how the software was written. You really have to ask the software designers. Context switch rates would be a good thing to know. The very first thing to check is the setting of timeslice --- it's just possible someone "improved" it and set it to 1 rather than something very near 10.

[Steven E. Protter]

Probably time to collect a little data in the background.

see script.

attached

SEP

[David_246]

Hi SEP,

Great script! I assume this script needs to be run when the high load occurs? This is 03:00 and 06:00 MET, I need to schedule this for tonight then.
Will you be there to read it? It's quiet some info of our systems.

Regs David

[David_246]

Sorry Clay, timeslice is still at 10.

regs David

[A. Clay Stephenson]

Actually, performance gathering scripts should be run at both "good" and "bad" times. It's much easier to spot problems when there are clear differences to distinquish. For example, is "50 apples" bad? Beats me. However, if I know that apples was 10 and things were good and now apples is now 50 and things are bad them the "apple" statistic may be telling me something -- or it might be a non sequitur. This is really Performance Tuning 101. The best method is to periodically gather statistics (e.g every 10 minutes) and then analyze them.

This is why tools like MeasureWare are so useful they gather data on a very regular basis without imposing too much in the way of overhead themselves. I would load the Trial version of Glance and use it to look for your problems.

[Stuart Abramson_2]

If your system load is 15, then maybe your poor system is just overloaded. We rarely get loads higher than 3.

[David_246]

When we run a simple backup, our load jumps onto 11. It might be a small system, but a system should at least survive it's own backup? (Legato Networker)

I will have the extra info-files ready on monday.


Regs David