PHP-FPM usando 40% de CPU para um único pedido

Question

(Eu pesquisei e procurei neste fórum por horas, encontrei alguns tópicos, mas nenhum deles funcionou para mim)

Estou usando o Wordpress com: Varnish + Nginx + PHP-FPM + APC + W3 total de cache + PageSpeed .

Como estou usando o Varnish, pela primeira vez eu chamo www.mysite.com e uso apenas 10% da CPU. Chamando pela segunda vez, ele será armazenado em cache. O problema é passar o parâmetro de solicitação na URL.

Por apenas 1 solicitação ( www.mysite.com?1=1 ), ela é mostrada em 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

Depois que a página estiver totalmente carregada, esses processos acima ainda estarão ativos. E após 2 segundos, eles são substituídos por outros processos de 2 php-fpm (abaixo), que ficam ativos por 3 segundos.

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% de CPU de uso apenas para 1 solicitação não armazenada em cache!

Coisas estranhas:

• O uso da CPU é maior depois que a página foi carregada
• Quando eu depurei o cache (W3 e Varnish), são necessários apenas 10% da CPU para carregar uma página não armazenada em cache
• Esse alto uso da CPU acabou de passar o parâmetro de solicitação ou no Wordpress Admin

Quando tento fazer 10 pedidos (pressionando a tecla F5 10x), o servidor para de servir e no log do php-fpm aparece:

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

Eu aumentei esse valor para 20, mesmo problema.

Estou usando pm=ondemand ( pm.max_children=10 e pm.max_requests=500 ).

Inicialmente eu estava usando pm=dynamic ( pm.max_children=10 , pm.start_servers=1 , pm.min_spare_servers=1 , pm.min_spare_servers=2 , pm.max_requests=500 ) e aconteceu o mesmo problema.

Alguém poderia ajudar, plz? Qualquer ajuda seria apreciada!

PS:

• APC está ON (98% de acertos, 2% de erros)
• O servidor é Amazon Micro (613MB de RAM)
• PHP 5.3.26 (fpm-fcgi)
• Versão do Linux 3.4.48-45.46.amzn1.x86_64 Red Hat 4.6.3-2 (acho que é baseado no CentOS 5)

Answer 1

É difícil depurar de onde o problema está vindo.

Eu diria que reduza a sua configuração.

Você está usando: Varnish + Nginx + PHP-FPM + APC + W3 Cache total + Velocidade da página

Por que você precisa de verniz? O nginx também pode fazer cache para páginas estáticas. Dê uma olhada em fastcgi_cache

O PHP-FPM e o APC devem estar bem, considere apenas a memória APC suficiente para que todos os arquivos possam ser armazenados em cache sem problemas de memória e fragmentação.

Por que você precisa do W3 Total Cache? Dependendo das opções de configuração, isso pode sobrecarregar muita CPU, por exemplo. para diminuir o código ou armazenar em cache páginas ou chamadas de banco de dados para o disco ...

O mesmo com mod_pagespeed - É um wrapper que processa seus arquivos de saída e também adiciona complexidade que usa ciclos de CPU.

Então - Se você quer um site mais rápido, eu diria que você deve desordenar essa bagunça e simplificá-la:

• Livre-se do verniz: se você não tiver um strong caso de uso para ele. O nginx pode fazer cache muito bem e configurar o nginx para usar fastcgi_cache e usar um soquete para falar com o PHP-FPM.

• Livre-se do W3TC: Use memcached e o plug-in de cache do objeto memcache . Este é o seu DB-Cache e Object-Cache. Para o cache de páginas completas, basta usar o nginx ou o Varnish, se necessário. Você pode se livrar da configuração de cache de página inteira para nginx ou Varnish se usar batcache para armazenar páginas inteiras no memcached. Além disso, tente usar soquetes para o memcached.

• Livre-se de mod_pagespeed . Leia a otimização que faz para você e tente aplicá-las no tema ou nas imagens do seu blog manualmente. Se você estiver usando o gzip no nginx, a maioria das coisas não deve ser importante de qualquer maneira.

• Ative o cache de consulta do MySQL e procure por configurações otimizadas de desempenho do MySQL. Se você tem muitas escritas (por exemplo, muitos comentários), considere o uso do InnoDB.

• Use o PHP 5.4 ou mesmo o PHP 5.5 - Lotes de melhorias de desempenho e memória foram introduzidos nesses lançamentos, o que deve proporcionar algumas economias de velocidade e de memória.

Abordagens mais avançadas:

Dê uma olhada no profiler xdebug . Isso deve lhe dar um resumo de qual função consome muita CPU. A página fornece alguns detalhes sobre como analisar os dados gerados usando o kcachegrind .

Você poderia tentar observar a quantidade de syscalls usando strace na árvore de processos. Você precisará -f flag para isso e provavelmente apenas imprimir estatísticas -c deve ser suficiente para aprender sobre um possível problema.

Eu diria que aplique o princípio KISS e faça uso apenas de desempenho ou coisas de ajuste se você tiver um caso de uso claro para ele e as ferramentas mostrarem uma melhoria usando o perfil.