Apache2 e nginx que consomem aleatoriamente toda a memória, toda semana ou mais

Question

Eu gostaria de começar dizendo que li pelo menos 10 questões relacionadas ao Serverfault antes de recorrer a fazer o meu próprio ...

Atualmente, estou executando um servidor Ubuntu 14.04.3 com 2 GB de RAM e cerca de 5 instalações ativas do WordPress, todas gerenciadas sob o painel de controle do Vesta CP.

Normalmente, usa cerca de 700MB dos 2GB. Mas toda semana mais ou menos, toda a RAM é magicamente consumida, e o servidor fica quase parado.

Se eu fizer SSH nele e reiniciar o Apache, bem como limpar a memória ( echo 3 > /proc/sys/vm/drop_caches ), ele começará a funcionar novamente.

Aqui estão as minhas configurações do módulo prefork, que considero muito razoáveis:

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       1
    MaxSpareServers       5
    ServerLimit          10
    MaxClients           10
    MaxRequestsPerChild  1000
</IfModule>

Eu até habilitei mod_status e tentei ver o que os arquivos PHP estavam demorando, mas não achei nada suspeito. É claro que, quando olho para o log enquanto o servidor está inativo, ele é inundado com pelo menos 200 arquivos PHP porque eles não podem ser executados devido ao consumo massivo de memória.

Eu até habilitei um arquivo SWAP de 8 GB, mas isso parece ter atrasado o inevitável.

Veja o que o comando free -m obtém sempre:

root@apache2-ps7881:/home/dhc-user# free -m
             total       used       free     shared    buffers     cached
Mem:          2001       1943         57         35          1         59
-/+ buffers/cache:       1883        118
Swap:         8191       4083       4108

Depois de reiniciar o apache:

root@apache2-ps7881:/etc/apache2# free -m
             total       used       free     shared    buffers     cached
Mem:          2001        744       1257         65         36        204
-/+ buffers/cache:        503       1498
Swap:         8191        140       8051

Aqui está o /var/log/apache2/error.log :

[Fri Feb 12 08:22:33.063204 2016] [mpm_prefork:error] [pid 2081] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
[Fri Feb 12 13:12:59.819680 2016] [core:warn] [pid 2081] AH00045: child process 6334 still did not exit, sending a SIGTERM

Esse erro "o processo filho ainda não saiu" continua por centenas de outras linhas.

Eu recebo a mensagem server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting toda vez que ela cai.

Outro error.log revela o seguinte:

[Fri Feb 12 08:19:55.781598 2016] [:error] [pid 20686] [client 10.10.10.9:54559] PHP Warning:  mysqli_connect(): (08004/1040): Too many connections in /[censored]/$
[Fri Feb 12 08:19:55.896491 2016] [:error] [pid 20686] [client 10.10.10.9:54559] Too many connections, referer: http://[censored]

Será que há uma conexão que não está sendo fechada? Mas isso causaria um vazamento de memória?

Veja um exemplo do que os gráficos revelam durante as falhas:

    

Answer 1

Eu tive um problema semelhante em que um site do Wordpress começava a usar toneladas de recursos ao ponto de o servidor não responder mais. Investigando os logs, vi algumas centenas de tentativas de acessar xmlrpc.php ao mesmo tempo em que a pegada de memória aumentaria. As funções em xmlrpc.php podem ser abusadas como um multiplicador de força em ataques de força bruta usando o método system.multicall .

Este artigo é uma descrição mais articulada de como funciona: link

Mais importante, aqui estão algumas estratégias de atenuação desse artigo:

Protecting Yourself

I used to recommend people block all access to xmlrpc.php, but it was breaking some plugin’s functionality (mostly JetPack). With that in mind, if you are not using JetPack or any of the other plugin that require it XML-RPC, it might be a good idea to block direct access to it altogether.

If you can’t block XML-RPC, and you are using a WAF (web application firewall), I highly recommend blocking system.multicall requests. It is barely used in the wild and will protect you against these amplification methods.

