Server restarts?

received this email the other day:

[quote]Our monitoring systems show that your site is frequently reaching the technical capacity of its hardware. When this happens your website crashes and becomes briefly unavailable as we automatically restart it.

Here are the website usernames and how many times they were restarted within the last 30 days:

MYUSERNAME: 959[/quote]

It’s advertising Dreamhost VPS (and offering a free month) as a solution.
I’m running a few wordpress sites, nothing insane, but having to restart 959 times is a little crazy.

Is there a way to pinpoint what’s causing this? (is it even legit? I know I’ve had issues in the past where other users on the same server as me were DDOS’d and it took everything down…)

What type of plan are you on? Shared?


Shared hosting has limits on both memory and total CPU time.

What generally happens with wordpress is this plugin and that plugin get added. Memory usage grows. Sometimes those plugins are compatible with each other, others times the presence of one plugin will make another misbehave. Theme’s can also be memory hungry. There is no one single answer to what bloats wordpress. You might start here:

The email itself is interesting. I wonder if this specifically is a new type of procwatch notification.

I got the same email on April 11th. Never thought much about it, but when 10 of my 15 sites went down a few minutes ago I began thinking it through.

My “restarts” were at: “username1: 383, username2: 654”

That seems like a lot to me too, especially considering the 3 micro sites under username1 are getting maybe 2-3 visits per day, run simple sites with genesis platform themes (optimized and rather minimalist), and don’t have many plugins either.

On the other hand, the single site under username2 gets maybe 1000 visits per month and isn’t too resource heavy.

So, for both FTP users, I can’t imagine what would justify the email.


These emails are something new we’re trying out.

As LakeRat mentioned, there is something we run on our shared hosting servers called procwatch. It’s a homegrown monitoring utility that helps us ensure users aren’t breaking other users sites by consuming too many resources on a server. It allows some flexibility before acting and has a some built-in smarts so that it doesn’t do things like kill your shell sessions.

Procwatch looks at processes running on the server and is able to see similar information as you do when you run the top command. It knows the server username, process name, duration, and the amount of memory and CPU it’s consuming.

I’ve sampled a dozen servers today and about 90% of the time, processes are killed because they are consuming too much memory. And 99% of the time the process being killed is PHP.

There are lots of reasons that could increase memory consumption. It could be caused traffic to a site, a WordPress site with a lot of plugins, unoptimized code, hacked sites, many sites running under the same user, etc.

Unfortunately we usually don’t even know which site it is causing the problems because many users run more than one site under a user. We also don’t yet have a good way to expose this information in your control panel, but it’s something we want to do.

In the meantime, we’re trying out these emails and offering a free month of VPS hosting for those that want to try it. The offer is a no-pressure approach - you can keep your shared hosting as-is, work on optimize your WordPress site, or try a managed VPS server.

Hopefully that provides a bit of clarity into what these emails are and how we’d like to improve your shared hosting in the future.

+1 +1 +1

Now a user can know when they are getting procwatch kills.

I have been getting these emails about every week it seems. I don’t see enough traffic to be the root cause and I went to a VPS because I was having problems with the shared.

I am trying to figure out what is causing it and I have done pretty much all the optimization I can find.

I will say that I noticed that when I do a

“cat access.log| awk ‘{print $1}’ | sort | uniq -c |sort -n”

I saw the top ones were:



209 xxxxx -- me

I am thinking Jetpack might be a bit of the problem…