Re: Breaking up one partition into two.

If you like subpar performance and sending money to IBM, go for it.
Most of my customers rather strongly disagree that memory is that
cheap. My outside guess is if memory management was done more in line
with current practice, you could get away with far less memory. One day
of memory management for an employee that your paying anyway, and put
off another task for a day, or send money to IBM. I know which I would
pick in spite of my IBM stock ownership......

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 7/25/2011 3:04 PM, rob@xxxxxxxxx wrote:

One thing to keep in mind, my boss thinks IBM is giving memory away for
chump change. We have 131GB of installed memory on our 9117. Of that
we've used up 87GB on various lpars and the rest is sitting there in
Capacity Upgrade on Demand. We can authorize an additional 3GB of memory
for $780. We keep expensing this in on a monthly basis. It's not like
begging for money to buy a 2MB upgrade for your S/36 used to be. He's
wondering why we should tie up even a day's wages for managing memory

when

that would buy a GB of memory.

This lpar has 5.25 processors.


Rob Berendt
-- 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: rob@xxxxxxxxx To: Midrange Systems
Technical Discussion <midrange-l@xxxxxxxxxxxx> Date: 07/25/2011 09:13
AM Subject: Re: Breaking up one partition into two. Sent by:
midrange-l-bounces@xxxxxxxxxxxx Thanks. I will mull this over and
discuss it with my boss. He actually keeps the monitors going for
iNav, observing them periodically throughout the day. A couple of
questions: 1 - Are there guidelines out there that point to what
numbers indicate a concern with DSPSYSSTS? Like, x faults are a
concern? 2 - I found a couple of Domino memory guidelines that I've
popped over to the Domino400 list. Starting to get some replies now.

http://www-10.lotus.com/ldd/dominowiki.nsf/dx/4.8_Domino_on_IBM_i_Tips#Memory

http://www-01.ibm.com/support/docview.wss?uid=swg27013080

http://www.ibmsystemsmag.com/ibmi/administrator/domino/Managing-Domino-Memory/?page=2

The last one above does discuss some faulting guidelines. How they
change with disk arms, etc. Then, the addition of ancillary products
(such as Quickr) can make a difference

https://www-304.ibm.com/support/docview.wss?uid=swg27020460#Memory_R-hwgroup

Rob Berendt
-- 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@xxxxxxxxxx> To:
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> Date:
07/23/2011 12:46 PM Subject: Re: Breaking up one partition into two.
Sent by: midrange-l-bounces@xxxxxxxxxxxx To take Larry's comments one
small step further, lately I have been turning off automatic
performance adjustment for customers that have the following profile:
1) Someone capable of monitoring the box periodically during the day
(operator or system admin) 2) SQL being used in the applications
and/or from ODBC/OLE connections 3) Extensive use of ILE with named
activation groups The reasons are simple. If the SQE sees changes in
memory configuration it will re-optimize queries. It has to since the
last plan would not work when the available memory is different. While
this is a really fast process, I have seen significant throughput
changes particularly with SQL heavy products such as Web Query and the
like. If you have a web site running, regardless of the type, it's
almost certainly using SQL. If the system is memory or CPU constrained
the positive effect is larger. Downside, it requires someone to manage
Night/Day etc. (Back to the future with those CL pgms) With ILE, I
have run into situations were the programs can behave in unexpected
ways and have very poor performance when customers that use ILE to its
fullest. Moving these processes into a unique memory pool (sometimes
even a private pool) seems to mitigate those issues. With products
that use the IFS extensively (Domino, WebSphere, Zend Server, Apache,
etc) I put those into a separate pool because the I/O characteristics
and the paging patterns are really different than more traditional
applications. The real message both Larry and I are trying to convey
is simple. Give IBM i its due and provide it enough memory in *MACHINE
and *BASE memory pools. Move most, if not all user jobs out of *BASE.
Tune from there. Your system will like you for it. Jim Oberholtzer
Chief Technical Architect Agile Technology Architects On 7/23/2011
8:51 AM, DrFranken wrote:

To answer just the pool question:

Jim is right that 5400 is a very big number and if that's for

an

entire 5 or more minute time frame that needs addressing! Second your
comment about numbers from a B10 being applicable to a POWER6 machine

is

also accurate. A B10 would have already died before it sustained 5400
faults a second for any amount of time.

The key to pools is that different work is kept apart. Domino

has

various processes that run, something like 20 jobs per sever as I

recall

and most if not all of them are threaded meaning the actual number of
operating tasks is quite large. Each thread needs some memory and an
activity level in order to run. NOT every thread is running at all
times. By having Domino in its own pool there isn't any conflicting
demand for memory resource there and Domino tasks don't get paged out
(at least most of them won't.) Thus when they are needed they simply

run

without fanfare or additional system effort to bring them back into

memory.

Meanwhile back in *BASE (or better yet your batch run pool)

that

AP

check run (which we consultants are very fond of by the way:-) )

gets

submitted. It also needs memory resources. If it uses SQL the query
optimizer looks around to see how much memory is available and uses
whatever it can to do its work. If there are jobs there in a wait

state

those jobs could get paged out for the AP job. Of course the jobs
finishes and gives up it's memory to the next batch job. This is

good,

as you have a completely different type of task (Start, run hard,

Done)

in this pool -vs- the Domino subsystem (Start, run as needed

forever,)

So even if the AP job has a much higher run priority (remember I'm

good

with that!) It just gets done faster it doesn't shove Domino out of
memory. And since you have lots of CPUs it may not make any

difference

to Domino performance at all.

That's why different memory pools for types of tasks is a good
idea. It's the same reason you don't run you interactive jobs in

*BASE.

- Larry "DrFranken" Bolhuis

On 7/22/2011 4:22 PM,rob@xxxxxxxxx wrote:

> We do already have separate IP addresses for each domino

server and

a

> separate one for i, (and another separate one with it's own

card for

> Mimix).
>
> Back in the day we used to manage memory ourselves. We used

to have

two

> job schedule entries NIGHT and DAY that would shift memory

between

batch

> and interactive. We kind of like this theory of autonomics

and

having the

> system fix itself.
>
> Our concern with creating multiple pools is that you end up

allocating

> resources that are not available to other processes. For

example,

if I

> bust *BASE into *BASE and DOMINO. I would allocate x memory

to

*BASE and

> y memory to DOMINO. If one is not using it and the other is

not

(and

> QPFRADJ is turned off) then I end up with a bunch of

inventory not

being

> used, when other processes would love to have it.
>
> I think one theory is that by busting out DOMINO from *BASE

you can

> control a spike in either from affecting the other. Is there

some

other

> reason to do so? Like, "paging option"? I heard someone

mention

run

> priority. I thought that was something at the job level.

Upon

further

> review I do see that subsystems support "classes". From

there you

can

> control run priority, time slices, threads, etc. I guess I

just

don't

> know enough "why" as to why I would want to do this other

work. Like

> restricting down threads, etc.
>
> In general "I thought" our performance was good. Throwing

money at

a

> problem greatly simplifies management. There's a lot that I

used to

do on

> AS/400's that I don't mess with so much anymore on Power

equipment.

Also,

> our people thrive on Domino. If I throttled down a hundred

Domino

users

> so one persons A/P check run would have priority it would not

go

over

> well.
>
> I have forgotton so much, like why faulting is bad, but even

more

so, the

> guidelines as to what levels constitute high faulting. I

can't

believe

> the number one used on a B10 is applicable to a 9117-MMA.
>
> I am seeing that a separate partition for this is probably a

bad

idea. But

> I am still trying the grasp why a separate pool might help.
>
>
> Rob Berendt

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