Comments (2)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 RFS commented Permalink

A couple of questions? <div>&nbsp;</div> 1) Does the run queue count include the currently executing threads or just those waiting for CPU resources? <div>&nbsp;</div> 2) In this example, should I only be concerned if the run queue is &gt; 300 for sustained period?

2 nagger commented Permalink

On AIX and reported by nmon, vmstat, topas and others the run queue is the number of runnable processes that could use CPU cycles right now. Some of these will be on the CPUs and some waiting to get CPU time (assuming there are enough of them). For part 2) For maximum throughput you wan the number to be greater than 300 (or the total number of SMT threads (CPU cores times 4 for SMT=4) also called the logical CPUs) so that if some of the processes on the CPUs hit something they have to wait for like locks, disk I/O network packet responses, memory to be freed then there are other process threads that can use the CPU cycles. More of a worry for me (as a performance speed junky) is a smaller run queue like less than half the SMT threads = badly designed application, not enough user activity or a LPAR that is over configured in CPU resources at could be used better else where. <div>&nbsp;</div> If you use the "ps -el" command and look at the WCHAN column then the processes with a item in this column are the ones that are not runnable and so are not on the run queue as they are waiting for an event like terminal, disk or network I/O or locks or inter-process communication. The WCHAN is called the Wait or Sleep Channel and it actually the AIX Kernel address of the data structure it is waiting for the resource to be available event. When the kernel puts data in the resource it puts the processes waiting on the run queue so they can take actions on the newly arrived data. <div>&nbsp;</div> Hop that helps, Nigel Griffiths