Topic: Excessive CPU usage

[shnazzle]

I have level 1 file based caching enabled.
One thing I tried, which has yielded good results..
I've disabled our SMF Packs Shoutbox plugin.
We've had two little spikes into "very high" very briefly, but that's it.
We used to be hovering in the very high range with peaks into "extreme".

It might be a coincidence, and I guess I could verify by turning it back on, but I don't want to be shut down again

Image proxy is off. I had read about the https issues so as we're running https...off

[Aleksi "Lex" Kilpinen]

Anything that works "realtime" - such as shoutboxes, notifications and so on, can cause a considerable increase in CPU load.  If turning off features like that solves the issue, then you probably found the culprit. But often, the EIG -style limits on any resource tend to be pretty arbitrary, and basically only exist to limit resources that were originally sold basically "unlimited".

[Virus-X]

Has anybody experienced any extreme cpu usage since installing RC2?

HostGator shut us down last night for having 3 stints of 90+ seconds in the "Extreme CPU Usage" bounds.

I've shut down shoutbox, which is the only plugin I've got installed. But it never did this on 2.0.15.

What activities could cause a lot of cpu processing in 2.1 RC2?

How about your other plugins? If you believe this plugin has error, please try to remove it.

[shawnb61]

I have level 1 file based caching enabled.
One thing I tried, which has yielded good results..
I've disabled our SMF Packs Shoutbox plugin.
We've had two little spikes into "very high" very briefly, but that's it.
We used to be hovering in the very high range with peaks into "extreme".

It might be a coincidence, and I guess I could verify by turning it back on, but I don't want to be shut down again

Image proxy is off. I had read about the https issues so as we're running https...off

In my experience, CPU spikes are typically caused by crawls.   Look at your web logs and determine who the culprit is.  Somebody hitting your site several thousand times an hour isn't hard to spot in the web logs! 

If it's Google, throttle them in Google webmaster tools. 

If it's someone else, block them. 

As noted above, I use Hostgator.   It may also be that Hostgator is squeezing their users.  That is almost certainly part of it.  For whatever reason, crawls didn't bother me in the past, but they do now. 

I'm still on the fence whether to leave HG in the future.  On the plus side, I have never had issues with uptime or support - they've always been rock solid.  But on the downside I really don't like their backup policies & pricing.  And I suspect they are squeezing resources - as shown by sensitivity to crawls. 

[drewactual]

fwiw HG has a great dedicated server program.  its not cheap @ $3500 a year, but down time is exceedingly rare. 

back to the OP:  you may consider using an htaccess entry to throttle your php.  if there are some rogue scripts running they can consume a LOT of processor power, especially when they edge up to the cutoff limit regularly... I've set mine, as a for instance, to 30 seconds.  if even a robust search is called, it will die in 30seconds, as a for instance... and if a script regularly takes that long, it's likely i'd be needing to visit the coding and come up with a cleaner way to do it. 

i throttle the timeouts to 30 seconds and the memory to 16mb max per process. 

[Aleksi "Lex" Kilpinen]

IMO that's not really a very good idea. If you run to situations where you need to kill processes to conserve resources, you should get more resources.

[drewactual]

oh it certainly wasn't SMF snatching up those resources- it was a poorly written code even by php4 standards, and heavily searching a cumbersome and massive database and while running on php5.6 at the time and data from a >4.xSQL on a 5.4SQL... SMF is clean- nothing from it has ever taxed the system like that thing did. 

^it's for that reason i wonder what is gulping down the OP's resources.  Now that my (SMF+WP) primary site is so clean, i wager i could support it's traffic and weight on a shared environment with little issue.  NOT before, though, with that other function running on it.   

[shnazzle]

Our "guy" that we've just introduced made a good point. Or at least, seems like a good point.

We're on hostgator shared hosting. And while we generally tend to run within the high to veyr high band, it's sometimes that we are just under Extreme and then when we go over we're hit with enforced shut-downs.
So the logic seems to be that we may be sharing our hosting with some other very heavy users. So when what is usually "very high" for us on a normal day, when someone else absolutely rams their service, it becomes a "extreme" as a percentage of the total available for the shared host.

I'm not sure it's scaled that way, but the other day our site wa sdamn near unusable, and all of a sudden it was flying again.

[shawnb61]

I've been shared on HG for years.  I've never seen someone else's traffic affect my CPU.   

The CPU charts always track perfectly to traffic on the web access logs.  I download the most recent day or two of logs and analyze them in Excel to identify the culprit.

When I see wide swings in CPU, the cause is always crawls.