Re: Memory and CPU Considerations for IBM i LPARs

Jim Oberholtzer
Agile Technology Architects

On Aug 22, 2024, at 7:06 PM, Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Jim,

Am 22.08.2024 um 18:10 schrieb Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>:

To answer the original post, this allows the OP to manage how much memory is used for I/O on each hosted environment, within the hosting system.

Yeah. But since the guest LPAR also has memory being used as cache, and bringing the data as close to the where it is processed eventually should be beneficial, yes?

My intended question was: Is this partitioning of memory into pools (on the hosting side) still relevant, while very modern nowadays machines are equipped with memory in large amounts, and running from extremely performant NVM

Yes! The memory used to virtualize I/O is where the cache is done.

I manage several systems using these techniques and I would argue they are the current professional standard for anything but the smallest system.

Did you configure these so because you *think* it should be done for the reasons you outlined? Or did you take actual measurements to prove that your thinking had positive effects at all? Or possibly learn that the difference is negligible — something I assume for now with my limited experience with large systems enduring considerable workload?

Over the last ten years we have managed many production IBM i hosting IBM i partitions and yes we see much better I/O performance when setting the shared pool. It does not take huge memory, usually 2 or 4Gb is plenty.

Again, no offense intended. I'm just curious and want to understand.

:wq! PoC

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

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.