Como posso impedir que o Apache caia?

Eu tenho um par de servidores que hospedam um único site de comércio eletrônico Magento com tráfego moderado (60 mil visualizações de página por dia relatadas no google analytics, penso em 80 mil relatadas no próprio servidor). O servidor de banco de dados funciona sem problemas e com rapidez, além de um raro soluço ocasional, mas o servidor apache vem caindo de vez em quando.

Eu configurei o magento para usar o cache recomendado do PHP (APC), além de manter seus próprios arquivos de cache em 1,5 gig tmpfs (esse tmpfs fica bastante cheio regularmente, e eu tenho um script em execução para limpar os arquivos em cache quando o tmpfs é mais de 80%). Eu sirvo a maioria das imagens da Amazon Cloudfront. Recentemente, configurei o nginx como um proxy reverso para o apache (o nginx também serve os arquivos estáticos). Eu configurei o apache da melhor maneira possível - os keepalives e hostnamelookups estão desativados e o prefork é configurado da seguinte maneira:

<IfModule prefork.c>
    StartServers      50
    MinSpareServers   50
    MaxSpareServers  100
    ServerLimit  512
    MaxClients   256
    MaxRequestsPerChild 400
</IfModule>

Não desliguei os arquivos .htaccess e o log de acesso está ativado. Eu sei que existem alguns módulos que posso desligar. Não sei ao certo qual efeito teria essas três alterações, se houver.

O servidor apache é um VPS com 6 GB de RAM. No momento da redação, o servidor está relatando load average: 17.77, 18.27, 49.76, mas há cerca de 2 GB de RAM livre. Quando fica muito ruim, a carga vai para mais de 120 e fica lá - reiniciar o apache traz o site de volta e a carga de volta.

vmstaté (enquanto o servidor está relatando a carga acima), eu acho, mostrando um valor ocioso da CPU flutuando entre 0 e 70 ou mais. iostatestá mostrando um valor de iowait entre 0 e 0,2%.

Estou um pouco preso. O pouco que sei está me dizendo que o problema é que a CPU está sobrecarregada como resultado da combinação do código que está sendo executado e do número de usuários. Mas não tenho experiência suficiente para ter certeza de que esse é o problema. Se esse for o problema, acho que as soluções são melhorar o código ou dividir o site que hospeda em dois VPS com um balanceador de carga.

Então, acho que minhas perguntas são:

1. O que mais posso fazer para encontrar problemas ou gargalos no servidor?
2. Existem alterações óbvias que posso fazer na configuração do servidor para melhorar isso?
3. É uma boa ideia definir um sistema automatizado para reiniciar o apache quando a carga estiver acima de um determinado nível?
4. Pelo exposto, qual a probabilidade de o site ter superado o servidor?

Editar:

Achei algo estranho - / var / spool / mail / root era grande ... 38 gig. Isso parece ... doentio. Esse poderia ser o problema?

O Magento e o Zend Framework são bastante pesados ​​para a CPU, como você notou. A melhor maneira de evitar a carga da CPU é simplesmente renderizar qualquer conteúdo apenas uma vez, até que ele mude. A maioria das partes do seu catálogo não muda com tanta frequência, e geralmente apenas o bloco do carrinho de compras na sua página ou o bloco "itens mais populares" são as únicas partes dinâmicas.

Eu sugeriria colocar um cache de verniz na frente do Apache. Isso fornece cache de página de alto desempenho que pode descarregar seriamente sua pilha LAMP. Recentemente, sobrevivemos a um lançamento muito público de um site graças ao Varnish e fiquei seriamente impressionado com a velocidade e a baixa carga de CPU. O verniz é gratuito e flexível o suficiente para armazenar em cache páginas inteiras ou armazenar apenas partes relativamente estáticas e incluir o carrinho dinamicamente.

No entanto, o Varnish não armazenará muito em cache em uma instalação padrão do Magento, pois há muito conteúdo dinâmico por usuário, cookies, etc. Um módulo Magento como o ' PageCache powered by Varnish ' modifica o Magento para funcionar bem com o Varnish. Ele também fornece um arquivo de configuração do Varnish que corresponde à configuração do Magento. Esses dois juntos fazem uma configuração muito eficiente. É um módulo comercial, mas muito mais acessível do que um servidor mais poderoso.

