Olá, gurus superiores do servidor!
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 durante as horas mais ocupadas da semana. Apesar disso, estou tendo interrupções aleatórias de 1 a 2 vezes por semana, quando o servidor inteiro para de responder.
Um efeito interessante desse bloqueio é que todos os cronjobs parecem ser executados mais tarde do que o planejado, pelo menos é o que indicam os registros de data e hora em vários registros do sistema. Assim, parece-me que, na verdade, é todo o servidor que congela, não apenas o software personalizado em execução como parte do serviço do tomcat. O desligamento normalmente dura cerca de 3-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 sysstat Eu posso ver picos enormes tanto na carga média quanto nas esperas de bloco de disco que correspondem no tempo exatamente quando os clientes relataram problemas com o sistema backend. Segue-se um gráfico da utilização do disco a partir do sar com um pico muito óbvio em torno das 12.30pm.
Minhas sinceras desculpas por colocar isso em um servidor externo, mas meu representante é baixo para incluir arquivos aqui diretamente. Também tive que colocá-los juntos, pois só posso postar um link: S
Sar plots: http://213.115.101.5/abba/tmpdata/sardata_es.jpg
Graph 1: Block wait, notice how the util% goes upp to 100% at approx 12.58
Graph 2: Block transfer, nothing unusual here.
Graph 3: Average load, peaks together with graph 1
Graph 4: CPU usage, still close to 0%.
Graph 5: Memory, nothing unusual here
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 uma interface SOAP, para permitir que os usuários se conectem ao banco de dados. Aplicativos remotos também se conectam ao servidor via SSH para puxar e fazer upload de arquivos para ele. Nos horários de pico, acho que temos cerca de 50 conexões simultâneas SSH / SFTP e não mais que 1-200 conexões via http (soap / tomcat).
Pesquisando, encontrei discussões sobre identificadores de arquivos e identificadores de inode, mas acho que eles são normais 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 tempo de desligamento acima, mas o inode-nr aqui é SEMPRE muito alto comparado ao anterior.
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 já vi isso em dois servidores independentes executando a mesma configuração de hardware, sistema operacional, software, configuração de invasão, etc. Assim, quero acreditar que seu software depende mais da configuração do que do hardware.
Um grande obrigado pelo seu tempo
/ Ebbe
Os problemas estavam relacionados a um problema de incompetência entre o Ubuntu 8.04 LTS (Hardy) e o controlador Dell PERC 6 / i RAID, conforme relatado neste bug: link Atualizando para o Ubuntu 10.04 LTS Lucid (kernel 2.6.32) resolve o problema.
Caso alguém encontre os mesmos problemas.
Pode ser que você esteja executando uma consulta pesada que está fazendo uma varredura completa na tabela. Você verificou seu log de consultas lentas.
Se esse for o caso, apenas adicione índices adequados.
PS: Desculpe Se você já fez isso.
Tags performance linux