De acordo com as Leis 12.965/2014 e 13.709/2018, que regulam o uso da Internet e o tratamento de dados pessoais no Brasil, ao me inscrever na newsletter do portal DICAS-L, autorizo o envio de notificações por e-mail ou outros meios e declaro estar ciente e concordar com seus Termos de Uso e Política de Privacidade.

Melhorando o desempenho de um servidor em menos de três minutos ao ser slashdotted

Colaboração: Rubens Queiroz de Almeida

Data de Publicação: 01 de novembro de 2010

Este texto foi traduzido e adaptado a partir do original em inglês de autoria de Mark Dennehy. Este texto pode ser distribuído sob uma licença Creative Commons Attribution-Share Alike 3.0 Unported License.

Você escreveu um artigo em seu blog sobre algo que parecia bastante inofensivo mas, por alguma razão, seu artigo atraiu a atenção de um dos maiores sites e agora a carga de seu servidor está em 110 e subindo, os comandos que você emite em sua sessão ssh levam trinta segundos ou mais para responder, e dado que seu artigo está na página principal do site slashdot no horário nobre, parece que isto não é temporário. O que você faz?

Certo, primeiras coisas primeiro. Você não tem tempo de fazer uma sessão de ajustes apropriada. Você precisa fazer um ajuste rápido e rasteiro. Você pode deixar para fazer as coisas direito depois que o tráfego em seu site se normalizar, e então você pode voltar com um plano e ferraments decentes, como siege e assim por diante - mas esta é a versão "conserte em três minutos". Então, se você ver aqui coisas que parecem toscas para você, não se desespere, tudo parece tosco quando você está tentando fazer as coisas dentro deste tipo de situação.

Primeiramente, você precisa conseguir usar a linha de comando em seu servidor. Com a carga da máquina em 110 - e esta carga não vai baixar logo e até que ela baixe, você não consegurá fazer o resto do trabalho necessário, pois demora muito para que até mesmo a shell responda. A carga está sendo causada pelo Apache e MySQL pegando mais trabalho do que o servidor consegue atender, fazendo com que o servidor realize swap em excesso; e você tem que impedir que novas requisições cheguem para recuperar. Você pode ter o comando sudo killall -9 apache2 se você conseguir abrir um terminal ssh para fazer o trabalho (e isto é a primeira coisa que você deve tentar), mas provavelmente você terá que reiniciar o servidor. Se para fazer isto você tiver que ligar para seu provedor, caminhar para a sala do servidor, ou apenas clicar em um botão em uma interface web, isto é a primeira coisa a ser feita. Não adie, porque a menos que todos parem de ler sua página imediatamente, a carga não vai baixar.

Uma vez que seu servidor tenha rebootado (e eu quero dizer imediatamente - sente-se esperando que o comando ping comece a responder), faça um ssh para o servidor e pare o apache. Não se preocupe com o MySQL por enquanto, visto que as requisições chegam através do Apache. O servidor web tem que ficar fora até que tudo esteja pronto novamente. Você perderá alguns minutos de serviço, mas isto é recuperável para um blog (e se isto for algo mais sério do que um blog, então, para começo de conversa, você estará em apuros por não ter especificado o hardware corretamente. Então, limite suas perdas por enquanto e encare a sua responsabilidade mais tarde).

Neste ponto - se você estiver logado ou se você conseguiu rodar o comando killall com sucesso - se for um servidor debian você deve executar o comando sudo /etc/init.d/apache2 stop (eu já falei que eu amo o debian por ter scripts como estes e não coisas como apachectl, apenas uma interface padrão fácil de lembrar para cada serviço ativo. Maravilhoso). Eu vou arrumar depois os problemas causados pelo killall, ou então eu irei encerrar o apache da forma correta, dependendo da forma como você chegou aqui.

A primeira coisa que precisamos fazer é examinar a configuração do MySQL. Abra o arquivo my.cnf, onde quer que você o tenha posta (para instalações Debian, o arquivo fica em /etc/mysql/my.cnf).

A primeira coisa que precisamos fazer é examinar a configuração do MySQL. Abra o arquivo my.cnf, onde quer que você o tenha colocado (em instalações Debian padrão, este arquivo fica em /etc/mysql/my.cnf). Precisamos ajustar apenas alguns parâmetros. Primeiramente, key_buffer. Esta é provavelmente a variável mais crítica pois, por padrão, todas as tabelas serão do tipo MyISAM (se não forem, então isto não é tão crítico). O valor é definido, por padrão, como 16 MB; vamos aumentar este valor um pouco. Em um servidor de banco de dados dedicado, este valor teria um valor bem alto - algo como 50% da memória total disponível. Neste caso, com todos os aplicativos no mesmo servidor, utilizaremos um valor um pouco menor, pois o Apache também irá precisar de bastante RAM - 256 MB é um bom valor para começar.

Em seguida, iremos desabilitar oi InnoDB completamente para diminuir a quantidade de recursos usados pelo MySQL. Novamente, por padrão, o Wordpress não o usa. Apenas certifique-se de que a diretiva skip-innodb está ou descomentada ou inserida no arquivo my.cnf.

Finalmente, iremos habilitar o cache de consultas (query cache). O fato é que o cache de consultas do MySQL é particularmente ineficiente. Se uma consulta é executada exatamente no momento em que chega, ela será colocada no cache - mas qualquer tipo de mudança, não importa o tamanho, fará com que ela saia do cache. Sendo assim, este recurso não é tão útil quanto poderíamos imaginar. Entretanto, mesmo assim, ainda ajuda um pouco, então nós iremos aumentar ligeiramente o seu tamanho (48 MB de RAM é suficiente para nosso caso). Então, nossas mudanças no arquivo my.cnf são:

  key_buffer = 256M
  query_cache_limit = 16M
  query_cache_size = 48M
  skip-innodb

