mkmckinn
Active Member
All,
Newbie request here all. Can anyone help us improve some post V5R2 upgrade inconsistent performance (e.g. some UBEs, receivers, taking an order of magnitude longer to process than previously).
Last weekend we upgraded from V4R5 to V5R2. What we observe is inconsistent performance (variable run times) on UBEs and occasionally on some interactive applications.
System Description:
One World Xe, Distribution and Financials (No HR) Update 0 with selected SARs, SP 20, on an iSeries 830 (4200 CPW with 9GB RAM running V5R2) with 5 Terminal Servers (NT SP6 and Win2000 SP3) supporting ~200 simultaneous users.
Observations:
a) The UBE's which have suffered the most are causing significant memory paging and faulting (DB and nonDB) when they run
b) Running these UBE's under different conditions three times can improve their performance significantly in the short term (for the next few minutes), but not for the long term (beyond an hour)
c) Many UBEs run faster than before
d) The CPU isn't bound (averaging <50%)
e) The DASD though high isn't bound (<80% peak utilization)
f) There are some indications that under certain conditions the disk I/O can become bound
g) A background system performance monitoring application seems to have grown in disk I/O intensiveness
h) The network isn't bound
i) We run our operational documents on their single threaded queues
j) Our system (V4R5) was tuned pretty closely to the spec outlined in the JDE Redbook
k) Our subsystem configuration is system autotuned
l) By end of day today, our SQL packages had all stopped growing in size, except those for the control tables (UDC tables and the like).
Our Current Ideas:
1) Problem: too many jobs in a single subsystem - solution: build a new subsystem and shunt jobs to it.
2) Problem: new dispatcher and SQE subsystem not performing admirably - solution: turn off dispatcher and SQE (possible?)
3) Problem: SQL packages created for selected jobs are faulty because system autotune adjusting configuration too rapidly post upgrade - solution: manually tune subsystems, blow away SQL packages, let production run to let SQL packages settle, then turn back on autotune.
4) Problem: we missed something in the object conversion process of the upgrade - solution: find the non updated object and nail it.
Closing Request:
Anyone with thoughts on our listed potential solutions, and/or possible alternatives would be most welcome. Even other V5R2 war stories (preferably with happy endings) might prove cathartic. Seriously, any thoughts or advice would be most welcome.
Cheers,
--Malcolm.
Newbie request here all. Can anyone help us improve some post V5R2 upgrade inconsistent performance (e.g. some UBEs, receivers, taking an order of magnitude longer to process than previously).
Last weekend we upgraded from V4R5 to V5R2. What we observe is inconsistent performance (variable run times) on UBEs and occasionally on some interactive applications.
System Description:
One World Xe, Distribution and Financials (No HR) Update 0 with selected SARs, SP 20, on an iSeries 830 (4200 CPW with 9GB RAM running V5R2) with 5 Terminal Servers (NT SP6 and Win2000 SP3) supporting ~200 simultaneous users.
Observations:
a) The UBE's which have suffered the most are causing significant memory paging and faulting (DB and nonDB) when they run
b) Running these UBE's under different conditions three times can improve their performance significantly in the short term (for the next few minutes), but not for the long term (beyond an hour)
c) Many UBEs run faster than before
d) The CPU isn't bound (averaging <50%)
e) The DASD though high isn't bound (<80% peak utilization)
f) There are some indications that under certain conditions the disk I/O can become bound
g) A background system performance monitoring application seems to have grown in disk I/O intensiveness
h) The network isn't bound
i) We run our operational documents on their single threaded queues
j) Our system (V4R5) was tuned pretty closely to the spec outlined in the JDE Redbook
k) Our subsystem configuration is system autotuned
l) By end of day today, our SQL packages had all stopped growing in size, except those for the control tables (UDC tables and the like).
Our Current Ideas:
1) Problem: too many jobs in a single subsystem - solution: build a new subsystem and shunt jobs to it.
2) Problem: new dispatcher and SQE subsystem not performing admirably - solution: turn off dispatcher and SQE (possible?)
3) Problem: SQL packages created for selected jobs are faulty because system autotune adjusting configuration too rapidly post upgrade - solution: manually tune subsystems, blow away SQL packages, let production run to let SQL packages settle, then turn back on autotune.
4) Problem: we missed something in the object conversion process of the upgrade - solution: find the non updated object and nail it.
Closing Request:
Anyone with thoughts on our listed potential solutions, and/or possible alternatives would be most welcome. Even other V5R2 war stories (preferably with happy endings) might prove cathartic. Seriously, any thoughts or advice would be most welcome.
Cheers,
--Malcolm.