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



Further review with IBM Performance group.
CPU and/or memory not the issue, machine fault 0, low page faults.
The 10k spinny drives are the main issue.
High Util Dsk jumped to 78.
Disk response time jumped from normal of 2 ms to 55 ms (30 ms service time + 25 ms wait time)

RSTLIBBRM started at 10.47, ended at 11:19, 32 minutes.

Int High Pool
Transaction -CPU Util-- Feat --Util-- -Fault/Sec-
Date Time Count Resp Tot Int Bch Util Dsk Unit Mch User ID Excp
07/02 10:45 373 .05 18 2 16 1 2 0014 0 44 02 104055
07/02 10:50 285 .10 19 2 17 1 6 0020 0 30 02 108034
07/02 10:55 198 .04 12 0 12 0 33 0008 0 22 02 76101
07/02 11:00 13 .00 13 0 13 0 78 0013 0 12 02 60064
07/02 11:05 86 .04 16 0 16 0 57 0014 0 23 02 67173
07/02 11:10 258 .16 15 1 14 0 53 0015 0 15 02 58854
07/02 11:15 445 .12 17 5 12 3 70 0020 0 13 02 63228
07/02 11:20 482 .18 16 3 13 1 38 0004 0 19 02 74898
07/02 11:25 309 .06 20 2 18 0 8 0015 0 35 02 70960
07/02 11:30 260 .05 20 1 19 0 14 0001 0 25 02 60019
07/02 11:35 142 .09 18 0 18 0 10 0024 0 29 02 68198
07/02 11:40 105 .23 7 0 7 0 2 0009 0 24 02 62889

I then ran the same RSTLIBBRM on my Production LPAR, which has 100% SSD drives.

RSTLIBBRM started at 14:30, ended at 14:49, 29 minutes.
CPU and/or memory not an issue, machine fault 0, low page faults.
High Util Dsk jumped to 85
Disk response time jumped from normal of .2 ms to 21 ms (12 ms service time + 11 ms wait time)

Int High Pool
Transaction -CPU Util-- Feat --Util-- -Fault/Sec-
Date Time Count Resp Tot Int Bch Util Dsk Unit Mch User ID Excp
07/03 14:25 2217 .04 58 5 53 4 6 0005 0 62 05 303381
07/03 14:30 2542 .04 46 5 41 4 7 0021 0 52 02 280485
07/03 14:35 2325 .06 33 8 25 6 24 0023 0 52 04 251107
07/03 14:40 2196 .08 41 4 37 3 81 0020 0 183 02 419358
07/03 14:45 2386 .07 35 4 31 4 85 0020 0 50 02 249945
07/03 14:50 3008 .07 34 7 27 7 53 0019 0 38 02 283517
07/03 14:55 2855 .04 29 5 24 5 6 0022 0 46 02 250587

I also see similar behavior with SAVLIB.

But the Save/Restore has less impact on the Production lpar
Performance numbers are similar, but much larger impact on R&D with the 10k spinny drives.

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul
Sent: Monday, July 02, 2018 1:20 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: BRMS RSTLIBBRM jobs impacting RDI and LPAR performance

R&D LPAR.
Real 10k spinny.

Main storage size (M) . : 81400.00

Defined Max Allocated Pool -Paging Option--
Pool Size (M) Active Size (M) ID Defined Current
*MACHINE 4070.00 +++++ 4070.00 1 *FIXED *FIXED
*BASE 67562.00 989 67562.00 2 *CALC *CALC
*INTERACT 8140.00 2035 8140.00 4 *CALC *CALC
*SPOOL 814.00 20 814.00 3 *CALC *CALC
*SHRPOOL1 814.00 30 814.00 5 *CALC *CALC

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Monday, July 02, 2018 12:29 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: BRMS RSTLIBBRM jobs impacting RDI and LPAR performance

Paul:

BRMS will have some small effect on the performance (it has to read its
databases) but not what you're reporting. I suspect the restore is causing
the disk I/O to spike and since restores are one thing that run in the
machine pool, paging/faulting there. I suspect you've got the machine pool
set up to be fairly small since ordinarily it does not use that much memory.
I suggest you bump that up considerably if possible during a restore. I/O
is what it will be. If you are driving lots of I/O then it's going to show
up.

Is this a hosted environment or real disk?


--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Steinmetz, Paul
Sent: Monday, July 02, 2018 10:58 AM
To: 'Midrange Systems Technical Discussion' <midrange-l@xxxxxxxxxxxx>
Subject: BRMS RSTLIBBRM jobs impacting RDI and LPAR performance

Occasionally, we have to run some BRMS restore jobs (RSTLIBBRM) during prime
shift, 8-5.
The BRMS restore jobs are having a large impact on RDI performance, and
other LPAR jobs.
From MPG perf graphs, disk response time, machine pool faults have large
increases.

Has anyone from the group have/seen this same behavior.
What, if anything, can be done to minimize/eliminate this impact.

Also, what system jobs are used for the RDI communications?

Thank You
_____
Paul Steinmetz
IBM i Systems Administrator

Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071

610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home

psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx>
http://www.pencor.com/

--
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: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.

Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.