Re: Guested lpar shows high disk arm utilization while Host lpar shows high CPU utilization

At one of the site I am supporting, we had a major slow down, high disk percentages and low CPU usage. After investigating we found a RAID controller with a bad battery. The system went turned off cache processing whilst the batteries charged up. It took hours.

You may have a bad battery on a controller, if the controller is an older controller.

Darryl.

Sent from my iPad

On Jul 27, 2015, at 7:46 AM, rob@xxxxxxxxx wrote:

Thank you for your reply. I'm mulling this over.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Sue Baker <smbaker@xxxxxxxxxx>
To: midrange-l@xxxxxxxxxxxx
Date: 07/25/2015 09:32 AM
Subject: Re: Guested lpar shows high disk arm utilization while
Host lpar shows high CPU utilization
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



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.


--
Sue
IBM North America Advanced Technical Sales Support (ATS) Power
Systems
Rochester, MN

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.