Como posso evitar que o Apache caia?

Question

Eu tenho um par de servidores hospedando um único site de comércio eletrônico Magento com tráfego moderado (60 mil visualizações de página por dia informadas pelo Google Analytics, eu acho que 80 mil reportaram no próprio servidor). O servidor de banco de dados funciona sem problemas e rapidamente, além de um soluço ocasional raro, mas o servidor apache tem caído de vez em quando.

Eu configurei o magento para usar o cache PHP recomendado (APC), bem como manter seus próprios arquivos de cache em um tmpfs de 1.5 gig (este tmpfs fica bastante cheio e eu tenho um script rodando para limpar arquivos de cache quando o tmpfs está mais de 80% cheio). Eu sirvo a maioria das imagens da cloudfront da Amazon. Eu recentemente configurei o nginx como um proxy reverso para o apache (o nginx também serve os arquivos estáticos). Configurei o apache da melhor forma possível - keepalives e hostnamelookups estão desativados e o prefork está configurado da seguinte maneira:

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

Eu não desliguei os arquivos .htaccess e o log de acesso está ativado. Eu sei que existem alguns módulos que eu posso desligar. Não tenho certeza do efeito que qualquer uma dessas três mudanças teria, se houver.

O servidor apache é um VPS com 6 GB de RAM. No momento em que escrevo, o servidor está reportando load average: 17.77, 18.27, 49.76 , mas há cerca de 2 gigabytes de RAM livres. Quando fica muito ruim, a carga vai para mais de 120 e fica lá - reiniciar o apache traz de volta o site e a carga de volta.

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

Estou um pouco preso. O pouco que eu sei está me dizendo que o problema é que a CPU está sobrecarregada como resultado da combinação do código 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 dois VPSs com um balanceador de carga.

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

1. O que mais posso fazer para encontrar problemas ou afunilamentos no servidor?
2. Há alguma mudança óbvia que eu possa fazer na configuração do servidor para melhorar isso?
3. É uma boa ideia definir um sistema automatizado para reiniciar o apache quando a carga ultrapassar um determinado nível?
4. Pelo exposto, qual é a probabilidade de o site ter superado o servidor?

Editar:

Eu encontrei algo estranho - / var / spool / mail / root era grande ... 38 gig. Isso soa ... insalubre. Poderia ser esse o problema?

    

Answer 1

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

Sugiro colocar um cache Varnish na frente do Apache. Isso oferece um 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 Verniz e fiquei seriamente impressionado com a velocidade e baixa carga da CPU. O verniz é gratuito e flexível o suficiente para armazenar em cache páginas inteiras ou armazenar em cache somente as partes relativamente estáticas e incluir o carrinho dinamicamente.

No entanto, o Varnish não armazenará muito cache em uma instalação padrão do Magento, já que 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 combina com a configuração do Magento. Estes dois juntos formam uma configuração muito eficiente. É um módulo comercial, mas muito mais acessível do que um servidor mais poderoso seria.

As peças que você descarrega em um CDN ou Nginx não são seu verdadeiro problema, embora ajude. Até mesmo o Apache pode lidar com um grande número de solicitações estáticas. Você precisa armazenar em cache as coisas que exigem esforço para gerar de novo e de novo, ou seja, suas partes dinâmicas.

    

Answer 2

Eu normalmente configuro o MaxRequestsPerChild para estar na casa dos milhares - normalmente, perto de 10.000.

Você diz que tem "o cache PHP recomendado" - mas você tem o APC instalado? Por fim, quantos usuários você vê acessando o website ao mesmo tempo. Se você tiver estatísticas estendidas do Apache, poderá ver quantos dos processos do Apache estão, na verdade, no estado Em Execução por vez.

800 ocorrências de arquivos APC por segundo e outro 200 usuários é muito. Se isso é um dual ou quad-core, eu esperaria que fosse manter-se bem embora. Se o banco de dados está realmente se atualizando, então conseguir uma máquina maior - e mais CPUs, pode ser a melhor coisa para isso, pelo menos agora.

    

Answer 3

Sua carga média é muito alta para um VPS dual core. 8 deve ser o máximo

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

Mais informações sobre o Event MPM: Documentação MPM do evento Apache

E mod_pagespeed: Google Code: mod_pagespeed

Se você continuar a ter problemas de carregamento mesmo depois de fazer as alterações acima, convém considerar mudar para um plano VPS diferente e melhor.

    

Answer 4

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

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

em quantos processos você normalmente tem solicitações de veiculação?

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

Peça uma cópia do livro de Steve Souders e leia-o. 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 construa algumas ferramentas para analisar os dados / isolar a lentidão. Semelhante para o MySQL.

Experimente o mysqltuner.pl e veja se ele indica algum problema.

    

Answer 5

Eu corri uma configuração semelhante, mas com nginx / php-fpm / apc (opcode e fast_backend / memcached (slow_backend). Acho php para ser o maior problema de recursos, provavelmente porque o magento é insanamente grande ou apenas mal codificado. Dê uma olhada no 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 tentar. Confira link e link .
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 em caso afirmativo, no tmpfs)?

    

Answer 6

Quando você usa o VPS, você está compartilhando a CPU. Eu recomendo que você converse com seu host para mover seu VPS para um hardware menos ocupado ou vá dedicado.

Devido à CPU compartilhada, seus aplicativos não podem ser executados no prazo e continuam sendo enfileirados, criando solicitações mais altas para serem processadas e também as despesas gerais que acompanham. Eventualmente, há uma condição em que o Apache, o php ou o mysql teriam superado seus próprios limites, causando problemas.

A linha de base é. VPS é basicamente compartilhado CPU. Seu host pode estar colocando muitas contas VPS na mesma CPU.

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

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

a pasta /var/mail.../root é hue, significa coletar muitos e-mails que vêm de seus aplicativos normalmente. Por exemplo, um script PHP com bugs está tentando enviar e-mail ou todas as tarefas do cron estão configuradas para enviar por e-mail o status das execuções do cron e da saída. Você pode olhar dentro do e-mail e ver o que o arquivo tem. Eu estou supondo que suas mensagens de erro para que você possa encontrar de onde vem.

Eu adicionarei mais se você precisar de mais informações e talvez eu precise de algumas informações também