Longos tempos de espera antes da resposta do servidor Apache 2.2 (Gentoo LAMP)

Question

Recentemente, mudei o site de um cliente (usando o concrete5 CMS) para um VPS executando Gentoo, Apache 2.2, PHP5 e MySQL 5 e notei que os tempos de resposta do Apache são muito ruins (era o mesmo no servidor antigo), às vezes até 8-9 segundos, mas mais frequentemente entre 300ms e 3 segundos (para 300ms eu não me importo). Eu sei que não é latência de rede, já que o servidor tem um ping (da minha localização) de cerca de 30ms.

Aqui está um exemplo dos tempos (você pode ver que é irritante após a espera inicial):

EstouexecutandooAPC(embora não sou Certifique-se de que está funcionando corretamente ...) e SuExec. Os módulos do Apache são:

 core_module (static)
 authn_file_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 env_module (static)
 expires_module (static)
 headers_module (static)
 setenvif_module (static)
 version_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 info_module (static)
 suexec_module (static)
 cgi_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 suphp_module (shared)

e os módulos do PHP são:

bcmath
calendar
ctype
curl
db
dbase
domxml
exif
ftp
gd
gettext
iconv
imap
mbstring
mcrypt
mime_magic
mysql
openssl
overload
pcre
posix
session
standard
sysvsem
sysvshm
tokenizer
xml
xslt
zlib

Eu tenho o gzip ativado em todos os arquivos relevantes.

O Apache está sendo executado usando o prefork, e as configurações no httpd.conf são:

<IfModule prefork.c>
StartServers         10
MinSpareServers      10
MaxSpareServers      20
MaxClients           250
MaxRequestsPerChild  4000
</IfModule>

HostnameLookups Off

Tenho notado que as páginas que (acho) são pesadas no banco de dados, como o Dashboard do CMS, geralmente são mais lentas. Eu pensei que isso poderia significar que o MySQL poderia ser otimizado. Gostaria de saber também sobre os módulos Apache - eu fico confuso entre mod_php5, mod_cgi, mod_fastcgi etc etc - há conselhos conflitantes em toda a rede quanto ao melhor para usar.

Aqui está a saída do MySQLTuner :

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.44-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 35M (Tables: 161)
[!!] Total fragmented tables: 15

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3d 21h 44m 16s (293K q [0.868 qps], 1K conn, TX: 135M, RX: 90M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 58.0M global + 1.6M per thread (100 max threads)
[!!] Maximum possible memory usage: 219.7M (93% of installed RAM)
[OK] Slow queries: 0% (0/293K)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/20.9M
[OK] Key buffer hit rate: 99.6% (5M cached / 21K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 3K sorts)
[!!] Temporary tables created on disk: 47% (2K on disk / 5K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 6% (64 open / 1K opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (356K immediate / 356K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (>= 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)

Eu notei quando uma página pesada do DB foi carregada, o uso da CPU chegou a 57% (usando o topo) - para mim isso sugere que há algum material mal otimizado do MySQL ou o armazenamento em cache é absolutamente necessário para acelerar essa configuração. p>

Qualquer ajuda seria muito apreciada!

    

Answer 1

Você sabe exatamente o que os processos de trabalho do apache estão ficando pendurados? Tente isto para ver:

mkdir /strace; ps auxw | grep httpd | awk '{print"-p " $2}' | xargs strace -o /strace/strace.log -ff -s4096 -r

Carregue algumas páginas novas (ou seja, não armazenadas em cache localmente) no seu navegador, CTRL + C para interromper o strace e, em seguida, classifique os strace.logs pelo tempo gasto em cada chamada:

for i in 'ls /strace/*'; do echo $i; cat $i | cut -c11-17 | sort -rn | head; done

Visualize quaisquer strace.logs com mais de 1.0 segundo chamadas e pesquise pelo tempo a partir da saída do comando anterior. Isto irá indicar-lhe o passo exato em que estão pendurados.

Você tem uma firewall como o CSF instalado? Eu vi o mesmo problema em um VPS. Ao depurar processos httpd com strace, estava levando até 5 segundos ou mais em chamadas gettimeofday. Estranhamente, reduzi isso ao CSF, que estava tentando filtrar a interface venet0, uma interface de loopback nos contêineres OpenVZ ou Virtuozzo. Configurar esse parâmetro em /etc/csf/csf.conf principalmente o corrigiu para mim:

"ETH_DEVICE_SKIP = "venet0,lo"

Eu digo principalmente porque às vezes ainda há 500-1000ms de espera para estabelecer as conexões, mas é uma grande melhoria a partir de 5000 +.

    

Answer 2

Aqui está um excelente primer / walkthrough para solucionar esses problemas tipos de problemas usando strace.

Maximum possible memory usage: 219.7M (93% of installed RAM)

Esta deve ser uma caixa VPS de baixo custo?

• Você pode querer discar suas configurações do MySQL
• Ajuste o Apache para reduzir o número de forquilhas httpd
• Verifique se você pode ativar a troca
• O APC está configurado para armazenar códigos opcionais automaticamente? Verifique usando o script 'apc.php' distribuído com apc.

Answer 3

Você tem que separar rede, apache, mysql e php como fontes de latência.

Se você conseguir puxar uma imagem do apache rapidamente (muito pouco tempo até o primeiro byte), a rede e o apache estarão normalmente bem.

Se você pode puxar uma página apenas com uma instrução phpinfo (), então normalmente o PHP está ok (pode precisar de alguns ajustes).

Se você escrever um teste simples de conexão com o banco de dados e for rápido, então essa camada também estará bem.

Por fim, puxe a página do aplicativo. Se for lento, o problema é interno ao processamento das aplicações. Embora o ajuste possa ajudar, isso é muito mais difícil de resolver.

Sem criar o perfil do aplicativo, pode ser difícil encontrar o problema. Ferramentas como o NewRelic podem ajudar com esse problema, mas não é uma cura.

O seu aplicativo tem algum tipo de depuração interna para mostrar onde o tempo está sendo gasto?

    

Answer 4

Sugiro adicionar uma medida de tempo de renderização e verificar quanto tempo demora para o servidor renderizar a página HTML pura. Então você sabe se está no CMS ou em outro lugar. Aposto que meu 2 cent não é a configuração do seu servidor. / maddin