Performance emails suggesting VPS upgrade?

vps

#1

I’ve been receiving emails from Dreamhost Customer Experience over the last 6 months advising that my site (on shared hosting) is reaching the technical capacity of it’s hardware from time to time and requires restart and subsequent brief down time.

These emails are pointing me toward some optimization knowledge and a nudge toward an upgrade to VPS.

I don’t know what to think about this as the site in question is a WordPress site running 5 very established plugins (Akismet, Fast Secure Contact Form, Jetpack, Better WP Google XML Sitemaps, Elegant Themes Updater) and when I look at my analytics I don’t see anything too alarming regarding traffic (less than 20 visitors daily).

Does anyone have any first hand experience with these emails? I don’t know if I should treat them as something I should be worried about and get stuck into, or if it’s just an annoying FUD upsell.

Been a while since I touched base with anything Dreamhost, hope to find good people as always and I thank you in advance for any help/opinions


#2

No first hand experience of these emails. If 20 visitors daily is causing alarms - then that sounds worrying to me. Possibly one of the plugins is acting up.


#3

That’s a possibility. Another is to look deeply at the account and see if there are other scripts running outside of WordPress, like cron jobs. Or if there are other users attached to the same account running other websites/scripts. Or something malfunctioning on DreamHost side (also a possibility :slight_smile: .)

This thread has some more details on how the limits are calculated and some ideas on what may be going on.

Let us know if you see other things, otherwise it’s a good idea to double-check with Support what the root cause of your site hitting the limits.


#4

Thanks for the feedback y’all. I will run with it and see what can be seen.


#5

As I said over on another thread, after some support give-and-take, I learned that one should have a different user for each site. If you have only one site, then that’s not the answer! Hate to think that this is all an upsell!


#6

I am getting those emails too, I don´t know what to make of them because there are no details other than I am hitting the server limits. The site appears to run fine when I visit it…


#7

@malcarada I suggest you to read this thread, the Knowledge Base articles about procwatch and maybe also search the forums for ‘procwatch’ to learn more about what may cause these issues. You can solve most of these by yourself given enough time and knowledge, or you can contact Support to have them investigate and give you more suggestions.


#8

I was getting those e-mails when my website was on PHP 5.6, but since upgrading to PHP 7.0, I haven’t had any problem.


#9

They are something new we’ve started trying around the middle of this year.

For a little background, “procwatch” is a service that runs on all shared hosting servers that tries to ensure fair usage of its CPU and memory resources. It has some intelligence built into it instead of just blindly killing processes that exceed some set limit. That means sites can get a little more resources for small spikes in traffic when the server isn’t overly busy and we don’t kick you out of your SSH sessions. If it does kill a running process, it usually means that something temporarily stops on your site. It could be a valid page request, a long-running upload, or in most cases, a WordPress plugin or theme that becomes a memory hog. (I can’t stress enough how much caching helps a WordPress site!)

In the past, when customers have bumped into the limits of their shared hosting account and the server didn’t have anymore to give, procwatch would dutifully kill the process and the site owner usually never notices. We’re using these emails as a way to let customers know this is happening so they can take action if they want to.

The bad news is that it’s very hard to diagnose the problem programatically. It takes the site owner, and/or our Tech Support team, to look at the site and logs to determine why it’s using a lot of CPU or memory. Sometimes it’s fixed with a simple config change, enabling caching, or upgrading to a VPS to have more memory. If you think the latter may be best, we’re offering a free month of VPS service so you can try it risk free.

We’re still working on the emails to provide better information. Right now procwatch only reports the server user that is running the process that was killed (because users own processes in linux). The next iteration should report the website(s) that user owns and we can include that in the email. Depending on how useful these messages are, we’d like to add these as notifications in the control panel instead of emails.

We’ll keep refining the messages to provide better information. Please let me know if there’s any changes you’d like to see and we can try testing that too.

Hopefully that helps provide some context around these emails and what we’re trying to accomplish. It’s all about providing you with more information about your website and making sure you’re using the best hosting option for it.


#10

