Hello,
We are having stability problems on our Drupal site. We have a dedicated server which runs mainly our Drupal site and couple of other small sites. Daily visitor is around 20.000 and around 17.000 is on Drupal and only 200-300 are registered.
We have Gainestown E5520 8 cores(running as 16 cores) CPU with 8 GB ram and fast disk configuration enough. As all can guess hardware infrastructure is well enough to manage whole work. Configuration is simply:
PHP 5.2 cgi mode
Apache 2.2.14
APC installed, MPM_WORKER
Suhosin
Drupal core 6.18 with updated boost module for performance with default settings.
Mysql 4.1.22
Currently Drupal site is waste of stability. And time by time(nowadays almost everday) mermory failures which results with apache restart and downtime at least 8 minutes.
Hosting company has not been working on the issue enough to check what the problem is. They only say APC is causing the memory leaks.
So we need to solve our problem by ourselves, who are only developers of Drupal. We have been googling on the issue till now not yet any result.
Could you please suggest a roadmap or any idea to fix the problem? Any help would be appreciated!
PS: If you need any information of configuration files ..etc please let us know.
Comments
Example of error message
As a note:
PHP Fatal error: Out of memory (allocated 52690944) (tried to allocate 8208 bytes) in /home//public_html//includes/menu.inc on line 637
Well if it's APC that's
Well if it's APC that's causing the problems than I can fully recommend Xcache. If you have the opportunity to switch then you can at least see if that's the problem. What OS are you running?
The hosting company is
The hosting company is reporting it as APC. Actually they had this just to skip the subject. But we contact with them to switch APC to Xcache. Or if they have any previous experiment on xcache I will let you know.
Thanks for kind reply.
The error message appears to
The error message appears to be corresponding to your setting of the memory_limit variable in php.ini which has nothing to do with APC. Give your PHP scripts a little more space to breathe ;)
But this does not result in crashes. Instead for that specific request the user gets a WSOD (white screen of death). There should be other error messages in the log corresponding with the crashes.
Is there any specific reason behind the decision to run PHP as CGI?
High performance Site
Up your php memory setting.
Read this article: http://groups.drupal.org/node/18177
Install the lock patch & the faster menu router build patch; should help with Drupal's stability under heavy load.
http://drupal.org/node/251792#comment-2125124
http://drupal.org/node/512962#comment-2505654
Hi, I do not want to make
Hi,
I do not want to make this a support thread, but I think these are also related with performance somehow.
Our php memory limit is 128 MB, I think this is more than enough.
The error I gave about menu.inc happens in other files as well when I refresh the page or sometimes it raise error within another file; so I do not think it is something menu specific.
For the CGI part, we are using mpm_worker since the server is high on the cpu side and told that this will help reduce memory load. As a result of this, mpm_worker cannot work with mod_php.
When we get lots of these errors, the server becomes instable and the support team on the hosting side increase apache maxclient settings; and when lots of memory consumed because of this, they decrease it :) .During this touch we are loosing about 8-10 minutes with downtime.
Anonymous user are much more than the registered users. FYI
How can we narrow this subject? If any configuration file helps, I may send it here.
PHP memory limit
I know you feel 128M is enough, but you really should look at increasing your PHP memory limit. Most of my Drupal sites run with a php.ini memory_limit of 512M or higher. 128M seems a bit small to me if you're using APC, especially if you're using cacherouter. I regularly see utilization (via apc.php graphs) in excess of 512M on my heaviest-loaded servers.
-Greg
512 MB ?!?!?! I've worked on
512 MB ?!?!?! I've worked on a few dozen sites over the years and never had one more than 64MB. If you need half a Gig of RAM to render a page that's the sign of a serious bug.
Someone correct me if I'm wrong but the PHP memory_limit has nothing to do with the amount of memory that APC consumes. The memory_limit is what PHP uses internally for things like holding your arrays and such. APC is either an opcode cache (in which case the memory it uses is the compiled PHP code), and/or as a cache for No-SQL (in which case the memory it uses is your cache objects - anything that runs through cache_set()) and has its own separate configuration for the amount of memory it consumes.
--
Dave Hansen-Lange
Director of Technical Strategy, Advomatic.com
Pronouns: he/him/his
Apparently my brain is swiss
Apparently my brain is swiss cheese. That'll teach me to post before caffeine. I was thinking of my APC memory limit, not php.ini. That 512M including the opcode and various other chunks of cache data cacherouter sticks in there.
No, I'm not talking about 512M just to render a page. :-) Sorry for the confusion.
-Greg
Out of curiosity what version
Out of curiosity what version of APC are you running? There are memory leak problems in some of the older versions.
HollyIT - Grab the Netbeans Drupal Development Tool at GitHub.
What best for d6 on
What best for d6 on litespeed?xcache,acce or APC?
APC version, static content
intoxination already asked the most important question here; what version of APC are you using (apc.php will show that, so will phpinfo() ). It's imperative to keep up to date with the latest releases of APC right from Pecl, don't wait for your distribution to catch up. There have been some pretty annoying/severe bugs in APC which can cause all kinds of weird problems and stability issues.
But it's weird that this manifests itself as 'out of memory' errors in PHP. Can you grep your Apache error log for those errors and post a few of them?
It also would be a good idea to try another opcode cache just to see if APC really is the problem.
Some recommendations:
- Put something in front of Apache to handle all the static content, this reduces load/memory usage in a big way (varnish seems to be a nice solution in combination with Drupal, also check out Pressflow)
- Move PHP back to the 'normal' prefork mod_php5 setup
Previous have been using
Previous have been using Nginx 0.8.52+PHP-FPM+APC 3.1.2 (and 3.1.3p for testing) along with boost installed.
Performance was fine until APC cache memory was filled with compiled scripts. Then php-fpm sometimes was unresponsive, which meant it had to be restarted manually.
Decided to try out eAccelerator -- now my vps is running quite stable and fast.
Correct me if I'm wrong, but
Correct me if I'm wrong, but isn't APC all but useless if you are running PHP in CGI mode? Since no memory can be shared between the different processes in this configuration you end up consuming MUCH more memory with virtually no benefit.
If you are going to run APC, you really need to run mod_php. If you have other reasons for running in CGI mode, then you should use memcache instead of APC as that uses a separate daemon for the caching and will actually share cache between threads.
Also, the first suggestion made here should be: Pressflow!
APC isn't useless for
APC isn't useless for PHP_FCGI mode--in fact it uses shared memory. That's what option apc.mmap_file_mask is for.
So whats the commen concensus
So whats the commen concensus on apc memory useage? I have 1.5gb of memory on a vps.... how much can I give untill it affects the total number of users logged in?
www.thecenterofthenet.com
http://cn.linkedin.com/in/roberpteatonjr
http://www.facebook.com/robertp.eaton
http://www.alamy.com/stock-photography/6A42F1A1-E40A-48FD-8C7F-FF258A401...