Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

some questions about performance

Status
Not open for further replies.

holdahl

IS-IT--Management
Apr 4, 2006
213
NO
does it usually indicate problems/bottleneck with the disks when the wait cpu% is high?

get this from ps on one of our AIX boxes:

$ ps -Ao pcpu,pmem,vsz,comm,user | head -10
%CPU %MEM VSZ COMMAND USER
0.0 0.0 64 swapper root
0.0 0.0 844 init root
14.0 0.0 48 wait root
14.3 0.0 48 wait root
14.5 0.0 48 wait root
14.4 0.0 48 wait root
14.4 0.0 48 wait root
14.3 0.0 48 wait root
0.0 0.0 48 wait root

what does a high number of VSZ indicate?

user@machine:/home/siho> ps aux | head -1; ps aux | sort -rn +3 | head
USER PID %CPU %MEM SZ RSS TTY STAT STIME TIME COMMAND
u_nlag 1077278 0.1 1.0 60960 31704 - A Aug 27 21:09 java -DbrCommon
u_nlag 1015910 0.1 1.0 70656 48336 - A Aug 29 11:54 java -DbrCommon
u_nlag 1003704 0.1 1.0 44608 24152 - A Aug 29 14:06 java -DbrCommon
u_nlag 970826 0.1 1.0 71008 46284 - A Aug 29 11:38 java -DbrCommon
u_nlag 831566 0.1 1.0 74644 43896 - A Aug 29 14:57 java -DbrCommon
u_nlag 807156 0.1 1.0 43988 27092 - A Aug 29 14:49 java -DbrCommon
u_nlag 630918 0.1 1.0 45288 28564 - A Aug 30 18:29 java -DbrCommon

could the java processes affect overall performance?
 
If the CPU is always in wait (%wait is high) then yes this usually indicates a possible disk bottleneck!

That's what the vsz indicates:

Code:
vsz 
Indicates, as a decimal integer, the size in kilobytes of the core image of the process. The default header for this field is VSZ.

The above can be found in the ps man page:


Java processes, from my experience, usually hits the RAM! But after all it depends on what exactly that java process is doing!

Regards,
Khalid
 
You'd have to measure the [tt]%idle[/tt] and [tt]%iowait[/tt] with [tt]vmstat[/tt] or [tt]sar[/tt], because "[tt]wait[/tt]" processes do not differentiate between those two wait states.

There are as many [tt]wait[/tt] processes as there are CPUs. And that's all they do: wait, as a CPU can't sit around doing nothing, it has to run instructions all the time. So if there are no user or kernel processes ready to be run, a CPU runs a "[tt]wait[/tt]" process.

That being said, Java hits the RAM and the CPU, but it can also hit the disks if you don't have enough RAM, so it can induce paging and disk I/O and hence [tt]%iowait[/tt]...


HTH,

p5wizard
 
Thanks for the answers.

I have also been getting some messages from my monitor tool about high scan rates:
Fatal: Scan Rate is averaging 18155 scans per second. Consistently high scan rates indicate a physical memory (RAM) shortage and contribute greatly to reduce overall performance.

How do I check this further to see what might cause the problem?

 

Oh the wait processes... And as I've said before that's a POWER architecture flaw as most others incl. x86 can stop the processor. When's IBM going to implement this...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top