Thank you, Justin. That was very helpful.

I know for me, it was oftentimes a plugin that was incompatible with my version of Wordpress. Also, I’d often see like 5 or 6 php56 processes taking up much of my RAM.

Perhaps the email could include a snapshot of the processes taking up the CPU.


#11

I thought this was interesting so I did a quick test. I sampled 8 machines over the last two weeks and over 98% of the processes killed by procwatch were PHP! Lots of php56 processes so one approach we can look at is to suggest upgrading to PHP 7.


#12

I upgraded to PHP 7 when I got an email saying there were performance updates coming to my DreamHost VPS and logging in to my panel saw that PHP 7.0 was now the default.

I was surprised it wasn’t automatically updated since I had “Automatically upgrade PHP” checked. I also then turned on PHP OpCache support.


#13

+1 to add a snapshot of the ps that is being used in the determination.

From @justinlund " It takes the site owner, and/or our Tech Support team, to look at the site and logs to determine why it’s using a lot of CPU or memory." … The site owner can only help in that process if the site owner has the log. :slight_smile: Obviously if Support can go back and look at logs, the data is available.

I have several sites in shared space being killed every day by procwatch. They get almost no traffic otherwise and I believe the trigger here is a remote backup process that’s hitting all of them simultaneously.

Yes, shared space has its limits. Yes, I’m moving to VPS. Yes, I’ll move sites to unique users. I can solve the site issue. But my point is that while this issue persists it would be nice to see a log that verifies exactly what the problem is when the sites are killed. That would be a test of the utility of procwatch itself and its ability to explain why it’s taking action. Then emails or dashboard notifications wouldn’t be questioned as “up-sells”, the evidence would be right there for anyone to see.

C’mon DH. You’re smart people but you move at snail speed when we’re seeing issues (not just this) daily over a period of years. That doesn’t reflect well on the brand.


#14

Hi @justinlund ,

I just got one of the e-mails saying my VPS exceeded memory allocation.

When I look at my VPS dashboard, it says I’m using only 8.6% of the RAM.

But, when I ssh into my VPS, top -c showed it would be more like 80%. Why would there be such a discrepancy?

Also, I think my nightly backup process of my WordPress site with UpdraftPlus was running, because the memory used did drop after I got an email saying the backup was successful. All WP plugins are current versions.

Here is the output

    Tasks:  29 total,   1 running,  28 sleeping,   0 stopped,   0 zombie
Cpu(s): 22.6%us,  3.0%sy,  0.0%ni, 72.9%id,  1.0%wa,  0.0%hi,  0.6%si,  0.0%st
Mem:   1024000k total,   893496k used,   130504k free,        0k buffers
Swap:        0k total,        0k used,        0k free,   821800k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7074 micpol26  20   0  407m  66m  49m S    0  6.6   0:10.56 php70.cgi
22215 dhapache  20   0  199m  18m 2672 S    0  1.8   0:00.08 /dh/apache2/apache2-ps576031/apache2-ps576031-httpd -DModSSL -d /dh/apache2/apache2-ps576031
 6262 root      20   0  198m  17m 3808 S    0  1.8   0:02.61 /dh/apache2/apache2-ps576031/apache2-ps576031-httpd -DModSSL -d /dh/apache2/apache2-ps576031
32740 dhapache  20   0  199m  17m 2612 S    0  1.8   0:00.03 /dh/apache2/apache2-ps576031/apache2-ps576031-httpd -DModSSL -d /dh/apache2/apache2-ps576031
 6441 dhapache  20   0  198m  14m  676 S    0  1.5   0:00.02 /dh/apache2/apache2-ps576031/apache2-ps576031-httpd -DModSSL -d /dh/apache2/apache2-ps576031
 6266 dhapache  20   0  197m  14m  352 S    0  1.5   0:00.00 /dh/apache2/apache2-ps576031/fcgi-pm                -DModSSL -d /dh/apache2/apache2-ps576031
 6108 mongodb   20   0  623m  12m 1788 S    0  1.3   0:11.21 /usr/bin/mongod --config /etc/mongodb.conf
 6857 root      20   0 59676  10m 1048 S    0  1.0   0:00.16 /usr/bin/python /usr/bin/supervisord
