Important Notice:
Two sections of this forum are available only to registered customers. In order to receive access to the Customer Forums and ResellerCentral Forums, you must first register on these forums or login to your existing forum account. If you are an existing HostNine customer, be sure to register using the email address on file for your billing profile.
|
|||||||
![]() |
|
|
Thread Tools | Display Modes |
|
#1
|
|||
|
|||
|
Hi Guys,
Has anyone else had any trouble with the new 500MB memory usage (RAM) limits being imposed via CloudLinux on a number of servers? All of my sites are fairly plain-jane Wordpress installations, running only a few plugins and popular premium themes, but they're hitting the 500MB limit multiple times per hour, causing them not to load properly. I have deactivated plugins, updated themes, switched themes, installed caching plugins - the works. And nothing has helped all that much. I am pulling my hair out trying to get to the bottom of this. Have been for two days, actually. If anyone has any pointers, please let me know. I've been with H9 for a couple of years now with very few problems, and love the reseller backend, the features and options. I don't want to have to move, but right now many of my sites aren't getting the RAM they need to run properly, and I'm having trouble tracking down anyone that can help me diagnose the issue. In any case, the entries in my sites' error logs all look something like this: [Thu Apr 28 14:50:51 2011] [error] [client 75.xxx.xx.xxx] (12)Cannot allocate memory: couldn't create child process: /opt/suphp/sbin/suphp for /home/zicl/public_html/wp-content/themes/headway-101/media/css/layout.php, referer: http://www.examplesite.com/wp-conten...-101/style.css [Thu Apr 28 15:00:27 2011] [error] [client 75.xxx.xx.xxx] (12)Cannot allocate memory: couldn't create child process: /opt/suphp/sbin/suphp for /home/imq/public_html/wp-content/themes/headway-101/media/css/typography.php, referer: http://www.examplesite.com/wp-conten...-101/style.css And the WP errors logs have entries like this: [28-Apr-2011 04:32:37] PHP Fatal error: Out of memory (allocated 20447232) (tried to allocate 131072 bytes) in /home/imq/public_html/wp-includes/functions.php on line 3071 [27-Apr-2011 23:53:05] PHP Fatal error: Out of memory (allocated 18087936) (tried to allocate 78 bytes) in /home/zicl/public_html/wp-includes/formatting.php on line 949 Please, if you have any insight, advice, help, criticism, or just plain support, please let me know. I would be very, very grateful. Thank you! |
|
#2
|
||||
|
||||
|
Do you have single sites on the cPanel accounts, or are you doing multiple add on domains? The Wp errors show 19.5 Megabytes and 17.25 Megabytes, neither of which get close to the memory limit set, so I'm curious what else on that user id you may have running?
|
|
#3
|
|||
|
|||
|
Nope -- just 1 site per account, no add on domains or anything. Nothing else is (or at least should be) running on these accounts.
|
|
#4
|
||||
|
||||
|
I've taken a look at the server you're on, and there are very few people hitting LVE limits, so it definitely appears that it's something with regard to your particular sites, whether it's the traffic, the memory intensity needs of the theme, a plugin with a memory leak, I'm not sure (and I don't want to get too specific here on a public forum).
But there are other WordPress sites with similar specs on that server that are not making a blip on the radar of the server's resource management controls at all (or the top ten, top twenty and so on), so it seems to be something indicative to your set up. Extremely resource intensive sites could run into a problem with CloudLinux since CL is designed to prevent their taking down a server - without resource management in a shared hosting environment, a single site has the ability to use just about all available resources that are on a single machine. This can and does often lead to server instability where an entire server can screech to a halt and/or crash completely and need to be restarted because it's ability to give anyone resources for anything is stopped by a single site tying up the entire server. CL mitigates that by putting each site effectively into a VPS-like container. We chose the limitations of each LVE to be equivalent of the smallest VPS we offer (which would be one site without cPanel, so we figured that was an apt/fair comparison). So, one shared site gets nearly the same resource use ability that someone buying a $20/m VPS would, just without the VPS control. Now, previous to CL, we would deal with people that abuse resources if they negatively affected the server. You *could* have been outstripping your "fair" share of resources all this time and if it didn't cause a major problem, we may not have known. That risk of instability, though, isn't something that makes for great uptime and stable servers if someone wakes up and decides to get out of control, so to ensure that things crashed less and everyone has what they need, we opted to install something that automated that parceling out of cpu and memory. It changes the management from having to constantly be reactive to being proactive. If you had been suffering server issues because your neighbor was a resource hog, CL is going to dramatically improve your performance and you are likely ecstatic at the dramatic change. If you were one of the few neighbors hogging the resources but hadn't done so enough to actually crash or seize the server up? Well, this likely caused some problems for you, and it may have come as a surprise. But it also gives people easy, defined feedback regarding their sites - we can tell you exactly what you're allowed to have and exactly what limits you are hitting, and it will enable people to make a much better decision about whether they need a VPS or not. We can also provide a history of precisely what your site (container) uses. What we still can't do, though, is tell you precisely why your site is inefficient without some kind of audit, though we can make general suggestions based on what we've seen on the servers. In this case, there's a possibility that there's a memory leak with a plugin you are using, your traffic is simply higher and those simultaneous processes add up to a lot of memory use, your WP isn't optimized, your theme is too intense and, again, simultaneous users cause a problem due to that, your cache isn't working, and on and on. WordPress can run beautifully or, if it's loaded down, it can be incredibly inefficient. |
|
#5
|
|||
|
|||
|
Hi Jen,
Thanks so much for this thorough explanation of what CloudLinux is. I definitely understand why you guys are implementing it, and yes: 500MB definitely seems sufficient. Unfortunately, many of my sites which have issues have very low traffic, only 1-2 popular plugins, and a popular theme. I have tried deactivating plugins, changing themes, installing caching plugins, and host of other strategies -- all to little avail. While I totally see why you guys are implementing CloudLinux, it's tough to experience my relatively plain-jane and modest sites go down - sites I've spent years working to make successful - and be unable to get support or answers as to why this is happening. I am definitely not someone deliberately or irresponsibly hogging resources - that's for sure. But I need some help getting to the bottom of this. I can usually research the hell out of something, and after enough hard work and experimentation, figure out the answer. But this one has left me stumped. I would be willing to pay for you guys to, indeed, undertake a site audit. Or, if you could guide me in the right direction as to how to track down the source of the high memory usage, I could try to diagnose the issue myself. Either way, I would be hugely grateful for and appreciative of any additional insight, help, or support you could lend. |
|
#6
|
||||
|
||||
|
We've talked to the CloudLinux folks and there isn't a specific way, at this time, to pinpoint the high memory usage cause inherent in CL. That's pretty standard in Linux, though.
With ps or similiar tools you will only get the amount of memory pages allocated by that process. This number is correct, but it doesn't reflect the actual amount of memory used by the application, only the amount of memory reserved for it, and can be misleading if pages are shared, for example by several threads or by using dynamically linked libraries. We're still looking at tools that we may be able to use to profile memory usage at a more granular level (like valgrind), but in general it's a real hit or miss, trial and error kind of thing to fix unfortunately. |
|
#7
|
|||
|
|||
|
Thanks for asking the CloudLinux guys about this, Jen.
Argh...I just wish I understood more about this. We have sites on 4 different themes hitting the memory limits, which seems to preclude the theme as the issue, but we are having trouble finding any other constants. For instance, there is no one plugin that is being used across all of them. No apps, no cron jobs, nothing out of the ordinary. In any case, we have hired out a WP ninja to put some sites on a test server for the week and see if he can track down the issue. I will update this thread with our findings if it seems like anything that could potentially help others in the future. |
|
#8
|
|||
|
|||
|
Hi Jen,
Do you know of any difference in setup between uswest10 and the other servers which have been upgraded to CloudLinux? I ask because the sites I have on uswest10 are not having any issues whatsoever; in fact they are hardly using any RAM at all. But here's the kicker: a couple of them are exact clones (except for content) of sites on other servers that are using 10x more RAM and hitting the limit. Same themes, same plugins, same permalink structure. They were in fact cloned in every way except content, and they get less traffic. So if uswest10 is set up in some slightly different way, could that point to what my issue is? Thank you so much in advance for your time. |
|
#9
|
|||
|
|||
|
Well first of I can confirm you are not alone, I too am seeing the same problems.
I can confirm that near identical sites running on different servers are responding different at the moment. I have approx 50 sites running wordpress with H9, and approx 50% are effected in some way by the recent changes. All run the Latest Wordpress with All in One Adsense Auto Tags Easy Privacy Policy populair-tags Sitemap Index StatPress W3 Total Cache WP Database Optimiser I have tried disabling plugins in turn\in bulk - with no benefit I have cleaned out unused options - with no benefit I have changed memory limited within PHP and WP again with no benefit. My current theory is that the MySQL memory is getting hogged on some servers and not others. Can H9 confirm that the my.cf settings are the same with respect to memory\caches etc. on all their shared servers? |
|
#10
|
|||
|
|||
|
Hi Drum,
It's good to know I'm not alone (although I'm sorry you're having to deal with this too). Thus far, the WP expert I hired to look at my sites for memory usage problems has not been able to replicate the issues on his own test servers...so I can't say I'm convinced that our sites are the problem here. Have you looked at the Resource Usage section in the cpanels of effected sites? Are they pegging that 500MB RAM limit pretty often? |
![]() |
| Thread Tools | |
| Display Modes | |
|
|








Linear Mode
