Did you try the dynamic list for websites in Plesk?
Right now there are many different view modes for websites and domains in Plesk. We believe that the dynamic list is the most advanced one. But since many people still prefer previous versions, such as the active or the classic list, we would like to know if you tried the dynamic list, and how it fits your needs.
For this purpose, please take part in the dedicated 10-minutes survey.
Your answers will help us to improve the website managing experience.
- Thread starter PedroV.
- Start date May 2, 2014
Hello, I have a wordpress website using Nginx with PHP-FPM but sometimes when I try to post a article give me a blank page. When I go to nginx error log I saw this: 2014/05/02 17:41:35 [error] 3184#0: *25722 FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 268435456 bytes exhausted [tried to allocate 196608 bytes]$server: domain.com, request:
"GET /wp-admin/post.php?post=135710&action=edit&message=6 HTTP/1.1", upstream: "fastcgi://unix:/var/www/vhosts/system/domain.com/php-fpm.sock:$ In PHP settings I have on memory limit: 24384M. But I think is need to raise the memory limit of FastCGI right? How can I increase? My server have 32GB of ram. Thank you
Regards,
Pedro
Last edited: May 2, 2014
Tozz
Regular Pleskian
- #2
You probably edited the PHP memory limit in the wrong place. Please create a new PHP file on this website containing: Then open the file in your browser and check for the PHP.ini file location. Then edit that file. PS: Your error indicates WP is trying to allocate more then 268 MB
of RAM. That is quite a lot just for posting a new article. It could be you have some out of control WP plugins.
Or, modify PHP.ini settings for this subscription in Plesk.
- #3
Thanks for the reply Tozz, I see in php file and shows me the memory_limit is 24384M. Yes appears to be a plugin that are using much resources but the error with memory of 268 MB doesn't make sense.
Tozz
Regular Pleskian
- #4
24G is alot of memory for 1 PHP script. What if you change it to a more sensible amount? Such as 2GB? Or maybe you can set it to 0, to set an unlimited amount. Also see:
//stackoverflow.com/questions/9276212/php-settings-memory-limits-1024m-does-not-work
As that thread suggest you might also verify that suhosin [if installed] is not causing grieve. You could try to uninstall suhosin, as it can cause troubles hard to diagnose. You can then reinstall it later on when necessary.
More broadly, you're failing to allocate memory inside the memcache module. That suggests that you have a single very large cached object [~47 MB, per the error message] that you're trying to load. In a server running under a 256 MB memory limit, spending almost 20% of it on a single object is not going to work out well.
In Drupal, this manifests in a few forms: you might need to "get over the hump" and that 47 MB is an intermediate object, in which case you'll see simple page loads succeed, then any that depend on that 47 MB object fail until one of them succeeds, then all loads succeed. Or that object might be agglomerative, in which case you'll see requests start off fine and then start failing later in the day. Or the object could be specific to particular parts of the site, or even a particular localization. It's really hard to know, and my point is that the symptoms don't always align and may even seem non-deterministic.
To debug, you could
start by either querying memcache directly to see what's in the cache of approximately that size, or by turning on detailed logging in the memcache module so it will tell you what it was attempting to GET when it failed. See the "Debug Logging" section of this link for details of how to do the latter, in D7 at least. You could also probably infer some additional context from the
full stack trace, if you have it.
Ultimately, as Bert alludes to here, debugging this might be well beyond the scope of what you'd like to do. In that case, increasing the memory_limit will certainly make the problem go away for now. While this seems like an easy way out, keep in mind that whether or not the issue will recur will still remain an unanswerable question until you do the debugging steps outlined above.