× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thank you Rob, Patrik, and Jim.

Rob,
Thank you for the tips on the vendor tools. I located the one you were
referring to.

Patrik,
I have been reading the "Work Management" manual, and I must admit, it's
taking me longer than I'd like to understand the pieces. But I'm trying.
That article you shared on "Post-Install Optimizations" is very practical.
Thank you.

Jim,
I have not set up a memory shared pool in the hosting partition for
virtualization I/O, but I will do that in my testing environment ASAP.
I found this Midrange archive post talking about that, so thanks for
pointing me in that direction:
https://archive.midrange.com/midrange-l/201304/msg00907.html

+1 to all three of you.

-------------
Jacob
-------------

message: 1
date: Thu, 22 Aug 2024 09:42:22 -0500
from: Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
subject: Re: Memory and CPU Considerations for IBM i LPARs

Have you by chance set up a memory shared pool for your hosting environment,
putting memory in there? That will force the I/O operations that IBM i
virtualizes into that memory pool giving you significant control over it.
Now you can size it large enough to avoid I/O issues with the hosted
environments and isolate that activity away from *BASE.

If you have not moved the hosted environment into its own shared pool(s)
then all that work and the work the host does in *BASE is mixed and
interesting things can show up and hamper operations. I said "interesting"
because hosting certainly can stay in *BASE successfully, but it's not in my
view a best practice, unless that's the only thing IBM i does is host the
other environments.

As to CPU and memory in the partitions you assign those in the HMC, so each
partition has its own memory/CPU (Assuming you don't have memory sharing
turned on) and CPU can vary if you have the processors set to uncapped.



--
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On Wed, Aug 21, 2024 at 4:08?PM Jacob Banda via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

So I have a new Power 10 set up with IBM i hosting i and Linux
partitions, managed with V10R3 vHMC. I have a good understanding of
the workings of Processing Units (PU) vs. Virtual Processor (vCPU)
allotments in the partition profiles and have been monitoring the
workloads with the HMC Performance Dashboard for Average and Maximum CPU
consumption.

My questions are regarding assigning sufficient CPU resources to the
client partitions and identifying memory usage in the IBM i client
partitions.

1. How the heck do I identify just how much memory is required for my
workloads in an IBM i partition? DSPSYSSTS just seems to dump the
total system main storage (memory), but I have a feeling that it's
allocating everything because we gave it a lot to begin with. How can
I identify how much I can cut back? I would REALLY like to cut back
some memory on partitions that we migrated from dedicated boxes with
only 1 partition per box.

2. Is there a rule of thumb for the PU to vCPU ratio on Power
hardware? On my x86 hosts I tend to shoot for 1:2. For mostly idle
workloads, I use 1:4.

3. For Shared Processor Partitions, do you all try to set Entitled
Capacity
(PU) to be close to average usage, and vCPU to peak usage, with the
MAX PU value set to match the vCPU max, or as close as possible? I
read this on a slidedeck published by Bjorn Roden during an IBM Edge 2015
conference.

Thanks,

-------------
Jacob
-------------


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.