Occasional issues on site5

Hi,

I'm posting this here to see if anyone else is in the same boat as I am.

I have a few modx sites on site5 and every so often the server slows down tremendously. Their support alerts me to sites using up a lot of CPU and these are mostly modx sites. I have their VPS4 option which I believe should have more than enough horsepower to run my sites.

Here is part of their last msg to me:

User Domain % CPU ▴ Process
jta jtasupermarkets.com 66.0 /usr/bin/php /home/jta/public_html/home/index.php
insight insightevaluations.com 57.0 /usr/bin/php /home/insight/public_html/admin274/removeshopper.php
jta jtasupermarkets.com 56.0 /usr/bin/php /home/jta/public_html/home/index.php
jta jtasupermarkets.com 47.0 /usr/bin/php /home/jta/public_html/home/index.php

THe insightevaluations.com site is not modx, but jtasupermarkets.com is.

Is there anything I can do or anything I can have the host check for me?

Thanks.

Can you match the excessive CPU usage times to any particular type or pattern of traffic in the access logs? Like trawling by a particular search engine? Or after a mailing list is sent out?

Thanks for this - good question and will check with the host now.

The company I work for has several VPS's on site 5 ( all VPS 7, 8 or 9 ) with around 600 sites hosted on them.

In my experience with them they blame the first site that may be using a few resources and to be honest their support isn't anything to shout home about as everything has to be escalated above chat.

Really wish we could find a decent host that supports Modx and actually has a idea about what there supporting as site 5 don't ( but around the same price, currently spending around $2000 a month with them ).

For example they will say this site is the issue, so I move that off the server and the server still has the same issues, then the next site is to blame and i move that one etc etc ....

But that said I have a personal standard reseller account that never goes down, so maybe there just better at the little stuff.

There shouldn't be any technical reason for the server to slow down. Xen allocates the resources up front, so they shouldn't be able to oversell the resources. I would focus them on what is causing the resource usage (ex: imagemagick/gd).

I suspect in most cases they are dealing with smaller websites that are poorly constructed, so blaming the script is far easier than investigating the cause. I know we have installed NewRelic for some of our clients to isolate resource usage problems. You might consider asking their support to install it.

Thanks a lot for the replies, guys.

I'll take a educated guess that it's the use of phpthumb on the frontend for generating your recipe thumbnails on jtasupermarkets.com. If you clear the cache and have to regenerate all those thumbnails at once, it can place tremendous load on the machine - I've seen phpthumb bring a 16-core, 32gb VPS to it's knees in this exact scenario.

Note, I'm talking about CPU load and not % here, a higher load average means requests are getting queued and having to wait for available CPU time to process.

I would recommend looking at phpthumbsup for the frontend, it's an alternative to phpthumb and handles thumbnail generation in a slightly different manner which may help in this situation.

Garry is right, image processing can kill a server very fast.

If you don't feel like updating calls you can replace phpThumbOf with pThumb. It resolves quite a few issues while sharing the same namespace, so an easy replacement.

In the case of a site with a lot of image processing, it might be worth considering the tradeoff of having two images for each one displayed, a thumbnail and a full-sized image for other displays, such as a "lightbox" effect or for individual item displays. Of course this takes more time and work on the part of the web manager, but it would eliminate the server overhead of processing all the thumbnails.

Another way to minimize such things would be to use AJAX requests for paging, thus the server only needs to process and feed a few images at a time - this would have the added benefit of having the browser only downloading the same smaller number of images at one time.