Estamos tendo problemas com nosso servidor rackspace wordpress caindo com tráfego médio após o envio de um e-mail.
As especificações do servidor são:
CPU 2 vCPUs
RAM 2 GB
System Disk 80 GB
Network 240 Mb / s
Disk I/O Good
Correndo:
Centos 7.0
Wordpress 4.3.1
Httpd 2.4.6
PHP 5.4.11
MariaDB 5.5.41
A instalação é bastante padronizada, pelo que posso dizer, e o banco de dados é bastante padronizado, indexado e bastante pequeno. Também estamos armazenando objetos em cache no wordpress.
De acordo com a Nova Relíquia; durante o tráfego normal, o site passa cerca de 80% do tempo em PHP, 15% do tempo em web externa e apenas uma pequena porcentagem no banco de dados. O tempo médio do aplicativo de página padrão é de cerca de 800 ms, o que parece lento para mim.
A execução de um teste de carga de 250 conexões em 1 minuto faz com que as conexões demorem progressivamente mais e comecem a atingir o tempo limite após cerca de 30, e o servidor pare de responder (mesmo quando o tráfego diminuir). Requer uma reinicialização forçada para ficar ativo novamente.
Não consigo me conectar usando o putty e a página inicial oscila entre o tempo limite e o retorno do temido 'Erro ao estabelecer conexão com o banco de dados'.
Usando o agente de monitoramento rackspace no teste mais recente, parece que a CPU está no máximo de 100% pouco antes da morte, a memória usada atinge o pico de cerca de 1,6 GB, com queda livre para cerca de 100 MB. Parece que cerca de 2 GB de memória swap (total de 4 GB) também estão sendo usados. O uso padrão parece ser de cerca de 15% de CPU, 800 MB de memória e 400 MB de swap.
Nossa configuração do Apache não define nenhum dos seguintes itens (nenhum arquivo em /etcdo); Tempo limite, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout; então acho que está usando os valores padrão.
Eu olhei as configurações do mariadb:
innodb_buffer_pool_size = 1400M
max_user_connections = 0
O que não parece ser a causa.
Também ativei o performance_schema, mas realmente não sei o que estou procurando. Nem tenho certeza se o banco de dados é o problema.
Estou tentado a atualizar a instância, mas prefiro ter uma visão mais clara de onde está o gargalo e o que está causando a morte do servidor, em vez de apenas ficar lento.
Alguma ideia de por onde começar? Parece haver muitos ajustes possíveis e muitas informações.
Responder1
O monitoramento próximo durante qualquer tipo de evento é crucial. Como vemos, a verdade veio à tona:
Usando o agente de monitoramento rackspace no teste mais recente, parece que a CPU está no máximo de 100% pouco antes da morte, a memória usada atinge o pico de cerca de 1,6 GB, com queda livre para cerca de 100 MB. Parece que cerca de 2 GB de memória swap (total de 4 GB) também estão sendo usados. O uso padrão parece ser de cerca de 15% de CPU, 800 MB de memória e 400 MB de swap.
O PHP é conhecido por consumir bastante CPU. Você usou toda a CPU disponível e quase toda a RAM disponível.
Você deve primeiro tomar medidas para lidar com isso, como cache de opcode (por exemplo, Zend OPcache) e cache de arquivos (por exemplo, plugin W3 Total Cache WordPress). Se isso não ajudarsuficiente, então é hora de atualizar a instância.
Responder2
Você provavelmente está executando muitos processos ao mesmo tempo, ficando sem memória e alterando a troca. Pode ser que alguma outra coisa esteja travando, mas lide com isso primeiro e depois veja onde você está.
Você não nos disse se está usando mod_php ou algo como php-fpm. O último lida melhor com a carga, mas em ambos os casos, certifique-se de não executar mais processos php do que você tem memória. Você provavelmente não obterá nenhum benefício de desempenho executando mais de 5 ou 10 processos, mas a execução padrão do mod_php em particular executará muito mais do que você tem memória. Além disso, recicle processos a cada 30 solicitações. Se você fornecer 1 GB para seu banco de dados e sistema operacional, seus outros GB provavelmente não suportarão 10 processos do WordPress. Olha quanta memória eles pegam e resolvem, com um pouco de folga. Você não deveria usar nenhuma troca no curso normal das coisas.
Veja suas configurações de keep-alive. Com o Apache, provavelmente é melhor desligá-lo ou configurá-lo para 1 segundo. O Nginx lida com o keep-alive muito melhor. Na verdade, esta é a única razão realmente importante pela qual o nginx provavelmente terá um desempenho melhor com um aplicativo php como o WordPress (embora isso tenha o custo de uma configuração menos agradável). Muito provavelmente, isso não é um fator importante nos seus testes, mas é importante em navegadores reais.
100% CPU me surpreende. Use top para ver o que está usando. Lembre-se também de que 100% geralmente significa 100% de um núcleo. Você pode estar vendo apenas um cron job sendo iniciado, o que no WordPress normalmente não é "cron" como tal, mas sim os jobs são executados como um extra durante o processamento de solicitações da web. A falta de cache do opcode também pode estar causando alto uso da CPU.