Slow response Times for transactions relating to Solution Manager

[Former Member]

Hi all,

We recently installed a solution manager 4.0 system on one of our i570 hardware.

We have noticed that the response times for transactions relating "typically" to solution manager are a little slow(response times between 3-4 seconds) and sometimes very slow( sometimes like 12-13 seconds)...Its very random...Are these transactions typically like these ?

The transactions we are referring to are :

1) SOLAR_PROJECT_ADMIN - Project Administration (esp when we try to select a project and double click on it to edit/display the project)

2)RMMAIN - Roadmap

3)SOLUTION_MANAGER - Solution Operation

The way we have thing system configured is that we have assigned separate memory pools to the ABAP stack and JAVA stack...via the routing entries for the jobs in the subsystem description.

One thing, which we though have noticed that inspite of the system being up and used for almost a 4-5 days..the hit ratio for the Initial Records Nametab buffer is an abysmal 4-5%. The settings for initial Record buffer is:

rsdb/ntab/irbdsize 13500 kB

rsdb/ntab/entrycount 45000

Shouldn't the hit ratio for this Initial Records Nametab buffer be close to a 96-98% or better...We are wondering if this has anything to do with this..but then on the other hand, the other "basis" transactions run just within half a second.

There are no swaps anywhere in the system in ST02.

We have tried implementing the latest support stacks on both the ABAP/JAVA stacks as well as the PTF's, but it looks like something else.

Any ideas on this, anyone?

Thanks for all your help.

Abhi

[markus_doehr2 · Accepted solution]

I have seen this too - we use the Support Desk and as of now I was not able to find out, why it´s working sometimes very slow and sometimes very fast.

The box is a 4 CPU Opteron with 24 GB of RAM, there´s still RAM free/not used.

I also see a likewise behaviour on a CRM system when using transaction CRMD_ORDER, I believe it´s just "by design".

--

Markus

[JanStallkamp]

Hi.

If this performance problems are platform independent (as Volker said) then it might be an idea to look for answers in the . Seems to me that they are a quite active community over there too.

Best regards,

Jan

[Former Member]

Hi Jan,

Thanks for the response..I will try geting their (Solution Manager Forum) thoughts on this one as well.

Thanks

Abhi

[Former Member]

Hi Abhi,

unfortunately I have seen these performance issues on all platforms by now ;-(

As customers typically do not use this tool, I never investigated that. To me it sounds a bit that the ABAP Web-Dynpro is pretty ressource intensive and the SolMan Transactions might need some performance improvent in general.

As you talk on "random", the question would be:

Might it be possible, that especially the 10-12s happen after that you didn't use it for several minutes ?

To me it sounds, that SolMan is VERY RAM hungry and therefore is VERY dependent on the fact if it is paged in or not. As I imagine, that the ABAP WPs are running in Pool 2, this competes against all other SAP systems (and you most likely use more or less ABAP only in SolMan). Therefore all other SAP systems compete against this one ...

Did you deactivate RSDB_TDB in TCOLL from daily twice to weekly once on all systems on this box already ?

btw:

I do have 11% hit ratio in the Initial Records only, too ...

Just the first few cents based on your info,

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

[Former Member]

Hi Volker/Markus,

Thanks a lot for the response.

Yeah Volker, you are absolutely right. the 10-12 seconds happens when we have not used the transaction for several minutes...Looks like the transactions are moved away from the SAP buffer or something, in a very short time.

and yes, the ABAP WP's are running in Pool 2 (*BASE) and the the JAVA server, I have set up in another memory pool of 7 GB's.

I would say the performance of the JAVA part is much better than the ABAP part.

Should I just remove the ABAP part of the SOLMAN from memory pool 2 and assign the JAVA/ABAP a separate huge memory pool of say like 12-13 GB's.

Will that likely to improve my performance??

No, I have not deactivated RSDB_TDB in TCOLL from daily twice to weekly once on all systems on this box. It is running daily twice right now.

Should I change it to weekly once on all the systems on this box? How is that going to help me?? The only thinng I can think of is that it will save me some CPU utilization, as considerable CPU resources are needed for this program to run.

But my CPU utilization is anyway only like 30 % average. Its a i570 hardware and right now running 5 CPU's.

So you still think I should deactivate this job from daily twice to weekly once on all systems on this box??

Markus, Did you open up any messages with SAP on this issue.?

I remember working on the 3.2 version of soultion manager on change management and the response times very much better than this as compared to 4.0.

Let me know guys and once again..thanks a lot for your help and valuable input.

Abhi

[markus_doehr2]

> Markus, Did you open up any messages with SAP on this

> issue.?

> I remember working on the 3.2 version of soultion

> manager on change management and the response times

> very much better than this as compared to 4.0.

> Let me know guys and once again..thanks a lot for

> your help and valuable input.

Yes - 3.2 was MUCH faster.

I see likewise behavior in all products based on Kernel/Basis 7.00 - we have that also in the CRM and also in e. g. VA01 on ERP 6.0 on our test upgrade. If the transaction was not used for a day, its response time is beyond acceptable. Program buffers (and all others) are really big (abap/buffersize is e. g. set to 2,5 GB).

Something fundamentally seems to have changed in that kernel, the "subjective" response time is much slower than with older versions.

If you ask me, this is by design, because of using abstraction layers on top of abstraction layers on top of another framework on top of an abstraction layer... and not only on the backend but also on the frontend, using 1000s of windows controls.

No, I've not yet opened an OSS call for this, I in fact have no idea where to position it because it's pretty difficult to explain and I have no clue, whether is a memory-buffering issue or an other issue related to some application specific tuning.

--

Markus

[Former Member]

Hi Abhi,

I would agree to you, that it might make sense in your environemnt to move ABAP into an own pool - I would even think on ABAP into an own pool and Java back to pool 2 as it is not that often used ...

Have a look at 7am and 8pm to the data of ST06 of this box!

I can promisse you:

LOW CPU usage and HIGH page faulting !!!!

=> this job RSDB_TDB is THE RAM killer par excellance !

(but this is just a small part of your issue)

As mentioned, please move ABAP into its own 7-12GB and try again - then it will become better in my eyes ...

Regards

Volker Gueldenpfennig, consolut.gmbh

http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de