Topic
  • 2 replies
  • Latest Post - ‏2013-10-16T09:52:48Z by nagger
*$*$
*$*$
1 Post

Pinned topic CPU Utilization on Virtualized LPAR

‏2013-08-22T09:13:57Z |

I have a LPAR running with 18 physical CPU and 36 Virtual CPU. System shows high no of blocked kernel threads even though system utilization is very low. I have cross-verified other LPAR in the frame where this server is located, none of the other server don't see similar issue.

Below is the vmstat output ran for few intervals.

do over allocation of CPU in virtualized server create such situation where kernel threds got blocked. Need help on this and some ref if available.

------- --------------------- ------------------------------------ ------------------ -----------------------
  r   b        avm        fre    re    pi    po    fr     sr    cy    in     sy    cs us sy id wa    pc    ec
 18   2   16936257      58649     0     0     0 10869  22640     1  1190  24611  7971  4  2 93  0  3.75  20.8
 15   1   16933818      60046     0     0     0   644    899     0  1858  31738 11159  7  2 91  1  3.44  19.1
 12   4   16934413      60573     0     0     0  5912   7403     0  2487  50250 11672  5  2 92  1  2.80  15.6
  3 126   16931302      59782     0     0     0     0      0     0  2441  33292 11288  5  2 93  0  3.05  16.9
  6   4   16931222      58812     0     0     0  2204   3094     0  1914  35410  9558  4  2 94  0  2.47  13.7
 14   4   16937056      58621     0     0     0 10030  13255     0  2637  26474 11913  5  2 93  0  3.34  18.6
 12  12   16934191      59632     0     0     0  1287   1494     0  2336  32126 11596  2  2 95  0  2.47  13.7
 35   3   16931470      59002     0     0     0   482    532     0  2377  15338 11404  1  2 97  0  3.32  18.5
 79  40   16931389      58908     0     0     0  4921   6188     0  2671  50879 11567  2  2 96  1  2.01  11.2
  5   4   16928984      59427     0     0     0  1679   2255     0  2483  21487 12828  1  2 96  1  2.35  13.0
 44   3   16931353      59110     0     0     0  6209  10409     0  2127  45339  9981  2  2 96  0  2.29  12.7
 42   6   16930750      59922     0     0     0  4217   4913     0  2531  27110 11971  2  2 96  0  3.03  16.8
 23   4   16928104      61943     0     0     0  4909   6098     0  2314  62364  9589  3  3 95  0  2.76  15.3
 10   5   16928025      58660     0     0     0  1032   1603     0  2068  43995  9808  2  2 96  0  2.70  15.0
  7   1   16928025      58703     0     0     0  4562   7326     0  2669  30330 12035  2  2 95  1  1.71   9.5
 19   3   16930743      58644     0     0     0  6656   9888     0  2274  47071 10054  2  2 95  0  3.23  17.9
 17   4   16932009      58592     0     0     0  4754   5664     0  1930  21942  9773  2  2 96  0  2.74  15.2
  5  11   16930851      58762     0     0     0  3850   6654     0  2514  65087 10526  3  3 95  0  3.31  18.4
 24   3   16925189      60201     0     0     0   399    534     0  2428  50163  9829  2  2 95  0  2.62  14.6
  7   2   16925190      58754     0     0     0  1819   2593     0  2064  20712 10383  1  2 97  0  2.30  12.8
 kthr          memory                         page                       faults                 cpu
 

 

Sunil

 

  • GarlandJoseph
    GarlandJoseph
    167 Posts

    Re: CPU Utilization on Virtualized LPAR

    ‏2013-09-26T20:59:46Z  

    Too vague.  I do notice that vmstat output spiked with 79 runnable threads.  Post process stack of one of these threads. use dbx or kdb.

  • nagger
    nagger
    342 Posts

    Re: CPU Utilization on Virtualized LPAR

    ‏2013-10-16T09:52:48Z  

    So you don't have a problem at all but are worried about occasional  peaks in AIX kernel internal resources. I suggest you take a deep breath, let it out slowly and relax.  Then say to yourself "Trust the AIX, Sunil, trust the AIX."

    It you don't have a problem - don't try to fix it!  And are the other VM running the same application code under similar loads.

    The only way to determine what the kernel threads are doing is to raise a PMR and have a perfPMR ready. That seems like a lot of work to do just to understand a curious number.

    Cheers, Nigel Griffiths