Olá gurus de servidores superiores!
Estou executando um servidor Ubuntu que hospeda um serviço Apache Tomcat junto com um banco de dados MySQL. A carga do servidor está sempre próxima de zero, mesmo nos horários de maior movimento da semana. Apesar disso, estou enfrentando interrupções aleatórias de uma a duas vezes por semana, onde todo o servidor para de responder.
Um efeito interessante desse bloqueio é que todos os cronjobs parecem ser executados mais tarde do que o programado, pelo menos é o que indicam os carimbos de data e hora em vários logs do sistema. Assim, parece-me que é de fato todo o servidor que congela, não apenas o software personalizado em execução como parte do serviço Tomcat. O desligamento normalmente dura cerca de 3 a 5 minutos e depois tudo volta ao normal.
Hardware:
Model: Dell PowerEdge R720, 16 cores, 16 GB ram
HDD-configuration: Raid-1 (mirror)
Main services:
apache tomcat, mysql, ssh/sftp
#uname -a
Linux es2 2.6.24-24-server #1 SMP Tue Jul 7 19:39:36 UTC 2009 x86_64 GNU/Linux
Executando o sysstat, posso ver picos enormes na carga média e nas esperas de blocos de disco que correspondem exatamente ao momento em que os clientes relataram problemas com o sistema de back-end. A seguir está um gráfico do uso do disco do sar com um pico muito óbvio por volta das 12h30.
Minhas sinceras desculpas por colocar isso em um servidor externo, mas minha reputação é muito baixa para incluir arquivos aqui diretamente. Também tive que juntá-los, pois só posso postar um link:S
Parcelas Sar:http://213.115.101.5/abba/tmpdata/sardata_es.jpg
Gráfico 1: Espera do bloco, observe como o util% sobe para 100% em aproximadamente 12,58
Gráfico 2: Transferência em bloco, nada de incomum aqui.
Gráfico 3: Carga média, picos junto com gráfico 1
Gráfico 4: Uso de CPU, ainda próximo de 0%.
Gráfico 5: Memória, nada de incomum aqui
Alguém tem alguma pista sobre o que poderia causar esse efeito em um sistema? Como expliquei anteriormente, o único software em execução no servidor é um servidor Tomcat com interface SOAP, para permitir que os usuários se conectem ao banco de dados. Os aplicativos remotos também se conectam ao servidor via SSH para extrair e fazer upload de arquivos para ele. Em horários de pico, suponho que temos cerca de 50 conexões SSH/SFTP simultâneas e não mais do que 1-200 conexões via http (soap/tomcat).
Pesquisando no Google, encontrei discussões sobre identificadores de arquivo e identificadores de inode, mas acho que isso é normal para kernals 2.6.x. Alguém que discorda?
cat /proc/sys/fs/file-nr
1152 0 1588671
cat /proc/sys/fs/inode-state
11392 236 0 0 0 0 0
Ao mesmo tempo, "sar -v" mostra esses valores para o momento do desligamento acima, mas o inode-nr aqui é SEMPRE muito alto comparado ao acima.
12:40:01 dentunusd file-nr inode-nr pty-nr
12:40:01 40542 1024 15316 0
12:45:01 40568 1152 15349 0
12:50:01 40587 768 15365 0
12:55:01 40631 1024 15422 0
13:01:02 40648 896 15482 0
13:05:01 40595 768 15430 0
13:10:01 40637 1024 15465 0
Eu vi isso em dois servidores independentes executando a mesma configuração de hardware, sistema operacional, software, configuração de ataque, etc. Portanto, quero acreditar que é mais dependente de software/configuração do que de hardware.
Muito obrigado pelo seu tempo
/Ebbe
Responder1
Os problemas estavam relacionados a um problema de incompatibilidade entre o Ubuntu 8.04 LTS (Hardy) e o controlador RAID Dell PERC 6/i, conforme relatado neste bug:https://bugs.launchpad.net/ubuntu/+source/linux/+bug/607167 Atualizar para o Ubuntu 10.04 LTS Lucid (kernel 2.6.32) resolve o problema.
Caso alguém tenha os mesmos problemas.
Responder2
Pode ser que você esteja executando alguma consulta pesada que esteja fazendo uma varredura completa da tabela. Você verificou seu log de consulta lenta.
Se for esse o caso, basta adicionar índices adequados.
PS: Desculpe se você já fez isso.