WP admin, even 3.3, incredibly slow.

  • Ubuntu 11.10
    Nginx 1.0.10
    php5-fpm 5.3.8

    I’ve got a 256Mb VPS running a Zen Cart store and phpbb3, 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 ps_mem.py

    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;

        server_name mysite.co.uk www.mysite.co.uk www.my-site.co.uk my-site.co.uk;

        root   /var/www/mysite.co.uk/web;

        index index.html index.htm index.php index.cgi index.pl 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/mysite.co.uk/error.log;
        access_log /var/log/ispconfig/httpd/mysite.co.uk/access.log 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;
        }

         set_real_ip_from   204.93.240.0/24;
          set_real_ip_from   204.93.177.0/24;
          set_real_ip_from   199.27.128.0/21;
          set_real_ip_from   173.245.48.0/20;
          set_real_ip_from   103.22.200.0/22;
          set_real_ip_from   141.101.64.0/18;
          set_real_ip_from   108.162.192.0/18;
          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;
                break;
            }
        #include /var/www/mysite.co.uk/web/nginx.conf;
}

    Here’s the php5-fpm pool 

    [web9]

listen = /var/lib/php5-fpm/web9.sock
listen.owner = web9
listen.group = 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/mysite.co.uk/web:/srv/www/mysite.co.uk/web:/usr/share/php5:/tmp:/usr/share/phpmyadmin:/etc/phpmyadmin:/var/lib/phpmyadmin
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
extension=suhosin.so
suhosin.executor.include.whitelist="phar"
suhosin.request.max_vars=2048
suhosin.post.max_vars=2048
suhosin.request.max_array_index_length=256
suhosin.post.max_array_index_length=256
suhosin.request.max_totalname_length=8192
suhosin.post.max_totalname_length=8192
suhosin.get.max_value_length=1024
suhosin.memory_limit=128M

    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.

    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?

Viewing 15 replies - 31 through 45 (of 64 total)

  • After I upgrade to 3.3.1, it quite smooth like usual. But the other day, all my websites become slow. Is hard to post something in the backend too. Even my cpanel loading slow also. Any solution yet?

    We host hundreds of blogs on a single WordPress installation. We noticed that the admin got progressively slower as we added more sites. What we discovered was that for the super admin, all user_meta records were being loaded into memory on every page click. Each site could potentially create 4+ user_meta records. 250 sites X 4 records = 1000 records being loaded into memory on every page click. WordPress needs to have a blogID column added to this table so it only loads user_meta records relevant to the current blog.

    I have the same slowdown problem on a server with 13 sites and 512MB RAM. The straight HTML sites are as good and fast as always, but the WP sites all slow. WP 3.3.1 loaded on all WP sites, and I think I noticed the sites slower after 3.3. Control panel also slow

    Unfortunately, I only found this thread after upgrading server package ??

    I ran into the exact same issue. Content pages intermittently loading slowly, some admin pages loading slowly or in the case of the plugins page, not all all.

    The root cause ended up being that a firewall was preventing the server from communicating over port 80. Users could reach the site fine over port 80, but any attempt by PHP code to load anything via port 80 directly was being blocked. Once this was resolved, all issues disappeared.

    Now, this is just my observation and there is more to this, such as what WordPress is attempting to load from a remote source, but this did fix things immediately.

    @potatomaster Thanks for sharing your fix. It, kind of, solved a similar issue I had in my client’s site. In my case, the web host was not blocking the port 80 requests, but the requests were only delayed (to avoid any spam? only that webhost knows).

    For this…

    Now, this is just my observation and there is more to this, such as what WordPress is attempting to load from a remote source, but this did fix things immediately.

    From what I know, on WP dashboard, WP loads widgets that fetch latest WP news, latest plugin information, etc. I wish I know more to explain any other requests that WP sends out.

    I am getting SUPER SLOW page load and connection error while in admin panel of wordpress 3.3.1. If it does load a page it takes a very long time but most times it times out. To check, I then go directly to root via ftp and it won’t allow it to connect. Once it does connect via FTP, then http page I was trying to load in admin will load but any adjustments made are very slow or again times out. If I don’t access admin on wordpress, server has no issues. Any help would be greatly appreciated.

    I’ve got the same problem as everyone else.
    orbsid – that’s interesting. You’re saying that in order to get the page to load, you have to connect via another method first?

    My server had plenty of free RAM, low load, front end loads very fast. Admin takes 10+ seconds per page, sometimes I cannot edit pages at all.

    digitaltoast, once you go into WP admin, it seems to start a php script that disconnects the server. I used FTP to verify that I was unable to connect to server after login in WP admin.

    I would keep attempting FTP connections until it connected back to the root directory. Then when I went back to the WP admin page, it would load Sloooooooowly but click to two later, it disconnected again.

    I would go back to FTP to see if I could access root directly and I couldn’t! Verifying that it was something to do with the ADMIN PANEL in wp that created the server to literally disconnect.

    If i stay out of wordpress admin, or view other content on server, all worked fine.

    Thread Starter talkingnews

    (@talkingnews)

    OMG! No, in fact OMFG!!1!!! I’ve cracked it! For me, at least.

    The short story

    – in my case, running php-fpm on ubuntu:

    nano /etc/php5/conf.d/apc.ini

    You should see:

    extension=apc.so

    paste in the below lines:

    apc.shm_size="196"
