iSeries Tuning Recommendations

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

Can you document extreme high or low page fault rates? If so, then you can make a case for breaking out the storage pools. If not, then you dont have a case for the breakdown of the pools.

This is always been one of my pet peeves, what is considered high page faulting? Is a total of a 1000 faults per second for a 550 partition with 2.2 processor allocated considered high if no one is complaining. Is 10,000 high? I sure wish IBM would try and give some guideance on this instead of saying "well if no one is complaining....". No one may be complaining, but batch could be running way slow.

Jay,

My own personal experience says there is no substitue for separation of work, especially if you have workloads from many different products on your IBM i.

I'll take a wild guess that your CNC only has experience with windows installations? I'm guessing that because since windows doesn't allow disparate apps to 'play nice' very well, he always used different servers to separate his work.

If you check out my web side education page: http://www.cleindoriconsulting.com/educationmain.html

I have some docs on performance tuning from my Xe years, and two others 'Performance tuning 101 & 102' that might be of use.

Tom

The IBM guideline that I have read is a user pool fault rate of between 10 faults and 100 faults per second.

Everyone,
Researching the performance an bit more and I have discovered that QQRYDEGREE is set to *NONE and our system has symetrical processing. For E1 9.0, what is everyone's experience with setting QQRYDEGREE to *OPTIMIZE. Is this a good thing or can it open us up to potential badness?

Thanks, Jay

Jay,

FWIW, I had a Xe installation where we had literally 1000's of tasks doing SQL for JDE. Finally, after consultation with IBM we turned OFF SMP, and the performance issue subsided.

Personally, since you have SMP and QQRYDEGREE=*NONE, I'd try a week with *OPTIMIZE, if you are still having issues, you might want to try *IO. I normally recommend *OPTIMIZE when I am doing a performance evaluation for a E1 shop.

Tom

Jay, had this problem about 2 yrs ago. Check your *MCHPOOL paging rate, also. With QPFRADJ on, system would always steal from *MCHPOOL to satisfy *BASE, causing high NON-DB page faulting in *MCHPOOL, which should NEVER go above 10. I ended up turning off QPFRADJ and writing a little CL memory pool manager, that always assures *MCHPOOL has enough memory to keep it at or below 10 Faults in NON-DB. You're welcome to it if you'd like, worked well for us. The thing that really solved our problem, was adding more memory to the iSeries. Basically made serious page-faulting go away.