Re: How much memory is currently paged?

Thank you.


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: Jim Oberholtzer <midrangel@xxxxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>,
Date: 08/15/2012 07:50 AM
Subject: Re: How much memory is currently paged?
Sent by: midrange-l-bounces@xxxxxxxxxxxx



Evan,

You have just touched on the black art portion of tuning. The real
answer is it depends, on how the application is behaving, what else is
running on the system, etc. As a general rule I like to see faults <20%
of the page rates if it is the database side. By definition data is
transient and there will be some faults during I/O operations. If the
application is almost write only then I would expect that ratio to be
quite a bit better maybe <5%. Paging in the Database columns is real
work being done in DB/2 so a high page rate there is indicative of quite
a bit of I/O. Usually a good thing.

On the program side (Non-DB) keep faults/pages in the machine pool and
*BASE as close to zero as possible. .1 <> .8 is OK, but over that your
starting to thrash IBM i and the licensed program products. On the P7
boxes the numbers will be a bit higher but the goal is to minimize
them. For Domino &WAS and any other JAVA based applications they are
going to page/fault like mad so try to keep them at <20% of the total.
Remember that garbage collection in JAVA is going to clobber a bunch of
paged out memory so you'll see activity just for that.

The best way to see what your applications are doing is to use IBMs
Performance Tools (all the parts which include iDoctor and Job Watcher
now) and MPGs Performance Navigator. Those are the two sets of tooling
I use to diagnose application performance problems and suggest
corrections to the code. Look for job wait states. A wait state will
cause paging / faulting since a waiting program will get flushed from
main store quickly, then once the wait is satisfied, the system has to
bring it all back in again, more paging/faulting.....

Also keep your DB/2 indexes up to date and you'll help the system out a
bit as well.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 8/14/2012 6:08 PM, Evan Harris wrote:

So what kind of ratio do you look for to between paging and faults -
do you have a rule of thumb as to what % of faults is acceptable ?

On Wed, Aug 15, 2012 at 3:29 AM, DrFranken<midrange@xxxxxxxxxxxx> wrote:

Depends on the system (CPUs, total memory) the faulting numbers here
could be acceptable but they are significant. Pool 2 (*BASE) is

showing

more than one in four pages as a fault that's not a great ratio.

Pool 5

is very poor with about 80% of pages faulting. Need more meory there
almost certainly. Pool 4 is very good with 0.03% of pages faulting

and

that's with a LOT of paging! The machine pool ration is poor also

with

almost seven of eight pages faulting but the numbers are pretty low
overall there so not a huge problem.

If it was me, I would be investigating more memory for this system

or

potentially fewer jobs running in pool 2 and 5.

Of course additional performance work with the iDoctor tools or

MPG's

tools will help get more refined answers.

I don't believe QTEMP is in there, that space is tracked differently

as

I recall.

- Larry "DrFranken" Bolhuis

-- Regards Evan Harris http://www.auctionitis.co.nz
--

--
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.