Apache consome muita CPU e memória

4

Estou tendo alguns problemas com a CPU carregando uma memória com o Apache Web Server.

Estamos executando um Ubuntu Server 12.04 LTS em uma máquina virtual. Nosso servidor tem as seguintes especificações:

  • 8 GB de RAM;
  • 4 vCPUs ( 12ghz );

Configuramos o servidor para executar um site baseado no Drupal (7.23) . Então, nós instalamos o Apache, PHP, MySQL ... As versões estão abaixo:

  • Apache 2.2.22;
  • PHP 5.3.10 ( O PHP está rodando como Apache Module. );
  • APC 3.1.7;
  • MySQL 5.5.31 (todas as tabelas innodb);

Estou executando alguns módulos do apache também. Dê uma olhada ( apachectl -M ):

  • core_module (estático)
  • log_config_module (estático)
  • logio_module (estático)
  • mpm_prefork_module (estático)
  • link
  • so_module (estático)
  • actions_module (compartilhado)
  • alias_module (compartilhado)
  • authz_host_module (compartilhado)
  • deflate_module (compartilhado)
  • dir_module (compartilhado)
  • env_module (compartilhado)
  • include_module (compartilhado)
  • mime_module (compartilhado)
  • php5_module (compartilhado)
  • proxy_module (compartilhado)
  • proxy_http_module (compartilhado)
  • reqtimeout_module (compartilhado)
  • rewrite_module (compartilhado)
  • setenvif_module (compartilhado)
  • ssl_module (compartilhado)
  • status_module (compartilhado)

No apache2.conf , temos essa configuração:

    Timeout 90
    KeepAlive On
    MaxKeepAliveRequests 80
    KeepAliveTimeout 5
    HostnameLookups Off
    LogLevel warn

    <IfModule mpm_prefork_module>
        StartServers          10
        MinSpareServers       10
        MaxSpareServers       30
        MaxClients           120
        MaxRequestsPerChild 1000
    </IfModule>

O Host virtual do meu site:

    <VirtualHost *:80>
        ServerName blabla.bla.bla
        ServerAdmin [email protected]
        DocumentRoot /l/disk0/site/public_html

        <Directory />
            AllowOverride None
        </Directory>

        <Directory /l/disk0/site/public_html>
            Options MultiViews Indexes Includes FollowSymLinks ExecCGI
            AllowOverride All
            Order allow,deny
            allow from all
        </Directory>

        LogLevel warn
        ErrorLog "/l/disk0/site/logs/apache/site/error.log"
        CustomLog "/l/disk0/site/logs/apache/sit/access.log" combined
        SSLProxyEngine on
        RewriteEngine   on
        RewriteLog     logs/rewrite_www_log
        RewriteLogLevel        0

        Include rewrites-www.conf
</VirtualHost>

Módulos Drupal:

  • ACL 7.x-1.0
  • APC - Cache alternativo do PHP 7.x-1.0-beta4
  • Boost 7.x-1.0-beta2
  • Expiração do cache 7.x-2.0-beta2
  • CAPTCHA 7.x-1.0
  • Conjunto de ferramentas do caos (ctools) 7.x-1.3
  • Data 7.x-2.6
  • Acesso ao domínio 7.x-3.10
  • Domínios Blocos 7.x-2.0
  • Domain CTools 7.x-1.3
  • Domínio do domínio 7.x-1.0-beta3
  • Domínio Taxonomia 7.x-3.x-dev (2012-abr-29)
  • Exibições de domínio 7.x-1.5
  • Incorporar exibições Exibir 7.x-1.2
  • API de entidade 7.x-1.2
  • Referência de entidade 7.x-1.0
  • IMCE 7.x-1.7
  • IMCE Mkdir 7.x-1.0
  • Internacionalização 7.x-1.10
  • Link 7.x-1.1
  • Atualização de localização 7.x-1.0-beta3
  • Mídia 7.x-1.3
  • Meta tags rápidas 7.x-2.7
  • Boletim informativo 7.x-1.0-beta9
  • Elemento de Opções 7.x-1.9
  • Estilo de Página 7.x-1.0
  • Painéis 7.x-3.3
  • Pathauto 7.x-1.2
  • patológico 7.x-2.11
  • profile2 7.x-1.3 + 0-dev (2013-mai-24)
  • select_ou_other 7.x-2.19
  • sheetnode 7.x-1.0-beta4 + 3-dev (2013-mai-25)
  • Suporte à autenticação SMTP 7.x-1.0
  • Token 7.x-1.5
  • Transliteração 7.x-3.1
  • Variável 7.x-2.3
  • Vistas 7.x-3.7
  • Permissões de vocabulário por função 7.x-1.0
  • Webform 7.x-3.19
  • Validação do Webform 7.x-1.2
  • workbench 7.x-1.2
  • workbench_access 7.x-1.2
  • workbench_media 7.x-1.1
  • workbench_profile 7.x-1.1
  • xmlsitemap 7.x-2.0-rc2