As partes que você transfere para uma CDN ou Nginx não são seu problema real, embora isso ajude. Até o Apache pode lidar com várias solicitações estáticas. Você precisa armazenar em cache o material necessário para gerar repetidamente, ou seja, suas partes dinâmicas.

Normalmente, eu configuro o MaxRequestsPerChild para milhares - geralmente, mais perto de 10.000.

Você diz que possui "o cache recomendado do PHP" - mas você tem a APC instalada? Por fim, quantos usuários você acessa o site ao mesmo tempo. Se você tiver estatísticas estendidas do Apache, poderá ver quantos processos do Apache estão realmente no estado Executando por vez.

800 ocorrências de arquivos APC por segundo e outras 200 cache de usuário são muitas. Se isso é um dual ou quad-core, eu esperaria que ele continuasse bem. Se o banco de dados estiver realmente acompanhando, obter uma máquina maior - e mais CPUs - pode ser a melhor coisa, pelo menos agora.

Sua carga média é muito alta para um VPS de núcleo duplo. 8 deve ser o máximo.

Eu tive um bom sucesso com o uso de mod_pagespeed e do evento MPM para Magento. Eu recomendaria mudar para usar o evento MPM e instalar mod_pagespeed.

Mais informações sobre o Event MPM: Apache event MPM documentation

E mod_pagespeed: Código do Google: mod_pagespeed

Se você continuar com problemas de carregamento, mesmo depois de fazer as alterações acima, considere mudar para um plano VPS diferente e melhor.

Como Alister sugere, um valor MaxRequestsPerChild de 400 é absurdamente baixo.

A média de carga é muito alta, mas 60 mil visualizações de página por dia não são muito tráfego.

quantos processos você normalmente tem atendendo solicitações?

Eu não estou familiarizado com o Magento, mas parece que há algo errado com essa configuração. Eu esperaria que você pudesse obter um rendimento significativamente maior em um nível de carga mais baixo.

Vá buscar uma cópia do livro de Steve Souders e leia-a. Ative a compactação para todo o conteúdo HTML de saída (estático e dinâmico). E verifique se você tem uma boa configuração de cache. Comece a registrar% D no seu arquivo access_log e crie algumas ferramentas para analisar os dados / isolar a lentidão. Semelhante para o MySQL.

Experimente o mysqltuner.pl e veja se há algum problema.

Eu corro uma configuração semelhante, mas com nginx / php-fpm / apc (opcode e fast_backend / memcached (slow_backend). Acho que php é o maior problema de recurso, provavelmente porque o magento é incrivelmente grande ou está mal codificado. olha o que exatamente está comendo os recursos, poderia ser php como no meu caso?

Além do que Martijn Heemels escreve, há um módulo de verniz de código aberto que você pode experimentar. Confira http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/ e https://github.com/madalinoprea/magneto-varnish .
Eu só testei em um ambiente de teste e até agora tudo bem.

Você salva sessões no banco de dados ou no disco (e, se houver, no tmpfs)?

Quando você usa o VPS, está compartilhando a CPU. Eu recomendaria que você conversasse com seu host para mover seu VPS para um hardware menos ocupado ou se dedicar.

Devido à CPU compartilhada, seus aplicativos não são capazes de executar no prazo e ficar na fila, criando solicitações mais altas para serem processadas e também as despesas gerais que acompanham a mesma. Eventualmente, existe uma condição em que o Apache ou php ou mysql teriam atingido seus próprios limites e isso causa problemas.

Resumindo. VPS é basicamente CPU compartilhada. Seu host pode estar colocando muitas contas VPS na mesma CPU.

Se você quiser fazer pleno uso da CPU alocada, peça um servidor melhor com menos VPS, se possível (mova o host, embora isso seja problemático) ou continue dedicado.

Você também pode escolher a Amazon completamente e não se preocupar com o nginx usando seu balanceador de carga, que é apenas alguns cliques para configurar todos os seus servidores na nuvem.

a pasta /var/mail.../root is hue significa coletar muitos e-mails provenientes de seus aplicativos normalmente. Por exemplo, um script php de buggy está tentando enviar um email ou todos os trabalhos do cron são configurados para enviar por email o status das execuções do cron e a saída. Você pode olhar dentro do correio e ver o que o arquivo possui. Estou adivinhando suas mensagens de erro para que você possa descobrir de onde vem.

Vou acrescentar mais se precisar de mais informações e pode ser que eu também precise de algumas informações