Years back, I had a serious disk response time issue, a good portion of the issue was the disks were busy paging/faulting.
I added memory, the disk response time issue went away, paging and faulting also went away.
Our old Power5 had 64gb two partitions, 52 prod, 12 R&D.
Our new Power7 has 256 gb, three partitions, 196 gb Prod, 40 R&D, 10 Upgrade.
Bottom line, more memory the better.
Memory is much cheaper than it was 5 to 10 years ago.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Friday, November 01, 2013 5:02 PM
To: Midrange Systems Technical Discussion
Subject: Re: High Page Faulting in Base and Interactive Pools
Definitely use shared pools, they are much more efficient in 90% of the cases than a private pool. There are a host of reasons to use shared pools vs. private pools but suffice it to say a private pool is very rarely a better choice. It happens but it's really rare.
If the shared pool and/or private pool do not have sufficient memory the jobs will thrash with faulting and paging and get no real work done.
In the examples shown thus far, I suspect that has quite a bit to do with the page/fault rates. Once the system starts faulting heavily that causes more paging, which causes more faulting, etc. It goes that way up to a point, then the internal system managers take over and force jobs to an ineligible state so they sit on the sidelines until the system is able to catch up. In the end very slow.
Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects
On 11/1/2013 3:49 PM, Joel Harvell wrote:
What would be the performance consideration for assigning memory to a
subsystem rather than have the subsystem use a shared pool or *base??
What would happen if I did not assign enough memory to the subsystem?
--
--
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.
midrange.com
