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



I second that. Really helpful stuff, I appreciate the trouble you've taken.

On Thu, Aug 16, 2012 at 12:48 AM, <rob@xxxxxxxxx> wrote:
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.





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.