Solved

additional setting to limit cpu usage on Oracle servers

  • 3 January 2023
  • 9 replies
  • 777 views

Userlevel 3
Badge +10

Some years back we ran into a problem with cpu usage spiking during backups and someone in commvault suggested an additional setting that limited cpu usage it leveraged the OS to prevent cpu usage going through the roof and was expressed in percentage. 
i forget the name of the additional setting. Can someone help?

thanks.

icon

Best answer by Orazan 3 January 2023, 21:50

View original

9 replies

Badge +15

What agent? Here is just a quick search for the work "cpu” and you can maybe spot the key there based on the agent.

 

https://documentation.commvault.com/additionalsetting/?q=cpu

Userlevel 6
Badge +15

This should do what it is you are looking for with the Oracle agent:

https://documentation.commvault.com/additionalsetting/details?name=sSDTHeadMaxCPUUsage

Userlevel 7
Badge +19

I truly hope Commvault adds smartness to reduce the impact of the backup on application performance automatically and integrate this option more visible in Command Center. We hear customers complaining quite often when the backup is impacting application performance while running application-level backups quite often.

Userlevel 6
Badge +15

I do not believe a setting like this will be added without it being behind an additional setting.  Too often when a setting like that is easily available, we see customers mess with the setting causing negative impact to backups  Pros and Cons to having this type of setting easily accessible.

Userlevel 7
Badge +19

I agree, but often this is also because it wasn't implemented in a correct manner and not well explained and/or documented. As said the best way would that the software itself, for example based on defined RPO, decides how much resources it needs to claim to be able to satisfy the requirement and to be able to create the recovery point in the given RPO period. 

The current implementation with tons of additional settings, from which a large part is also not documented, also comes with a lot of downsides and issues because they are poorly documented and most often customer forget they implemented it. 

Userlevel 7
Badge +16

I would not expect automatic implementations of such limitations / throttle settings, in my experience this mostly is a resource/sizing issue on the VM when such settings are needed. What I do would like to see are DB backup settings regarding compression and block sizes, depending on application specific settings this can have a big impact on CPU usage as alignment between the backup and application is off.

Badge +3

Hi Chris,

 

  Can you try this? This will limit CPU usage of processes launched by Cvd when you set ‘1’ (for low priority)

 

  https://documentation.commvault.com/2022e/expert/8558_changing_priority_of_communications_service_cvd.html

 

Thanks

Prakash

Userlevel 7
Badge +19

I would not expect automatic implementations of such limitations / throttle settings, in my experience this mostly is a resource/sizing issue on the VM when such settings are needed. What I do would like to see are DB backup settings regarding compression and block sizes, depending on application specific settings this can have a big impact on CPU usage as alignment between the backup and application is off.

Well we have a different opinion on this I think. The biggest part where Commvault can make a difference is reducing day-2 operations for customers and consumers. Commvault is still perceived as difficult and complex by a lot of peple and as an example the additional settings capability also contributes to this. Yes, not every setting can be brought in the UI, because all these options will introduce another form of complexity. Looking at market developments and also what we see within our customer teams is that real in-depth knowledge of Commvault is only available in the platform team and these people are not responsible for the workloads themselves. Same thing applies to Metallic in where Commvault is responsible for the backend infrastructure and because in-depth technical information is not available on the documentation it thus means new customers or Commvault/Metallic consumers will not adopt a lot of technical knowledge how it really works and have less understanding that there are hidden settings which might help. 

Most of times the backup will just work out fine just after implementing it, but as the workloads gets bigger and/or matures things might start to work out differently causing problems. Now you could indeed argue that this might be a resource issue on the source, but most of the times the RPO window is satisfied quickly meaning Commvault could automatically slow down, thus reducing load, while still meeting RPO SLA. Adding resource just to prevent this from happening also means adding cost and there is no need to do it. 

Other thing they could do is introduce some alerts/events. They gather so much information these days including performance statistics, so one of the things they could also do is monitor and alert on the effects of the backup on the client. In case performance is really degraded just because the backup kicks in and there is no logic yet to tune it automatically than why not inform the customer that there are things to consider looking into:

  • Reduce readers
  • Limit CPU affinity (in case IO latency remains low)
  • Increase IO performance
  • Add blackout window to prevent backup from impacting application performance during peak hours. 
  • ….

Now there are definitely cases in where the source is lacking resources and there are application side tweaks to put in place, but if you take into account the RPO than most of the times there is no need to increase the resource (also comes with cost) and implement tweaks. 

Userlevel 3
Badge +10

Well we have a different opinion on this I think. The biggest part where Commvault can make a difference is reducing day-2 operations for customers and consumers. Commvault is still perceived as difficult and complex by a lot of peple and as an example the additional settings capability also contributes to this. Yes, not every setting can be brought in the UI, because all these options will introduce another form of complexity. Looking at market developments and also what we see within our customer teams is that real in-depth knowledge of Commvault is only available in the platform team and these people are not responsible for the workloads themselves. 
 

I really don’t think this is a thing that can be fixed and certainly doesn’t apply to just Commvault. 

I think there exists tiers of knowledge in every organization and there is simple no way to get ride of those tiers, I think the issue is how each tier communicates with each other. At every level of the tier the people existing laterally in that tier may be aware of issues that people in the tiers above and below them do not consider. 

 

There is also the tradeoff between how does x thing affect performance for how many people.

In a situation where lets say %97 of the time the product give optimal performance with certain settings disabled, it would be unfair to enable to setting for %3 of people.

In other words it’s not so much that I agree or disagree with either of but talent and time is limited and therefore the allocation of that time towards any given issue has to be justified across a broad range of properties. 

 

 

Reply