Meu site é simples e não tem muitos visitantes. Estou falando de cerca de 500 visitantes por dia, talvez. Drupal pode causar muito carregamento da CPU? Ou um módulo?

Outro problema é o uso de memória. Quando um processo é criado, o 80M é alocado para o apache2. Eu acho que é demais.

Meu problema é que a CPU (todos os núcleos) tem uma carga alta. A maior parte do tempo, atingindo entre 90% e 100% de carga! O processo incorreto é o apache2 . A memória também é consumida sem pena. De um total de 8 GB, a memória consumida é de aproximadamente 6,5 GB a 7,5 GB . Não sei se minha configuração do Apache está errada ou se realmente preciso de mais hardware (acho que não). Drupal pode causar alta carga de CPU?

Quando a carga da CPU atinge 100%, o site cai e precisamos reiniciar o apache. Eu fiz uma solução alternativa com o Drupal usando o APC e instalando o Boost. teve alguma eficácia, mas a carga da CPU ainda é alta. Muito alto.

Se você precisar de mais informações, como módulos do Drupal e extensões PHP. Por favor me avise.

    
por Ricardo Giaviti 25.09.2013 / 18:30

2 respostas

4

Other problem is memory usage. When a process is created, 80M is allocated for apache2. I think is too much.

Isso é memória real ou virtual? Honestamente, não é muito; mais ao ponto, você deve se concentrar em consertar as coisas que estão causando problemas, não apenas as coisas que você "acha" deveriam ser diferentes.

Se você quiser que os processos do Apache ocupem menos memória, desabilite os módulos (já que cada um deles é mais código que precisa estar na memória). Mas se você precisar de todos os módulos que você ativou, então, bem, é isso.

Uma abordagem que usei ao administrar uma máquina com restrição de memória foi mover certas tarefas do Apache para outros servidores, para que eu pudesse ajustá-las separadamente.

Mas uma abordagem muito mais simples é mudar

MaxClients           120

para algo mais razoável para sua carga de trabalho:

If we consider the rewrite accesses and the main site traffic, we have about 70 requests per minute. Right now, we have 33 incoming connections.

Voltarei a isso momentaneamente, mas se você estiver lidando apenas com 33 solicitações simultâneas, não precisará de 120 trabalhadores!

MaxClients           40

E você provavelmente deve reduzir MinSpareServers e MaxSpareServer para algo como 5 e 10, respectivamente. Não há necessidade de ter 30 trabalhadores sentados sem fazer nada.

Agora, voltando para

If we consider the rewrite accesses and the main site traffic, we have about 70 requests per minute. Right now, we have 33 incoming connections.

Se você tiver 33 solicitações simultâneas, mas só fizer 70 por minuto, há algumas possibilidades:

  1. Suas solicitações estão demorando cerca de 30 segundos para serem veiculadas!
  2. Sua taxa de solicitações não é muito estável e, na maior parte do tempo, você não está fazendo nada.

Se o # 1 for o caso, eu realmente não sei como ajudar - algo está incrivelmente errado, tão errado que nem sei onde dizer para começar a procurar.

Se for o segundo lugar, acho que você está atendendo todos os seus recursos estáticos (imagens, js, css, fontes) do seu servidor. É melhor colocá-los em um CDN, mas se você realmente não puder fazer isso, poderá definir tempos de cache super longos e ativar o verniz novamente. Se você estiver usando processos do Apache com PHP e toda uma série de outras coisas apenas para servir arquivos estáticos, você está desperdiçando recursos - faça isso com algo mais simples!

My problem is that CPU (all cores) have a high load. Most of time, hitting between 90% and 100% load! The offending process is the apache2.

Este é um número constante ou apenas quando você atende a solicitações?

Como a aparência de E / S de disco ( iostat -mhx 2 )? O que o MySQL está fazendo ( show processlist; )?

Seu servidor é muito dominado pelo que você descreveu. Esta é uma boa notícia, porque significa que você deve corrigir esse problema.

    
por 13.12.2013 / 01:18
0

Eu enfrentei o mesmo problema. Faça o download do conteúdo da web na sua máquina local e escaneie o conteúdo com o Anti-Virus atualizado. No meu caso, o culpado é o vírus trojan. Depois de limpar o vírus no meu conteúdo da web, meu problema foi resolvido.

    
por 22.09.2017 / 11:33