Subscribe

CPU Processing

I am fighting a high CPU issue on one of our controllers.  Within Performance Manger I can see CPU begin to rise at 8PM evey evening and then start to normalize at 10AM.  What tools or CLI\GUI items can I look at to dive deeper into what processes are utilizing CPU?  Is there a single way to see the deduplication schedules of all volumes at one time?  Thanks for the help.

Re: CPU Processing

Sis config will show dedup schedules.

Sysstat -m 1 to see CPU every second for all cores.

Priv set advanced ; Sysstst -M 1 to see domain usage. Uppercase M

Re: CPU Processing

Thanks Scott, I tried the sysstat -M in priv mode, but it did not work.  Running ONTAP 7.3.4.

It was definitely the dedup jobs, canceled everything and CPU dropped.  Bottom line is no one was changing the default dedup schedule from midnight every day.  Jobs were running and others were waiting in an idle state.

Re: CPU Processing

Hey Scott, I found the sysstat -M setting.  It is accessed by "priv set diag" not "priv set adv."

Thanks for the direction!

Re: CPU Processing

It should work under priv set diag ... or my memory is wrong that it was on 7.3.4.  Good catch on dedup...the sis config is easy to modify and often doesn't have to run daily depending on change rates for good efficiency.

Re: CPU Processing

BTW - high CPU is not a bad thing as long as your latencies are not suffering...

Re: CPU Processing

I thought high CPU creates resource contention among the volumes thus FlexShare would be used to prioritize the resources among the volumes.  This is what was happening with us.  CPU in the 90+ range and many VMs were running very slow.  When I got the CPU back down into the 70% range everything was normal.

Re: CPU Processing

run graphs through OnCommand console and DFM.

Re: CPU Processing

Like I said - high CPU is OK as long as latencies are not suffering. Once you start having performance issues, you need to look at the system and see what's taking resources.

In general, spreading out workload is a good idea. So, don't run all possible dedupe threads at once - spread them out, for example.