No APC + PHP, quanto de RAM é demais? Está tudo bem para definir apc.shm_size para muitos GB?

Question

Em nosso servidor, temos MUITA RAM para nossos níveis de tráfego (16 GB). Os processos HTTP consomem regularmente toda a CPU e precisam ser reiniciados sem sequer chegar perto de usar memória swap, então estou procurando maneiras de gastar RAM para facilitar a carga no Apache (e / ou ajudar o servidor MySQL separado que pode ser quebrando o Apache).

Eu tenho muitas instalações do WordPress na instância HTTPD, então o APC às vezes usa até 900MB de RAM (de acordo com os gráficos apc.php). Apenas no caso eu tenho apc.shm_size definido para 1600MB, que é mais do que o necessário, mas não mais do que eu posso poupar. Isso significa que normalmente há muita RAM extra disponível para a APC, mas também muito pouca rotatividade e a fragmentação nunca é superior a 1%.

Isso é perigoso? Devo estar emagrecendo APC para menos de 1 GB apenas por princípio? Eu deveria estar esperando algum volume de negócios dentro da APC em nome de reduzir sua pegada geral?

Ter muita memória dedicada ao APC significa que, no topo / htop, cada processo httpd mostra ~ 1.9GB na coluna de memória VIRT. Obviamente, isso é memória compartilhada e não é usado por processo, mas poderia estar prejudicando o nosso servidor?

NOTA: O problema com o servidor permanece incerto, mas o efeito é que cerca de 60 vezes por dia todos os 8 CPUs preenchem até 100% e tudo pára de funcionar até que Monit veja que o Apache está quebrado e o reinicia (Monin também salva o MySQL servidor). Não tenho certeza se o APC é parte do problema, mas estou tentando otimizar tudo apenas no caso.

    

Answer 1

Ter tantas alocações é geralmente excessivo. Neste caso, você pode sentir que precisa, por causa de todos os arquivos diferentes. O que pode ser mais útil é reduzir o número de arquivos que precisam ser armazenados em cache, mesclando as instalações do Wordpress. Em qualquer caso, se o APC nunca atingir 1.000 MB usados, ter mais do que isso é redundante.

Quantos MaxClients são definidos em função do tráfego do servidor e, particularmente, do tamanho da parte residente do Apache e de outros programas. Com 16GB de ram, mesmo com metade do alocado para Mysql (o buffer pool do InnoDB - InnoDB controla membro melhor que MyIsam, mesmo ao custo de mais um ram), algumas centenas de processos Apache geralmente são suficientes (eu estava Atendendo a 10 milhões de acessos ao PHP por servidor por dia e a média foi de 40 processos sendo usados por vez.

Tendo as imagens estáticas, css, JS etc servidas pelo NginX, instaladas na frente (ou em uma URL separada), o servidor Apache também reduzirá o trabalho que o servidor PHP com maior capacidade é obrigado a fazer - geralmente muito substancialmente . link tem alguns pensamentos sobre isso, e há outros blogs e tal que o guiarão pela instalação do Nginx na frente do Apache, com ou sem o Wordpress sendo envolvido.

Por fim, o KeepAlives basicamente apenas mata um site ocupado. Desativá-los é recomendado agora, para evitar o tipo de fome de recursos que você está vendo regularmente. Se, por exemplo, você definiu 100 MaxClients e um KeepAlive de 30 segundos, do que apenas 100 visitantes em um período de 30 segundos manteria abertos todos os slots Apache, e você não poderá servir mais nada. KeepAlive Off .

    

Answer 2

Eu não acho que alocar tanta memória seja um problema se estiver disponível e não for necessário em outro lugar. Uma coisa que você pode fazer é usar melhor o APC para usar um cache de objetos do WordPress como W3 Total Cache ou o Plugin do Cache de Objetos da APC de Mark Jaquith .

Para seu problema de CPU, eu verificaria seus MaxClients e MaxRequestsPerChild. Eles podem estar muito altos. Veja também a configuração do KeepAliveTimeout e certifique-se de que não é alto.

    

Answer 3

Eu acho que você pode permitir o máximo de memória que quiser para o APC. A memória usada pelo APC para armazenar em cache o opcode não será usada pelo sistema de arquivos para armazenar em cache os arquivos lidos.

Para reduzir a carga da CPU, você pode configurar a expiração dos recursos (css, js, imagens). Instale o mod_expire no apache e use o .htaccess para definir o cabeçalho de expiração conforme necessário. Se você não fizer isso. Os navegadores verificam se os arquivos foram alterados, mesmo que estejam em cache. Isso gera muitos acessos e drena os ciclos da CPU.

Usar o les instance do wordpress também seria bom.

Mas o melhor aumento seria verificar como o site wordpress é codificado. Plugins exigem muita energia. Em algum momento, os usuários os instalam para coisas estúpidas, como incluir o código do Google Analytics no rodapé, enquanto ele pode ser inserido no arquivo de modelo footer.php.