Eu não uso nenhum plug-in que exija acesso ao xmlrpc.php, então modifiquei o .htaccess para negar acesso. Desde então, nenhum ator mais malicioso conseguiu esmagar o site. Aqui está o código, se você quiser tentar:

Usando o editor de texto de sua escolha, modifique /var/www/html/.htaccess para incluir:

    <Files "xmlrpc.php">
    Order Allow,Deny
    deny from all
    </Files>

O Wordpress tem diretrizes adicionais para proteger o acesso ao seu site encontrado aqui: link

O plugin do Login Security Solution para o Wordpress também pode ajudar. Eu colocaria o link, mas não tenho a reputação. Desculpe!

    

Answer 2

Parece que o site simplesmente fica ocupado, mas você disse que não é o caso. Está ficando sem recursos do servidor, portanto, talvez seja necessário limitar os recursos antes que eles se esgotem.

Eu também verifico os plugins que o Wordpress está usando e os widgets. Remova qualquer coisa que não seja 100% necessária para um teste. Eu vi plugins e widgets fazer coisas horríveis terríveis para sites Wordpress. No mínimo, você deve estar usando um plugin de cache, o W3 Total Cache é o melhor da memória.

Se fosse meu servidor, alteraria a arquitetura subjacente do servidor para usar Nginx e HHVM, incluindo o cache de páginas. Eu tenho quatro instalações Wordpress e um moderadamente ocupado site rodando em um aws t2.micro, que é de 10% de um núcleo Xeon (burstable para um núcleo completo) e 1GB de memória, embora eu também use o Amazon RDS (serviço de banco de dados relacional ). Meus sites carregam MUITO rapidamente. Note que essa mudança não é necessária, você provavelmente pode corrigir sua configuração e ela deve funcionar bem, mas não sei como.

Eu escrevi um tutorial significativo sobre como configurar o Wordpress na AWS com Nginx, HHVM, etc. Você pode leia aqui . Você poderia facilmente configurar tudo ao lado de sua infra-estrutura atual, executar o Nginx em uma porta diferente e até mesmo usar o mesmo webroot e banco de dados - mas criaria um usuário de banco de dados somente leitura enquanto eu estivesse em teste. Uma vez que você está feliz que está funcionando apenas troque as portas e você estará rodando nginx, hhvm, e isso deve ser mais confiável. Se não, pelo menos, você pode obter algum apoio da comunidade, como a configuração que eu sugiro é bastante normal.

Se seus sites tiverem muitos visitantes anônimos, você poderá enviar um grande número de solicitações do cache de páginas do nginx, que praticamente não usa CPU, e não acessa o PHP. Minha pequena instância pode servir 1000 páginas em cache por segundo, às vezes mais, não tenho certeza qual é o gargalo, mas faz isso em 2% da CPU do cache. Ele só pode fazer 11 páginas por segundo se atingir o PHP, uma enorme diferença que mostra quão lento é o código de execução. Isso tornará seu site mais rápido. Ele deve torná-lo mais rápido para todos os visitantes, o HHVM é um pouco mais rápido que o PHP5.

    

Answer 3

A configuração que você nos mostrou é explicitamente contradita pela sua descrição de "pelo menos 200 arquivos PHP" e a saída de top - que claramente contém mais de 10 instâncias. Que limpar o cache do vfs parece remover os sintomas é um pouco alarmante - o único impacto que deve ter é diminuir o servidor.

Todos esses processos estão bloqueados - e eles não estão funcionando para o banco de dados. Parece haver alguma contenção de arquivos feia acontecendo aqui também.

Parece uma combinação de que permite muitas conexões combinado com um bloqueio de arquivo de bloqueio. O último pode ser um ataque DOS, particularmente se você estiver usando o manipulador de sessão padrão. Se este for o caso, deve ser evidente a partir dos seus registros de acesso.

Não há uma solução rápida aqui, mas o próximo passo deve ser consertar a configuração para que ela realmente funcione e desativar todos os plugins do WordPress. Esses plugins variam muito em qualidade.

Realmente, deveríamos votar para encerrar isso como muito amplo.