CCMS implementation performance impact

[TomCenens]

Dears

I'm looking for information on the impact on performance of a CCMS implementation.

Impact on Solution Manager, impact on managed SAP systems. I opened a customer message but SAP comes back with there is no sizing documentation for ccms.

The purpose is to add a lot of managed SAP system into SAP Solution Manager and enable CCMS + IT Performance Reporting. I would like to know how much impact the RFC access causes.

If anyone has done a study on this or has information on this please share.

Kind regards

Tom

[Former Member · Accepted solution]

By implementing CCMS through Solution Manager, you have to apply agents to all systems that you want in the implementation. The SAP start commands in some cases start the agent first for you, but be careful cause this only works for JAVA. Start ABAP on your own before running the SAP start commands. I would highly recommend scripting all this.

This makes the SAP landscape agent intensive, and you will always have to start the agent before the system and offline the monitoring from solution manager before you stop the agent and the system Many times I have had to kill not only the agent but SAP start programs from the OS, cleanipc and other shared and segment memories.

The agent requires memory and in some cased for this reason can not be started after the system is up and running. You can then send your alarms to a ticketing tool and have alarms going off or have it SMS the support respnsoible team directly.

My suggestion is to set this up in a test landscape, and then move it to Production. Decide which critical systems you want to get alarms for. There will definitely be a tunning period in any case but you will be more proactive and also have your hands full. You can also limit which CCMS monitors you want, but realize that you will have to clear alerts as part of a maintenance in all systems directly.

[TomCenens · Accepted solution]

Hello Augusto

The integration of CCMS agents into sapstartsrv is only applicable from SAP Netweaver 7.0 EHP2 and higher. The majority of SAP system we have running are below that release version.

We have already written scripts to handle agent failure, cleanipc and so on so that part is covered. We also already have agents in place for a dozen of SAP systems. Doing so slightly increases CPU usage and of course RFC traffic but we don't have a view yet on what a massive amount of SAP systems would do in terms of performance impact on Solution Manager.

Looks like I will have to see if I can the result by doing tests myself, strange thing is SAP mentions on help.sap.com that the way the CCMS agent is integrated is changed from SAP Netweaver 7.0 EHP2 and higher because it makes the performance better. When I then ask them for the "proof" of that they don't have any information available. If you state performance is better in case X versus case Y you should have test results available at least I would think.

Kind regards

Tom

[Former Member · Accepted solution]

Hi Tom,

The explanation for this is due to sapstartsrv daemon will have to run anyway at your system for starting the instance and providing monitoring functionality. You still have the option to not use the sapstartsrv as a monitoring agent and disable the function to use the standalone agents. But as you already must have this started, aggregating the function of monitoring to it will certain increase the performance by lowering the overall memory usage.

Cheers,

Maurício

[Former Member · Accepted solution]

I agree Tom, and apologize for not understanding the initial question.

It is my experience that any improvements comes with the kernel and possibly code SAP provides, thus avoiding an answer because every situation would appear to have a different impact based outside factors that can differ from each customer.

We hope that each version of that SAP releases is always better but we also know that a new set of bugs appear. I believe with the in memory computing HANA, performance with improve vastly. In the meantime we should carry on to implement such better support scenarios and use Solution Mangers as it was intended, doing our own testing in each case to mitigate risk of system performance.

It is a good observation and I do understand your concern with Solutoin Manager taking the full impact of system monitoring, however unless you are placing a great deal of load in Solutoin Manager I would expect the handing to be adequate. That said a second Solution Manager for this purpose and or the use of PI may be assistance. You are adding system to aid in performance but you have to monitor and maintain them. Sort of a catch 22, and if you are not even at the latest version in most cases I imagine your funding is limited.

[TomCenens · Accepted solution]

@Mauricio Yes I do understand the principal behind it. From a logical point of view it should improve performance but then again tests should have been run to prove the point.

For example: I'm involved in the pilot program for SAPJVM 4.1 and while SAP sais the performance should be the same or better but we all know SAP doesn't have every combination of OSDBSAP system running. It's the same principal, from a logical point of view it should be the same or better but one should do some performance tests to verify if it's the case.

@Augusto No problem on the misunderstanding, it shows my question wasn't that great and I should have provided more information

The point is that we have a lot of managed SAP systems to add and apparently SAP doesn't have that many customers that have a big number of managed SAP systems in the Solution Manager. The performance impact of CCMS implementation is neglictible if you only have some managed SAP systems. What is a 3% CPU rise in that case, shouldn't be a problem but now imagine you put in thirty times as much SAP systems then it can be become a problem if you don't foresee additional server resources.

A lot of those scenario's seem to have been tested with only a few managed SAP systems, doing a full landscape fetch through transaction SMSY takes a long time for example. I do know in Solution Manager 7.1 there is another component in between the SLD and SMSY which can synchronize content faster to avoid long runtime.

Another example was the landscape verification tool 1.0 which I reviewed in a blog. It didn't have a possibility to refresh single systems (I haven't checked latest version) but that is a problem if you have many managed SAP systems and you want to just check one. In the video demo's it flashes and it's very fast because there are only five managed SAP systems.

I'm looking forward to Solution Manager 7.1 but these kind of performance impacts should be known really. Doing a small implementation is no problem but customers are really interested in application lifecycle management and so on and are starting to generate demand for a lot of different scenario's. Sizing it is not that hard in small environment but once the environments become larger and a lot of managed SAP systems are involved the issue I see with CCMS for example rises and it becomes very hard to size properly. Perhaps it could be integrated into the quick sizer (number of managed SAP systems and enablement/use of certain scenarios).

I do know for some scenarios there is sizing documentation available, diagnostics being one of those.

[Former Member]

I'm assuming CCMS Implementation is mainly targeted at the implementation of the agents, sapccm4x and sapccmsr (-j2ee).

Some performance issues that i've noticed before:

1) sapccmsr agents occassionally being high on CPU (90%), and may be periodical thing. This shouldn't be a problem unless the agent is at this state for quite a long time, in which i've noticed. Contributions to this were mainly agent bugs and network issues according to my observation.

2) Dialog WPs on Monitoring System will be used by CSMREG user, and i believe that data is being pushed from Monitored systems via ccms agents. These WPs can sometimes be long running. I believe the pushing of data is triggered by Monitoring System's batch job, SAP_CCMS_MONI_BATCH_DP.

3) Probably the most evident, noticeable by an administrator, is when you use RZ20 and looking into a specific custom page. Assuming that you're retrieving MTE by MTE Class, if the scope of the R3 systems in that page is large, i.e. with many SIDs, It will take a long time to display the page. Connections via TCP/IP to the agents seem to be made.

I would say appropriate sizing including proper load balancing would be important, due to mainly network implications.

Going through WAN to retrieve CCMS data increases the time for data collection and increase possibilities of a stalled situation for the agents, which may lead to CPU bottlenecks on monitored systems. I would especially not overlook item 3) and properly customize RZ20 to only show data which is truly necessary.

With regards to memory, DB space and filesystem consumption for CCMS, i believe there shouldn't be a really high usage. Alerts would still be using shared memory in the Monitored systems. Agent logs may sometime have error and lead to a large file size though.

[TomCenens]

Dears

Thanks everyone who contributed.

I was in touch with someone from SAP as well and he stated that the performance impact is very little or at least should be when you have correct support packages/patches and so on to avoid existing bugs.

Closing message down.

Kind regards

Tom