26560 root      20   0 4093m 5328 2884 S    0  0.5   0:00.22 /usr/sbin/console-kit-daemon --no-daemon
26673 micpol26  20   0  129m 5076 1708 S    0  0.5   0:00.18 -bash
 6145 root      20   0 16532 4252 3392 S    0  0.4   0:01.24 /usr/bin/atop -a -w /var/log/atop.log 600
23344 root      20   0 79876 3632 2796 S    0  0.4   0:00.00 sshd: micpol26 [priv]
 6996 root      20   0  535m 3468 2268 S    0  0.3   0:02.46 collectd -C /etc/collectd/collectd.conf -f
26648 root      20   0  190m 3428 2764 S    0  0.3   0:00.00 /usr/lib/policykit-1/polkitd --no-debug
 5975 root      20   0 50036 2788 2192 S    0  0.3   0:00.01 /usr/sbin/sshd -D
 6964 nobody    20   0  153m 2088  620 S    0  0.2   0:00.00 proftpd: (accepting connections)
    1 root      20   0 23800 1784 1340 S    0  0.2   0:00.04 /sbin/init
 5988 root      20   0  179m 1664 1280 S    0  0.2   0:00.04 rsyslogd -c5 -n
 6829 root      20   0 25100 1652 1348 S    0  0.2   0:00.00 /usr/lib/postfix/master
26672 micpol26  20   0 79876 1640  804 S    0  0.2   0:00.00 sshd: micpol26@pts/168
 5958 messageb  20   0 23812 1608 1300 S    0  0.2   0:00.00 dbus-daemon --system --nofork --activation=upstart
 6835 postfix   20   0 27216 1600 1320 S    0  0.2   0:00.00 qmgr -l -t fifo -u -c
 6834 postfix   20   0 27164 1592 1308 S    0  0.2   0:00.00 pickup -l -t fifo -u -c
 3585 micpol26  20   0 17196 1356 1088 R    0  0.1   0:00.12 top -c
 6110 root      20   0 19356 1164  928 S    0  0.1   0:00.00 cron -f
 6535 nagios    20   0 25428 1024  640 S    0  0.1   0:00.06 /usr/sbin/nrpe -c /etc/nrpe.cfg -d --no-ssl
 6101 daemon    20   0 17152  760  600 S    0  0.1   0:00.00 atd -f
 6979 root      20   0  4288  268  180 S    0  0.0   0:00.12 /usr/sbin/collectdmon -P /var/run/collectdmon.pid -- -C /etc/collectd/collectd.conf
 6053 root      20   0   188   32   12 S    0  0.0   0:00.00 runsvdir -P /etc/service log: .....................................................................................

#15

@mikepolinske unfortunately neither top nor the VPS dashboard on DreamHost panel alone will give you a precise view of what is happening inside your machine. The way the VPS technology is architected, the various ps, top, ntop etc will give you information that is not necessarily relevant to your user. In any case, those tools will only tell you what is happening to your server now and not show you what triggered the email notification.

I wrote two guides on how to install New Relic on DreamHost VPS exactly because I wanted to get a clearer picture of what happens inside WordPress (or any application, really) with high levels of details.

I have on my wish-list a tutorial on how to install Datadog on VPS too but haven’t had time. If you’re interested in researching that option I’d be glad to help.


#16

Thanks @smaffulli. I will check out the link tonight when I get home.


#17

Well, I’ve got New Relic all set up on my site. It looks like they capture quite a bit of information.

I am on the Lite plan, so hopefully it doesn’t limit me too much.

Thank you for your help.

Will New Relic send out e-mails when they have new releases? Or will I need to check the site to see if I need to update my site?


#18

that should be enough for you to get some ideas.

IIRC, you need to keep an eye on things yourself. I have updated the monitors a couple of times but I don’t remember if I received an email or noticed there was an upgrade pending on NR dashboard or somewhere else.


#19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.