Apache recentemente usando maior CPU enquanto ocioso

1

Eu tenho rodado um servidor Ubuntu 14.04 com a pilha LAMP padrão já há algum tempo e faço o sistema reportar o uso médio da CPU por hora para mim via e-mails diários. Por muito tempo, isso foi reportando o tempo ocioso da CPU na maior parte dos anos 90 (é um servidor levemente carregado).

Cerca de um mês atrás, isso mudou e o servidor agora está relatando tempo ocioso nos 80s mais altos do que nos 90s mais altos. top revela que o apache é o consumidor da maioria das CPUs:

top - 00:20:43 up 39 days, 22:34,  1 user,  load average: 0.34, 0.41, 0.39
Tasks: 165 total,   2 running, 163 sleeping,   0 stopped,   0 zombie
%Cpu(s): 10.0 us,  0.7 sy,  0.0 ni, 89.2 id,  0.1 wa,  0.0 hi,  0.1 si,  0.0 st
KiB Mem:   6110180 total,  5500892 used,   609288 free,   232448 buffers
KiB Swap:        0 total,        0 used,        0 free.  3502368 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
16235 www-data  20   0  503848  77680  41564 S   8.3  1.3   0:04.28 apache2
16124 www-data  20   0  506624  86688  47888 S   8.0  1.4   0:06.23 apache2
16351 www-data  20   0  506456  79224  41364 S   7.3  1.3   0:01.54 apache2
16301 www-data  20   0  506356  78908  41156 S   7.0  1.3   0:02.93 apache2
16102 www-data  20   0  507116  87292  48272 S   6.6  1.4   0:06.88 apache2
 1343 mysql     20   0 2670112 540216   8308 S   2.7  8.8 988:08.92 mysqld
16354 www-data  20   0  503248  76144  40636 S   1.3  1.2   0:01.29 apache2
16100 www-data  20   0  507016  80436  41524 S   1.0  1.3   0:07.12 apache2

Eu coçei minha cabeça por um tempo sobre isso para determinar que mudança eu poderia ter feito para causar isso. O tráfego da Web não aumentou durante esse período de tempo (na verdade, foi menor que o normal), e posso sentar assistindo apachetop mostrando nada de mais acontecendo enquanto a saída top acima continua.

Eu tentei aplicar todos os patches mais recentes esta noite, na esperança de que talvez algum problema temporário tenha sido introduzido em uma atualização recente e que já tenha sido resolvido, mas sem sucesso.

Ocorreu-me então que era talvez por volta do mesmo período de tempo que instalei o mod_security no servidor. Eu tenho executado isso no modo de observação desde então. Desativei esta noite e reiniciei o apache, mas a carga parece não ser afetada pela alteração.

Alguém pode sugerir como posso diagnosticar o que o apache está ocupado fazendo? Atualmente, isso não é uma grande preocupação, mas eu gostaria de entendê-lo antes que ele se torne um!

    
por John Rix 22.02.2017 / 01:41

1 resposta

0

Acontece que foi um peru chilando xmlrpc.php várias vezes por segundo em um site WordPress que eu não estava monitorando com o apachetop. Bloquear o endereço IP ofensivo resolveu bem o problema!

Caso alguém venha procurar aqui novamente, usei mod_status para me ajudar a chegar ao fundo disso. Especificamente, com o mod_status instalado e ativado, ativei o caminho / server-status em um dos meus hosts virtuais da seguinte maneira (substituindo <my-current-ip> pelo endereço IP atual do meu PC cliente):

<VirtualHost *:443>
    ServerName myhost.com
    ...
    <Location /server-status>
            SetHandler server-status
            Require ip <my-current-ip>
    </Location>
    ...
</VirtualHost>
Em seguida,

visitou https://myhost.com/server-status para obter uma visão completa do tráfego da web no sistema. Isso rapidamente revelou a maior parte do tráfego vindo do script xmlrpc.php no host virtual em questão.

De lá, acompanhei os registros de acesso desse host virtual e pude ver o padrão de atividade e o endereço IP de origem. Foi então uma questão de bloquear o endereço IP usando o ufw da seguinte forma:

sudo ufw insert 1 deny from <the-bad-ip>

Nota: o uso de 'insert 1' nesse comando garante que ele seja aplicado antes de qualquer regra de 'default allow' na configuração do firewall, como as portas 80 e 443, que tornam o filtro tão inútil quanto um bule de chocolate!

    
por 22.02.2017 / 02:34