Performance issue with V5R3

[Former Member]

Hi all,

We just upgraded our production system from V5R2 to V5R3 and in last 3 weeks I have noticed that average response time of DIA WP's have jumped from closer to 1 second to 1.7 seconds. I looked under the note for 'known problems for V5R3' and all the recommended PTF's were already there. Overall the system is slow and I cannot pinpoint a single transaction. It seems like the entire system as a whole.

We have 830 with 8 CPU and 16 GB memory and both database server and application server is on the same machine. We donot use any LPAR's.

Kernel level: 2219

V5R3 CUM level: 6045

Has anyone of you noticed any performance degradation while upgrading to V5R3.

Any suggestions?

Regards

Srikant

[Former Member · Accepted solution]

Sometimes a user who's always run a report in BTC decides to then run all their reports in DIA and that alone can skew your statistics regardless if you upgraded the O/S or not, so I'd also start looking in other places too.

Since you specifically are talking about DIA response time, I would break down its components from both pre & post upgrade.

If you receive weekly Early watch alerts, this is going to be very easy and you can find the data in your reports.

In general DIA reponse time is comprised of

DB time

Wait time

CPU time

GUI time

I would focus in on the segment where the largest increase has occurred.

It does take a few days for the new DB stats to kick into gear for the optimizer to take full advantage of them; but you did mention that it's been 3 weeks.

[Former Member · Accepted solution]

Hi Doreen,

Thanks a lot for the reply. I looked into the stats and before the upgrade the average response time for the DIA WP's were close to 1 sec and about 45% of the time was Db req time.

After the upgrade the first week was average response time was 1.6 sec and 614 sec was DB req time. The second week was little worse and was 1.8 sec and 720 ms. The third ongoing week is 1.6 and 664 ms.

I am suspecting that first few weeks was also because of the conversion time for objects to convert to V5R3. I should have used the object conversion program STROBJCVN which I didn't used.

We are small company and we do not have a full time basis person. Seems like I may have to spend some time doing some performance tuning.

Any pointers on how to improve DB req time?

Regards

Srikant

[Former Member · Accepted solution]

Hi Srikant,

We also did an OS upgrade from V5R2 to V5R3 and we suffered important performance problems. It was just because the V5R3 was so different and had different resource needs.

We had an 890, 16 CPUS and 64GB of main memory. R/3 version was 4.7x200 Unicode. Our DIA response time was aprox. 1 second, after migration jumped to near 2 seconds.

What R/3 version are you running ? Are you experiencing paging in your iSeries ( *MACHINE and *BASE pools )?

I recommend to start with an analysis of WRKSYSSTS at interesting times, to know where you have the bottleneck.

We learn that V5R3 needed more memory than V5R2. At last, we upgraded our iSeries to an i5 570 with 10 CPUs and 128 GB.

Regards,

Joan B. Altadill

CELSA SAP Admin

[Former Member · Accepted solution]

According to the information you provided...

Before the upgrade -

DIA response time = 1 second

45% = DB REQ TIME which equates to 450ms DB REQ TIME

55% = other parts of DIA response which equates to 550ms for other parts

After the upgrade -

DIA response time = 1.6 second

664ms DB REQ TIME

1000ms other parts of DIA response

These figures equate to

47% increase in DB REQ TIME

82% increase in other parts

I would focus on the 82% increase to the 'other parts', in my eyes that's where you've taken the biggest incremental hit.

So.....some of the obvious factors

1. Do you have enough DIA WP's now that response time is longer you might be encountering a double hit with users also waiting for an open DIA WP

2. WRKSYSSTS - Make sure SAP is running in *BASE & also what is the MAXACT for the *BASE pool? A very, very rough rule of thumb for the MAXACT would be that MAXACT # should be around the total # of WP's running on the box

Just some thoughts but you might want to engage a performance tuning consultant

Doreen

[Former Member · Accepted solution]

Hi Joan,

Thanks a lot for responding to the issue. We are using 46C. We only have two pools *MACHINE and *BASE. There is no paging happening on the *MACHINE pool but yes there is a lot of paging on the *BASE pool in which SAP runs. I have 47 WP's and the maximum active jobs is set to 75. I am just reducing it to 65.

Regards

Srikant

[Former Member · Accepted solution]

Hi Doreen,

I fully agree with your recommendation. We have 47 WP's and the QMAXACTLVL was set to 75. I reduced it to 65. May be that will help a little. Also I also noticing some swapping happening in the Single record buffer in ST02. The current value for parameter buffer_length is 50 KB. I will plan to increase that to 60 KB.

Thanks a lot for all your help.

Regards

Srikant

[Former Member]

Hi Srikant,

I would strongly suggest, that you check the note 442288 or something similar where the QMCHPOOL is in. You should apply all the values there.

Then 16GB of RAM for 8 CPUs are a little bit small for very new OS ... So, I would like to see the page faults of your system over the day in ST06 pool - previous hours.

Then the PTFs do not really look too new. What is the DB fixpack #?

I would update to the very latest level and check if or if not to apply pack #10 especially.

Then it would be interesting, what are the detailed timings. just DB-time and non-db-time is not sufficient.

What does DIA look like for all columns, that are larger than 30ms ?

Regards

Volker

[Former Member]

We had a similar issue with the system when we upgraded. We think that we narrowed it down to the way in which SAP was accessing the database. We found that it related to the Database Optimiser, and we discovered that by creating a new index it got the Optimiser to improve dramtically. We don't think that the particular index area was that important.

[Former Member]

Hi Alan,

Thanks a lot for the response. Are you talking about a particular index on some tables. As I mentioned before it seems like the entire system has slowed down and I cannot pin point to a single transaction that may slowed down. Can you please provide some more details about the index that you created.

Regards

Srikant