cancel
Showing results for 
Search instead for 
Did you mean: 

V5R3 Cum 6255 installation and DB group 13 Performance ?

Former Member
0 Kudos

Hi,

We did install these PTFs last week since that time we have serious problem degradation performance as soon as user increase on the system......

Just to verify if someone else as thess kinds of problems......

ECC 5.0

Kernel 155, libdbsl 149, Tp 154, R3trans 145, Callcmd 17,....on iseries 825

Emergency !!!!!!!

Thanks,

Jules

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hello Jules,

Sorry but I do not have a solution for your problem, but the last year we have had similar problems when applying cum packs. Strange thing however is that the performance problems, which were huge, only occurred with two of the four cum packs we installed.

On both occasions IBM and SAP were involved for assistance but never a cause was found for the bad response. The performance problems vanished away in two weeks after the cum pack install.

When thinking of a reason why two installs of a cum pack had such a big impact on the performance, I tried to figure out the order being followed during the install.

In both cases it went wrong when the cum pack was installed on Thursday evening around 20:00 hours or so. Friday did show a bad performance, but Friday is a day with less people in the office. On Saturday a client copy was scheduled, that is when the performance trouble started.

My theory, (which may be stupid after all I am not an SAP expert), is that prior to a cum pack/database group ptf install you are supposed delete all software packages. The client copy requires the recreation of to much SQL packages at once, leaving the system out of breath. Stopping the client copy or stopping SAP at that stage only makes things worse.

After having had these experiences I always plan the cum pack apply in the weekend and without the need of a client copy being scheduled in a week's time. Following this roadmap did not result in any performance problems after a cum pack apply.

Having said that I am curious if the performance on your systems stays bad or that you also see some improvement in time. So an update about the status of your problem would be nice.

Kind regards, Rudi van Helvoirt

Answers (3)

Answers (3)

Former Member
0 Kudos

Well,

Since the beginning of the week, evrythings look fine .... after some

verifications and interventions on our setup... and returned on the ''B'' side of our as/400 and back to Kernel 142 and Lib_DBSL patch 100...

We cannot say why this happened, maybe w've made something wrong...but it's still mystical.... three weeks of nigthmare.....we had to restart our SAP system every two days to get performance it was like a ''reset ressources button'' when we got the maximun... the perfomance dropped tragically......

If someone in the future, has this kinds of issue with the same or close to same

environment (Kernel or PTF), let us know....

Thanks to everyone,

Jules

Former Member
0 Kudos

Hello Jules,

As I remember, 'B' side contains the OS/microcode with "temporarily applied" PTFs, and 'A' side contains the "permanently applied" PTFs.

Did you return to 'A' side so the system is on previous Cum and DB fix level?

Thank you,

Victor

Former Member
0 Kudos

Hello Victor,

I can not confirm your conclusion at 100%, but you are exactly right when you say:

'''B' side contains the OS/microcode with "temporarily applied" PTFs, and 'A' side contains the "permanently applied" PTFs.''

And the purpose of our action was to eliminate all PTF's installed temporarily during the last weekend before the problem began.... As we had installed CUM and the DB Group the easiest way to verify if one of them was the reason of our problem. But in my mind if for any reason beetwen two CUM you decide to apply permanently an HIPER PTF or others as soon is permanent you should retrieve them in ''A'' side...

That' s my comprehension but.... I'm pretty new in the Basis As/400 environment.

Remember that we are exactly at the same level that we are at the beginning of our performance problem with the OS, this let some doubt about Kernel 155 ???

Because presently everythings fine, up to now....

Best regards,

Jules

Former Member
0 Kudos

Hi,

We also did experience severe performance issues.

On the same kernel level as you

But not yet on Cum 255 (but DB 13 is active)

We went two weeks ago from 6.40 kernel 146 to 155 (on R/3 4.7x100)

With the same SAP load as usual, the AS/400 CPU utilization increased from about a normal 50-60% to allmost a sustained 99-100%. A classical greek drama.

When patched to kernel 156, it was a liittle better.

But now back on kernel level 146, cpu usage is back to normal values.

Still investigating it...

Paul Hoogendoorn

Former Member
0 Kudos

Please try to display Collection Service - Graph History in iSeries Navigator to look at

- CPU Utilization (average)

- Disk Arm Utilization (maximum)

- Disk IOP Utilization (maximum)

- Machine pool Fault

- User Pool Fault (maximum)

CPU should not be at 100% for a long period. The majority of the disk units should not be busy more than 40% for a long period. Disk IOP should not be utilized more than 20% for a long period. Machine pool fault should not be more than 10 per CPU for a long period. These can be the basic point to start investigating perofrmance problem.

Did U record the allocated RAM pool size and its MAXACT paranmeter before applying CUM PKG (WRKSYSSTS)? If so, see if these value change or not.

Satid S.

IBM Thailand