The PID on the top cross reference that with this command:
ps -ef|grep <PID>
have you checked out
topas
This will show you what application/process is taking up the CPU usage. But based on the lpar stats there is nothing to tell you what is causing the issue.
Hi ,
Thanks for your reply techy, I am not experienced in monitoring stuffs, ill try to post your required details while causing today.
Actually that was an impact when user are high during business hours.
It was normal now. OBIEE app is running in this server.
I checked the Process, disk IO, network traffic at that time. I suspect only the nqsserve (BIP owner ) process consuming more usage.
I only have this output which i executed yesterday,
Yesterday During Business Hours
----------------------------------
It is close to it's entitled capacity (up to 95%), but did not hit the 1.3 processing units.
There could also be tuning capacity in the application. I found this here you might have a look into: https://blogs.oracle.com/pa/entry/test
There is a link, I can not access since I have no account there anymore: https://support.oracle.com/rs?type=doc&id=1333049.1
Check the document and see if your box is tuned as they advise. This document also exists for 10g.
Also maybe setup nmon to monitor your AIX LPARs. Will be easier to check when customer says it was slow 10 mins before he calls and you have no history.
I've come across some oracle servers were I/O was a problem causing CPU problems.
I would high suggest as well to setup nmon reports and monitor these for a day or two, to really give you an idea of what your system is really doing. the 1.3 seems odd, and defiantly uncapped is best if allowed, but keep in mind as well if there is some config problem going on uncapping the server is going to be a pain for your other lpars.
First i'd adjust the CPU to maybe 1.6 or personally i would go for a min of 2 on a oracle server.
Ensure nmon is installed on your server and add this line to the crontab:
So, this is a partitioned server. It has an allocation of 1.3 CPUs. I'm assuming therefore that there are other partitions defined, and perhaps a little spare CPU on the chassis as a whole. If the partition is capped, then it will use up to 1.3 CPUs and no more. If it is uncapped and there is spare CPU then it will burst through the limit and you will see the value for entitled CPU on sar or vmstat exceeding 100%.
If you take the cap off the partition and other servers are busy, they will be guaranteed to get their allocated CPU as a minimum, however as already pointed out by Zaxxon, you are not CPU bound (95% entitled capacity)
Consider partitions:-
1.3 CPU shared
3.0 CPU shared
2.0 CPU dedicated
1.7 CPU shared
Server has 8 CPUs. Two are dedicated, so out of the reckoning. If the shared CPU partitions are all uncapped, then if the other two are idle, the busy one could get 6 CPUs. If all are busy, then they will be limited as shown. If partition 4 is idle and 1 & 2 are busy then they will compete for the spare CPU (after both have reached their entitled CPU limit) and you can weight them to show a preference.
You may be better just upping your CPU allocation a little then re-activating the partition (not just a reboot) else your end user will get used to having the full spare CPU available and then complain when it's in use elsewhere on the chassis. Is there another partition you could squeeze down, but take the cap off because it is rarely busy?
We have our set as 0.1 CPU, production uncapped, test/dev capped.