Jay Paff
Active Member
Hi All,
I'm an ex-CNC on an old XE environment (FAT, Citrix and Web) now working for a new company as the AS/400 specialist. Long story; based on not wanting to travel/re-locate.
Anyway, yesterday response time because non-existant for our E1 users due to high page faulting and disk busy due to QZDASOINIT and Kernal processes. Eventually, (after 20 minutes) things went back to normal sub-second response times. It should be noted that we also run the Showcase product for non-E1 queries and I do frequently see QSQSRVR jobs with high CPU and I/O stats.
Current environment is E1 9.0 TR 8.98.34, Intel WAS 7. Current iSeries is 2.2 processors out of 4.0, 56 Gb of memory and 7.5 Tb disk in single ASP.
Share pools: Machine 3600 Mb, *BASE=51772 Mb, *Interact=300 MB, Spool=150 Mb, *SHRPOOL1=1000 Mb (Mimix subsystem). Max Act is set high enough that we don't transition to Inel.
QPFRADJ is off because it does not respond fast enough for share pool adjustments and it keeps dropping base share pool way low (like 40 Gb).
Everything pretty much runs out of *BASE. *BASE page faulting averages around DB < 200, Non-DB < 500. Other pools faulting is good, *Machine, *Interact, *Spool all < 10 total. *SHRPOOL1 DB<20, NON-DB<150.
The current CNC is opposed to splitting up *BASE into additional pools for things like batch. His reasoning is it won't make a difference and will only incurr more overhead. What are other folks doing with regards to share pools?
What I'd like to do is split batch subsystems off to there own share pools, and then start looking at splitting out QSQSRVR and QZDASOINIT jobs into seperate pools. This is what we did in the old XE days and we had a pretty decent balance between batch throughput and response time. Again, what do others do?
Thanks Jay
I'm an ex-CNC on an old XE environment (FAT, Citrix and Web) now working for a new company as the AS/400 specialist. Long story; based on not wanting to travel/re-locate.
Anyway, yesterday response time because non-existant for our E1 users due to high page faulting and disk busy due to QZDASOINIT and Kernal processes. Eventually, (after 20 minutes) things went back to normal sub-second response times. It should be noted that we also run the Showcase product for non-E1 queries and I do frequently see QSQSRVR jobs with high CPU and I/O stats.
Current environment is E1 9.0 TR 8.98.34, Intel WAS 7. Current iSeries is 2.2 processors out of 4.0, 56 Gb of memory and 7.5 Tb disk in single ASP.
Share pools: Machine 3600 Mb, *BASE=51772 Mb, *Interact=300 MB, Spool=150 Mb, *SHRPOOL1=1000 Mb (Mimix subsystem). Max Act is set high enough that we don't transition to Inel.
QPFRADJ is off because it does not respond fast enough for share pool adjustments and it keeps dropping base share pool way low (like 40 Gb).
Everything pretty much runs out of *BASE. *BASE page faulting averages around DB < 200, Non-DB < 500. Other pools faulting is good, *Machine, *Interact, *Spool all < 10 total. *SHRPOOL1 DB<20, NON-DB<150.
The current CNC is opposed to splitting up *BASE into additional pools for things like batch. His reasoning is it won't make a difference and will only incurr more overhead. What are other folks doing with regards to share pools?
What I'd like to do is split batch subsystems off to there own share pools, and then start looking at splitting out QSQSRVR and QZDASOINIT jobs into seperate pools. This is what we did in the old XE days and we had a pretty decent balance between batch throughput and response time. Again, what do others do?
Thanks Jay