temos um serviço de correio com estes detalhes:
1-Centos 6.4
2:Postfix 2.6.6
3:roundcube 0.8
4:dovecot 2.0.9.7
5:mysql-server 5.1.71
está tudo bem, mas no horário de pico de uso, as conexões suspensas do roundcube aumentam de 1 ou 2 ou 3 para 270 em menos de 10 minutos e os arquivos abertos do Apache (medidos por lsof) aumentam de 4.000 para 20.000 nesse horário de pico.
este é o Apache conf: (o Apache funciona no modo prefork)
PidFile run/httpd.pid
Timeout 60
KeepAlive On
MaxKeepAliveRequests 100
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>
TraceEnable off
LimitRequestLine 1024
LimitRequestFields 100
LimitRequestFieldsize 1024
LimitRequestBody 10241024
e aqui está a configuração do mysql:
secure_auth=1
local_infile=0
max_connections = 600
max_allowed_packet = 16M
key_buffer =256M
wait_timeout=240
interactive_timeout=180
connect_timeout=10
innodb_buffer_pool_size=2G
quando as conexões suspensas do roundcube aumentam para> 100, quase os serviços (web, mail, mysql) ficam inativos ....
obrigado por qualquer sugestão.
Responder1
A resposta é:
Eu editei a opção apache max_client para diminuir o valor 256 -> 50 por quê!?
para um problema (ainda) desconhecido, todos os processos apache pré-bifurcados consomem cerca de 100% do uso da CPU (100% de uso desse núcleo executando o processo apache pré-bifurcado por alguns momentos)
Então o sistema fica inativo, porque o sistema tem 64 núcleos de CPU quando todos os 256 processos do apache usam 100% de uso da CPU, o sistema e os serviços ficam inativos
o problema ainda existe, mas os serviços não apresentam problemas. Acho que o problema está relacionado a ataques de rede (nossas ferramentas de monitoramento relatam muitos ataques por dia), que às vezes causam problemas como bloqueio de recursos ou qualquer outra coisa
obrigado por todas as sugestões.
Responder2
Agora
Depois de cerca de 5 anos
O problema foi detectado e resolvido em poucos dias.
Foi tão complicado para um administrador de sistema Jr. como eu;)
Houve um problema no sistema de arquivos de cluster GFS2 que meu colega de equipe preparou no iSCSI LUN e esse problema levou a vários problemas e problemas no Dovecot e no roundcube (e depois no Apache)
para sua informação, quando presto atenção ao parâmetro% wa no comando top (era cerca de 90%), pensei (talvez) que houvesse um problema no nível do sistema de arquivos.
Então decidi transferir todos os dados para o novo sistema de arquivos de cluster (ocfs2) porque o GFS estava obsoleto!
Primeiro de tudo, todos os dados foram movidos para o novo sistema de arquivos de cluster (no ocf2) e depois redesenharam todo o sistema baseado em pacemake haproxy no debian wheezy!