rob@xxxxxxxxx wrote on Fri, 24 Jul
2015 19:39:44 GMT:
From HMC:
Shr Shr
LPAR Min Mode Assg Max Wgt Pool
RACK1HST 0.10 UnCap 0.50 1.00 128 IBMi
Based on "HST" in this LPAR's name, I'm guessing it it the one
doing the hosting? Does this LPAR also have collect performance
ticked so it will capture CPU and memory for the whole system
not just itself?
Where do I check:
<snip>
I'd be looking at whether or not collection services is
reporting queuing for the virtual disks.
</snip>
I've seen disk arm utilization today was around 65%.
Where would I see if it was "reporting queuing"?
Even at 65%, I'd think there could be queuing reported in the
client LPAR. iDoctor has a chart for this. I don't recall if
Performance Data Investigator (PDI) has included this chart or
not, but perhaps easiest is to use PDI to look at QAPMDISK and
create your own table or graph to see what the average queue
length is with the formula DSQUEL/DSSMPL.
But maybe you don't need to go to all that work. Simply look at
the response times graph. If wait time is a significant
component of overall response time, you're queuing and a
solution is likely more "disk units". In this case, virtual
disks from the hosting LPAR.
I suggest you contact support line too. I've heard of a
performance issue at your firmware level with IBM i hosting i
but I don't think it's for the model of machine you have. I do
not recall which model (getting old, I guess).
Another thought, memory in the hosting LPAR and on the system
.... do you have any way to give more to the hosting LPAR? All
those CPU cycles driving it to >100% may be due to paging in
support of the client LPARs. With more memory, it may not need
to do that.
Last thing you probably want to hear, but if all the LPARs are
consuming what's been allocated, it may be time to get another
license of i on the system so can allocate more CPU to the
hosting LPAR.
As an Amazon Associate we earn from qualifying purchases.