Re: Breaking up one partition into two.

[DrFranken <midrange@xxxxxxxxxxxx>]

I wouldn't go there.

1) You can't keep Domino running if you need to take ERP partition down 
for system maintenance.  So no gain.
2) You don't have separate disk units to use so you're not isolating 
I/O, so no gain.
3) Some additional memory will be consumed by the second copy of IBM i 
and some additional disk I/O as well, so some loss.
4) IBM i hosing limits the I/O queuing to only 6 deep so there is some 
possibility that Domino partition could have I/O issues unless you make 
lots of small drives, some potential loss.
5) You will now have two systems to PTF and do full saves on possibly 
requiring additional downtime for Domino (while ERP is down for backup 
and PTFs), some loss.

Also

a) You can (probably already do) run DOMINO in it's own memory pool so 
it doesn't affect, nor is it affected by, the ERP workload in that 
respect, no gain.
b) It's most likely that you would use uncapped processors for the 
partitions and you've got that already with both workloads in one 
partition, no gain.
c) You can set the run priorities on the ERP and DOMINO subsystems to 
your requirements for who gets CPU first. This is EASIER than it is will 
LPARs, some loss.
d) You already can (likely do) use a separate IP Address for DOMINO and 
ERP so again, no gain.

In short IBM i has such strong work management that I don't feel you've 
made a case for separate partitions configured in this way. Give me 
separate Disk Units and IOAs and then you have a different argument.

    - Larry "DrFranken" Bolhuis


On 7/22/2011 10:58 AM, rob@xxxxxxxxx wrote:
> Does it make sense to break up one partition running eight Domino
> partitions and all of our ERP and other "traditional" workload into two
> partitions?  We thought of having the ERP partition host the Domino
> partition and make it a guested one.
>
> Normally, on a straight Domino partition we do things a little
> differently.  Like, QCTLSBSD stays QBASE instead of QCTL as there's no
> batch or interactive workload - in the 'traditional' sense.
>
> Current lpar:
> 9117-MMA with 5.25 processor units, 51GB main memory, 52 disk drives of
> which four are SSD's and the rest 140's.  WRKDSKSTS shows them about 4%
> busy and 67.7% full.
>
> % CPU used . . . . . . . :       43.2    Auxiliary storage:
> Elapsed time . . . . . . :   00:00:01      System ASP . . . . . . : 6348 G
> Jobs in system . . . . . :      43596      % system ASP used  . . :
> 67.7759
> % perm addresses . . . . :       .660      Total  . . . . . . . . : 6348 G
> % temp addresses . . . . :     33.788      Current unprotect used : 91041
> M
>                                             Maximum unprotect  . . : 97924
> M
>
> System    Pool    Reserved    Max   -----DB-----  ---Non-DB---
>   Pool   Size (M)  Size (M)  Active  Fault  Pages  Fault  Pages
>     1     9644.92   4663.57   +++++     .0     .0    6.3    6.3
>     2    13060.87     82.01    1599     .0    1.8  385.4   1400
>     3      522.23       .30      29     .0     .0     .0     .0
>     4    18711.30       .92    1306    1.8    1.8    4.5    4.5
>     5    10284.65       .02     157     .0     .0  188.1  195.4
>
> System value . . . . . :   QPFRADJ
> Performance adjustment . . . :   2
> 2=Adjustment at IPL and automatic
>    adjustment
>
>
> Rob Berendt