Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I thought this might be a StackOverflow question, but I found Nginx+php5-fpm being discussed here at What is wrong in my php-fpm configuration? so I'll post here. Other research done is multiple searches relating to slow wordpress with similar config, but in all other cases I could find, it was front AND back ends slow, not just the admin. Here's my spec:

Wordpress 3.3 on Ubuntu 11.10 + Nginx 1.0.10 + php5-fpm 5.3.8 + ISPconfig + 256Mb VPS

Rnning a Zen Cart store and phpbb3 as well, both in different php-fpm pools. There's hardly anything running except the essentials and both those sites absolutely rocket along. As does the front end of the Wordpress site, when W3TC accelerated.

BUT.... the admin side takes 6-10 seconds to do anything. There's nothing in the mysql slow log, or the php-fpm error log, the load doesn't spike, and the memory usage doesn't shoot up (but see below about memory).

The first time it loads, at wp-admin/options.php it shows a very long page that looks wrong, with line after line of stuff like...

active_plugins SERIALIZED DATA

Here's the main items from

732.0 KiB +  87.5 KiB = 819.5 KiB       bash
  2.1 MiB + 369.0 KiB =   2.4 MiB       fail2ban-server
  1.8 MiB +   2.0 MiB =   3.9 MiB       nginx (5)
  5.1 MiB +  12.8 MiB =  17.9 MiB       php5-fpm (29)
 87.8 MiB + 149.0 KiB =  88.0 MiB       mysqld
                        116.2 MiB

Here's the load average pretty much all the time: load average: 0.48, 0.53, 0.51

And here's the output from free -m

             total       used       free     shared    buffers     cached
Mem:           241        202         38          0          3         49
-/+ buffers/cache:        149         92
Swap:          511         29        482

Here's the nginx.conf, including the cloudflare real_ip settings (tried without cloudflare too), and also the rewrite required to make permalinks work under nginx:

server {
        listen 31.172.x.x:80;


        root   /var/www/;

        index index.html index.htm index.php index.cgi index.xhtml;

        error_page 400 /error/400.html;
        error_page 401 /error/401.html;
        error_page 403 /error/403.html;
        error_page 404 /error/404.html;
        error_page 405 /error/405.html;
        error_page 500 /error/500.html;
        error_page 502 /error/502.html;
        error_page 503 /error/503.html;

        error_log /var/log/ispconfig/httpd/;
        access_log /var/log/ispconfig/httpd/ combined;

        ## Disable .htaccess and other hidden files
        location ~ /\. {
            deny all;
            access_log off;
            log_not_found off;

        location = /favicon.ico {
            log_not_found off;
            access_log off;

        location = /robots.txt {
            allow all;
            log_not_found off;
            access_log off;

        location /stats {
            index index.html index.php;
            auth_basic "Members Only";
            auth_basic_user_file /var/www/clients/client3/web9/.htpasswd_stats;

        location ~ \.php$ {
            try_files $uri =404;
            include /etc/nginx/fastcgi_params;
            fastcgi_pass unix:/var/lib/php5-fpm/web9.sock;
            fastcgi_index index.php;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_script_name;
            fastcgi_intercept_errors on;

          real_ip_header     CF-Connecting-IP;
        client_max_body_size 28M;
        client_body_buffer_size 128k;

        if (!-e $request_filename) {
                rewrite  ^(.*)$  /index.php?q=$1  last;
        #include /var/www/;      

Here's the php5-fpm pool


listen = /var/lib/php5-fpm/web9.sock
listen.owner = web9 = client3
listen.mode = 0660

user = web9
group = client3

pm = dynamic
pm.max_children = 4
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 2

chdir = /

php_admin_value[open_basedir] = /var/www/clients/client3/web9/web:/var/www/clients/client3/web9/tmp:/var/www/
php_admin_value[session.save_path] = /var/www/clients/client3/web9/tmp
php_admin_value[upload_tmp_dir] = /var/www/clients/client3/web9/tmp

php_admin_value[date.timezone] = "UTC"
php_admin_value[post_max_size] = 28M
php_admin_value[session.gc_maxlifetime] = 604800
php_admin_value[upload_max_filesize] = 28M
php_admin_flag[display_errors] = off
php_admin_flag[display_startup_errors] = off
php_admin_flag[log_errors] = off
php_admin_flag[ignore_repeated_errors] = off
php_admin_flag[ignore_repeated_source] = off
php_admin_value[memory_limit] = 32M

I had to make changes to /etc/php5/conf.d/suhosin.ini as advised by phpmyadmin, and also upped the memory limit for WP as I was getting "ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value".

; configuration for php suhosin module

I reduced the memory limit in wp-config.php as shown below.

define('WP_MEMORY_LIMIT', '32M');
define('WP_MAX_MEMORY_LIMIT', '32M');

Although, I've changed these limits from 256 to 128 to 64 to 32 and it makes NO difference to the front or back end speeds.

Here's my fastcgi_params file, which I'm posting here because I had make a change as advised here to fix the broken concatenated path_info that php is still sending out:

fastcgi_param   QUERY_STRING            $query_string;  
fastcgi_param   REQUEST_METHOD          $request_method;
fastcgi_param   CONTENT_TYPE            $content_type;
fastcgi_param   CONTENT_LENGTH          $content_length;
fastcgi_param CONTENT_LENGTH $content_length;

fastcgi_param REQUEST_URI $request_uri;
fastcgi_param DOCUMENT_ROOT $document_root;
# fastcgi_param DOCUMENT_URI $document_uri;
fastcgi_param SERVER_PROTOCOL $server_protocol;

fastcgi_param GATEWAY_INTERFACE CGI/1.1;
fastcgi_param SERVER_SOFTWARE nginx/$nginx_version;

fastcgi_param REMOTE_ADDR $remote_addr;
fastcgi_param REMOTE_PORT $remote_port;
fastcgi_param SERVER_ADDR $server_addr;
fastcgi_param SERVER_PORT $server_port;
fastcgi_param SERVER_NAME $server_name;

# PHP only, required if PHP was built with --enable-force-cgi-redirect
fastcgi_param REDIRECT_STATUS 200;

fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;

fastcgi_param SCRIPT_URL $script_url;
fastcgi_param SCRIPT_URI $scheme://$http_host$script_url;

# fastcgi_param SCRIPT_FILENAME $document_root$script_filename;

# fastcgi_param PATH_INFO $path_info;
# fastcgi_param PATH_TRANSLATED $document_root$path_info;

#try_files $fastcgi_script_name =404;

I changed the theme to default, turned off all the plugins, changed all the mysql tables to to innodb and followed the recommendations of mysqltuner (even though, as I said, there's nothing about slow mysql in the logs I can see).

I've tried changing php-fpm from socket to port and back, and so on and so forth. Not really sure what else to do now - can anyone spot anything here or advise?

The strangest thing of all? I'm running a personal WP install on a free "tiny" instance on Amazon S3 with a similar config, and it flies along. Which is what makes it even more difficult to diagnose.

And yes, I might be running a bit tight on memory, but then why does Zen Cart and phpbb running with a big db load pages sub 200ms but my wordpress install is 10 small pages? And, to answer another question - yes, the slowness still happens if I turn the other sites off.

share|improve this question

closed as off-topic by HopelessN00b Mar 8 '15 at 21:34

  • This question does not appear to be about server, networking, or related infrastructure administration within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

Have you repaired/optimized the WordPress tables in MySQL? WordPress is quite data heavy, so if its anything, I'm betting it deals with MySQL. Other than that, I'm quite unsure. This is a tough one... – Taylor Jasko Dec 13 '11 at 13:02
up vote 1 down vote accepted

Right - well two days of my life and a helluva lot of learning about things like xdebug, I can answer my own question and safely say you CANNOT now run Wordpress 3.3 - even a brand new fresh install with no plugins - on a VPS with less than 512Mb RAM. Which is a shame, because the 256Mb VPS had always been perfectly good before.

Previously, it had been OK. You remember in my original question, I noted the line about "ALERT - script tried to increase memory_limit to 268435456 bytes which is above the allowed value"?

Well, I also noted that I didn't see any memory spiking in the command line utility "top". But clearly, that doesn't refresh fast enough. With a bit of help from the VPS host who has graphical tools, we were seeing bursts of 228Mb usage when the ADMIN side of WP 3.3 was trying to load. But the front end? Well, as I said before, that zipped along and barely even registered on their graph.

Shortly after this happened, I found this: which confirms my findings, but doesn't quite show the same memory usage.

I've temporarily moved to a 512Mb RAM VPS while I decide what to do, and, of course, WP is fine again. But it's not an affordable long-term solution. So will either have to try and revert, or look at another CMS. Which is a shame, after 5 years of happy Wordpressing.

Final note to pre-empt the inevitable "but you can get 1Gb RAM VPS very cheap these days" comment, yes, you can. And I've been badly burnt that way and that's all I'm saying on that. You get what you pay for - just that paying for 256 is preferable to 512...

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.