PHP-FPM using 40% CPU for a Single Request

(I googled and searched this forum for hours, found some topics, but none of them worked for me)

I’m using WordPress with: Varnish + Nginx + PHP-FPM + APC + W3 Total Cache + PageSpeed.

Read More

As I’m using Varnish, first time I call www.mysite.com it use just 10% of CPU. Calling the second time, it will be cached. The problem is passing request parameter in URL.


For just 1 request (www.mysite.com?1=1) it shows in top:

PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM   TIME+  COMMAND
7609 nginx     20   0  438m  41m  28m S 11.6  7.0   0:00.35 php-fpm
7606 nginx     20   0  437m  39m  26m S 10.3  6.7   0:00.31 php-fpm

After the page is fully loaded, these processes above are still active. And after 2 seconds, they are replaced by another 2 php-fpm processes(below), which are active for 3 seconds.

PID USER       PR  NI  VIRT  RES  SHR S %CPU %MEM   TIME+  COMMAND
7665 nginx     20   0  444m  47m  28m S 20.9  7.9   0:00.69 php-fpm
7668 nginx     20   0  444m  46m  28m R 20.9  7.9   0:00.63 php-fpm

40% CPU usage just for 1 request not cached!


Strange things:

  • CPU usage is higher after the page was loaded
  • When I purged the cache (W3 and Varnish), it take just 10% of CPU to load a not cached page
  • This high CPU usage just happend passing request parameter or in WordPress Admin

When I try to do 10 request(pressing F5 key 10x), the server stop serving and in php-fpm log appears:

WARNING: [pool www] server reached max_children setting (10), consider raising it

I raised that value to 20, same problem.

I’m using pm=ondemand (pm.max_children=10 and pm.max_requests=500).

Inittialy I was using pm=dynamic (pm.max_children=10, pm.start_servers=1, pm.min_spare_servers=1, pm.min_spare_servers=2, pm.max_requests=500) and it happened the same problem.

Anyone could help, plz? Any help would be appreciated!

PS:

  • APC is ON (98% Hits, 2% Misses)
  • Server is Amazon Micro (613MB RAM)
  • PHP 5.3.26 (fpm-fcgi)
  • Linux version 3.4.48-45.46.amzn1.x86_64 Red Hat 4.6.3-2 (I think it’s based on CentOS 5)

Related posts

Leave a Reply

3 comments

  1. First reduce the stack of caches. Why using varnish which serves pages from memory when you’re using w3 cache already which serves from memory as well?

    W3cache is CPU intensive! It does not just cache items but also compresses, minifies and merges files on the fly.

    You got a total of 512MB of memory on your machine which is not a lot, also your CPU power is less than a modern smartphone has. Memory access is extremely slow compared to a root server because of the xen virtualization layer – That’s why less is more.

    Make sure w3cache is properly set up so it actually caches items, then warmup your cache and you should be fine.

    Have a look at Googles nginx pagespeed module https://github.com/pagespeed/ngx_pagespeed, it can do the same thing w3cache does, just much more efficient because it happens in the webserver, not in PHP

    Nginx can also directly serve from memcached http://www.kingletas.com/2012/08/full-page-cache-with-nginx-and-memcache.html (example article, might need some more investigation)

  2. Problem solved!

    For those who are having the same problem:

    1. Check Varnish configuration;

    2. Check your WordPress’s plugin;

    1) In my case, TTL was not configured in Varnish, so nothing was being cached.
    This config worked for me:

    sub vcl_fetch {
        if (!(req.url ~ "wp-(login|admin)")) {
                unset beresp.http.set-cookie;
                set beresp.ttl = 48h;
        }
    }
    

    2) The high CPU usage AFTER page loads, was caused by a WordPress plugin called: “Scroll Triggered Box”.

    It was doing some AJAX after page has loaded. I disabled that plugin and high load stopped.

  3. There are two factors at play here:

    1. You are using micro instance which has a burstable CPU profile. It can burst up to 2 ECU’s then be limited to much less than 1 (Some estimates put this at around 0.1 – 0.2 ECU’s)

    2. While logged in as an admin, wordpress caching plugins often bypass or reduce caching. W3 should allow you to switch this if you want caching on all the time.