Uma vez que estas mudanças tenham sido feitas, execute o comando sudo /etc/init.d/mysql restart para fazer com que o MySQL rode com as novas configurações. Uma vez que isto tenha sido feito, vamos para o próximo nível na pilha - Apache. Em sistemas Debian, os arquivos de configuração são dispostos de forma ligeiramente diferente do normal; as mudanças de configuração que iremos fazer serão feitas no arquivo /etc/apache2/apache2.conf mas em outras instalações estas configurações ficam em httpd.conf ou em outros locais.

Por padrão, a instalação do Apache usa a configuração do MPM prefork - uma thread por processo. É algo velho, mais lento, menos eficiente, mas tem menos bugs do que o worker MPM que não é threadsafe. Então, localize as configurações do prefork MPM no arquivo apache2.conf. Em uma instalação padrão, deve ser algo como:

  <IfModule mpm_prefork_module>
  StartServers          5
  MinSpareServers       5
  MaxSpareServers      10
  MaxClients          150
  MaxRequestsPerChild   0
  </IfModule>

Nós vamos reduzir bastante a quantidade de trabalho que o Apache executa de uma vez aqui. Sim, alguns usuários terão que aguardar alguns segundos para ver as suas páginas - mas neste momento, com a carga do servidor em 110 e subindo, eles podem esperar até que o browser desista de obter a página e eles não verão nada. Então, nós iremos reduzir ligeiramente o número de servidores que o Apache irá criar para atender aos pedidos de 5 para 4; iremos aumentar o número de servidores extras que ele irá manter para atender pedidos (nós queremos reduzir o overhead de iniciar e parar estes processos) de 10 para 12. Iremos definir um limite máximo para o número de processos que podemos ter, e iremos manter este número abaixo de 100. Isto funciona em meu sistema, que é um sistema básico; você pode se safar com mais, mas por enquanto use estas configurações e você poderá colocar seu servidor no ar e você poderá aumentar um pouco e verificar novamente com o tempo (e de qualquer forma, este guia realmente não é voltado para sites grandes, apenas para sites pequenos como o meu que são pegos no pulo). Nós vamos também garantir que nenhum processo do apache consuma muitos recursos de uma vez criando um limite no número de pediso que qualquer processo pode atender - nós iremos manter este número baixo por enquanto (3) mas poderemos aumentá-lo mais tarde. Então, as nossas configurações modificadas ficam desta forma:

  <IfModule mpm_prefork_module>
  StartServers          4
  MinSpareServers       4
  MaxSpareServers       12
  ServerLimit           96
  MaxClients            96
  MaxRequestsPerChild   3
  </IfModule>

Pronto. Neste ponto, você tem duas opções. A primeira é reinicializar o Apache e voltar a trabalhar. É possível que dê certo - mas você deve manter uma janela aberta com o aplicativo htop executando para observar como as coisas (e principalmente você deve prestar atenção na taxa de uso do espaço de swap e na carta. O swap é crítico, a carga é indicativa de que problemas estão surgindo - se qualquer um deles sair fora de linha, mate o apache e edit a configuração no arquivo apache2.conf configurando valores ainda mais baixos para // ServerLimit, //MaxClients and MaxRequestsPerChild antes de reiniciar o Apache. Se esta for a sua opção favorita, siga para o final deste artigo.

Entretanto, se você quiser dar um passo adicional, você pode fazer a instalação do memcached rapidamente. É uma forma muito eficar de reduzir a carga em sistemas Debian e é muito mais simples do que você pensa:

  sudo aptitude install build-essential php5-devel php-pear memcached

E instale as demais bibliotecas que o memcached precisa:

  pecl install memcached

Uma vez que este passo esteja completo, edite o arquivo php.ini (em sistemas Debian, o arquivo é /etc/php5/apache2/php.ini) e insira a seguinte linha (pode colocar em qualquer lugar, mas prefira usar a seção de extensões (extensions), pois é o mais correto):

  extension=memcache.so

Isto deve ser o suficiente para instalar e rodar o memcached com uma configuração padrão (nós poderemos acertar esta configuração mais tarde). Precisamos agora configurar o Wordpress para que ele possa desfrutar os benefícios do memcached. Faça o download de object-cache.php e copie-o para o diretório wp-content de seu site e altere as permissões e propriedade deste arquivo:

  cd  www/wp-content directory
  sudo wget http://plugins.trac.wordpress.org/export/215933/memcached/trunk/object-cache.php
  sudo chown www-data.www-data object-cache.php
  sudo chmod 644 object-cache.php

É isto. Rápido e rasteiro, e tudo com a configuração padrão, mas este é um remédio de três minutos para você (bem, talvez cinco minutos se você também configurar o memcached, e eu estou assumindo que você tenha uma conexão rápida para executar o passo do aptitude, mas memos assim ...).

Agora, reinicie o apache e tudo deve funcionar com o memcached fazendo o cache de uma grande quantidade de pedidos e mantendo a carga do servidor em um nível aceitável.

  sudo /etc/init.d/apache2 force-reload
  sudo /etc/init.d/apache2 restart

E uma vez que o pico de tráfego tenha passado, invista algum tempo para configurá-lo corretamente!