apc.ttl=0
apc.max_file_size="10M"

    save and close.

    Do service php5-fpm restart.

    Now go to your WordPress admin and watch that sucker fly with near instant response.

    The long story
    I was so damn sick of this slow admin I just decided to keep going, trying stuff.

    Finally, I came across this post:
    https://stackoverflow.com/questions/3723316/warning-require-once-function-require-once-unable-to-allocate-memory-for-p
    then this
    https://groups.drupal.org/node/75583
    which led me to this post:
    https://www.litespeedtech.com/support/forum/showthread.php?t=4366
    and finally this:
    https://2bits.com/articles/high-php-execution-times-drupal-and-tuning-apc-includeonce-performance.html

    The key to this was “download https://pecl.php.net/get/APC extract and run the apc.php, there you have a nice diagram how your cache usage look like“

    It showed APC was completely using its tiny default 32Mb, and was 100% fragmented. I’ve been running it for an hour, and see Hits: 70874 (98.6%) Misses: 991 (1.4%) Used: 124.4 MBytes (63.5%) Fragmentation: 0.00%

    Before this tweak it was something like 70% misses and 100% fragmentation. No wonder WordPress was running slow!

    @talkingnews – Great solution!!! Wow… Nice follow up post! Thanks muchly!! ??

    I should note that after a time, I had over 25 installations of WP 3.3.0, experiencing this slow issue.

    After upgrading to WP 3.3.1, the issue went away. (I’m assuming some issue was addressed in the x.1 update? – Although I’ve not followed up on any of that).

    @talkingnews’s solution worked for me as well.
    It’s incredible, the admin is so fast now its like I’m running it on localhost now.
    I’m seeing a little fragmentation of about 1% but I run many sites on that host.
    I’ve given it 196Mb but when I run top and ps_mem.py it doesn’t seem to show any more memory used. Does it take it from the overall php allocation?
    Anyway, problem solved. I think I need to understand APC a but more.

    My sites are with a host (ipage). How do I apply this?

    “nano /etc/php5/conf.d/apc.ini

    You should see:

    extension=apc.so

    paste in the below lines:
    apc.shm_size=”196″
    apc.ttl=0
    apc.max_file_size=”10M”

    ”

    I believe I solved the issue for my blog: https://www.premium23.com

    Solution
    “#2 Changing the Memory Limit via wp-config.php

    If you don’t want to mess with the PHP.ini file, then you can go for this method. In this you won’t be needing to create any extra file in your Directory. Just Adding define(‘WP_MEMORY_LIMIT’, ’64M’); in your ‘wp-config.php’ file would increase your PHP Memory Limit to 64 MB.”

    Note: I changed mine to 128 MB

    Source
    https://www.dailyblogging.org/wordpress/increase-wordpress-memory-limit/

    Wow – I am glad I discovered this thread. I too have been hit with major admin area slowdowns that I cannot identify and are unfortunately inconsistent. I have two similar multisites on the same server on different domains. On the test multisite (same server), 3.3.1 is very speedy on all sites. On the main site, the admin for the network and root blog is horrifically slow, even with all plugins turned off for the root blog/site.

    1 – Log slow queries is not identifying any admin related slowdown, despite huge slowdowns for the page load.
    2 – On the root blog/site and network, just trying to view the first page of “all users” with nothing but name appearing takes about 40 seconds. Clicking on plugins is the same, deleting or deactivating one can take a 1-3 minutes. The rest of the admin section flies.
    3 – The front end is experiencing a significant slowdown on the root blog. The others are lightning fast – despite having the same plugins and far more activated. I don’t know if it means anything, but I do have an SSL certificate for the main site’s domain but not for the test site.

    Here is where it gets interesting:

    Using webpagetest I get a MAJOR slowdown from wait time (time to first byte) on the root site. When I use another site from the multisite (and despite more plugins) the TTFB and wait period is at least 40% lower if not more in each instance.

    I’ve noticed that when I use showprocesslist (not showing the query for some reason) I do see about 10 “Sleep” entries sitting there. When I click on the “All Users” in the admin, I see two queries running at the same time although I don’t know what they are. If I wait for all of them to terminate, the site starts to be more responsive (everything but hitting the users area of the admin.) This explains why turning off plugins didn’t make a difference – it was a matter of waiting until these unidentified queries terminated.

    Since I’m on a hosted server, I did:

    define(‘WP_MEMORY_LIMIT’, ’64M’); in your ‘wp-config.php’ file would increase your PHP Memory Limit to 64 MB.”

    But changed it to 1024 MB for my main blog.

    Took my site from an 10-second load time, to ~2.5s.

    Also tried 4096 MB, but the site stopped working ??

Viewing 15 replies - 31 through 45 (of 64 total)
  • The topic ‘WP admin, even 3.3, incredibly slow.’ is closed to new replies.