alta carga pode causar travamento do servidor e erro "bloqueado por mais de 120 segundos"?

17

Atualmente executando algumas VMs e servidores 'baremetal'. Java está sendo executado em alta - mais de 400% + às vezes. Aleatoriamente, o servidor trava com o erro no console "java - bloqueado por mais de 120 segundos" - kjournald, etc.

Não consigo obter uma saída dmesg porque, por algum motivo, esse erro grava apenas no console, ao qual não tenho acesso, pois ele é hospedado remotamente. portanto, não consigo copiar um rastreamento completo.

Mudei o ambiente em que está - até mesmo o servidor físico e ainda está acontecendo.

Alterei hung_task_timeout_secs para 0, pois esse é um falso positivo conforme http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html .

Além disso, o irqbalance não está instalado, talvez ajude?

este é o Ubuntu 10.04 64bit - o mesmo problema com o mais recente 2.6.38-15-server e 2.6.36.

problemas de CPU ou memória / nenhuma troca restante pode causar esse problema?

aqui está a mensagem do console:

[58Z?Z1.5?Z840] INFUI task java:21547 blocked for more than 120 seconds.
[58Z?Z1.5?Z986] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z06Z] INFUI task kjournald:190 blocked for more than 120 seconds.
[58Z841.5?Z336] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?Z600] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z841.5?Z90?] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z841.5?3413] INFUI task java:21547 blocked for more than 120 seconds.
[58Z841.5?368Z] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?ZZ36] INFUI task kjournald:60 blocked for more than 120 seconds.
[58Z961.5?Z6Z5] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.
[58Z961.5?31ZZ] INFUI task flush-202:0:709 blocked for more than 120 seconds.
[58Z961.5?3393] "echo 0 > /proc/sgs/kernel/hung_task_timeout_secs" disables this
message.

linux kernel

— Tee
fonte

15

Sim, poderia.

O que isso significa é bastante explícito: o kernel não pôde agendar a tarefa por 120 segundos. Isso indica falta de recursos, geralmente em torno do acesso ao disco.

irqbalancepode ajudar, mas isso não parece óbvio. Você pode nos fornecer o entorno dessa mensagem dmesg, em particular o rastreamento de pilha que a segue?

Além disso, este não é um falso positivo. Isso não diz que a tarefa está pendurada para sempre e a afirmação está perfeitamente correta. Isso não significa que seja um problema para você, e você pode decidir ignorá-lo se não notar nenhum impacto no usuário.

Isso não pode ser causado por:

um problema de CPU (ou melhor, isso seria uma falha de hardware insanamente improvável),
um problema de memória (muito improvável uma falha de hardware, mas não aconteceria várias vezes; não haveria falta de RAM como processo oom-killed),
falta de troca ( oom-killernovamente).

Para uma extensão, você pode culpar isso por falta de memória, no sentido de que privar seu sistema de armazenamento em cache de dados na RAM causará mais E / S. Mas não é tão simples quanto "ficar sem memória".

— Pierre Carrier
fonte

Não há nada sendo gravado em / var / log / dmesg, então apenas colei o que o console mostrou .. quando isso aparece, o sistema está 100% travado.

— Tee

Esta mensagem é proveniente do kernel, aparecerá em dmesg(se tiver sido registrado o suficiente), pois este comando imprime o buffer do anel de registro do kernel. Espero que sua sysloginstalação também faça o logon em algum lugar /var/log, mas eu não sabia onde.

— Pierre Carrier

A mensagem NÃO aparecerá /var/log/dmesg, mas poderá aparecer quando você executar o dmesgcomando. O arquivo é criado durante o processo de inicialização e geralmente captura apenas as mensagens do kernel no momento da inicialização (que de outra forma acabariam rolando para fora do buffer de anel do kernel. Você também pode instalar / ativar sysstate examinar a utilização de recursos conforme relatado lá. Estou suspeitando de disco I / o / iowait, provavelmente relacionado com a troca (sysstat vai ajudar na identificação isso).

— Dr. Edward Morbius

@ Dr.EdwardMorbius Então, como podemos corrigir isso? Estou tendo um grande problema relacionado a isso no nosso servidor Zimbra, que estava funcionando muito bem em um ambiente de produção até recentemente.

— Dispensado

@ Lopsided: Desculpe pela demora, eu não estou aqui frequentemente. Resumidamente: você terá que criar um perfil do seu processo Java e descobrir por que ele está travando. A coleta de lixo é uma área em que tive problemas (e sucessos) no ajuste. Consulte ergodymics da coleta de lixo da JVM e consulte oracle.com/technetwork/java/javase/gc-tuning-6-140523.html Achei que o aumento da pilha ajudou significativamente.

— Dr. Edward Morbius

6

sudo sysctl -w vm.dirty_ratio=10
sudo sysctl -w vm.dirty_background_ratio=5

Em seguida, confirme a alteração com:

sudo sysctl -p

resolveu para mim ....

— usuario
fonte

6

Você deve explicar o que cada uma dessas configurações faz.

— kasperd

6

Isso corrigiu um problema semelhante que eu estava tendo em um ambiente de docker. Encontrei uma explicação aqui: blackmoreops.com/2014/09/22/… . "Por padrão, o Linux usa até 40% da memória disponível para o armazenamento em cache do sistema de arquivos. Depois que essa marca é atingida, o sistema de arquivos libera todos os dados pendentes no disco, fazendo com que todas as seguintes E / S sejam sincronizadas. Para liberar esses dados no disco, existe um limite de tempo de 120 segundos por padrão no caso aqui o subsistema de IO não é rápido o suficiente para limpar a withing dados ...".

— Peter M

2

Recentemente, passei por esse erro em um de nossos clusters de produção:

11 de novembro 14:56:41 Kernel xxx: INFO: task xfsalloc / 3: 2393 bloqueado por mais de 120 segundos.

Nov 11 14:56:41 Kernel Xxxx: não contaminado 2.6.32-504.8.1.el6.x86_64 # 1

11 de novembro 14:56:41 xxx: "echo 0> / proc / sys / kernel / hung_task_timeout_secs" desativa esta mensagem.

..

Na verificação adicional dos logs sar encontrados, a espera de E / S foi aumentada durante o mesmo tempo.

E, ao verificar o Hardware (discos físicos), foram detectados erros médios e outros erros SCSI em um dos discos físicos, que, por sua vez, estavam bloqueando as entradas / saídas, devido à falta de recursos para alocação.

11/11/15 19:52:40: sinalizadores de pRdm 607b8000 terminados = 0 TimeOutC = 0 RepetiçãoC = 0 Solicitação c1173100 Resposta 60e06040 iocStatus 0048 retryC 0 devId: 3 devFlags = f1482005 iocLogInfo: 31140000

11/11/15 19:52:40: DM_ProcessDevWaitQueue: Gerenciamento de tarefas no processo devId = x 11/11/15 19:52:40: DM_ProcessDevWaitQueue: Gerenciamento de tarefas no processo devId = x

Portanto, isso ocorreu devido a um erro de hardware em nosso cluster.

Portanto, seria bom, se você pudesse verificar o arquivo principal e também se o utilitário ipmi estiver presente, verifique o comando ipmiutil / ipmitool sel elist para verificar o problema.

Atenciosamente, VT

— Varun Thomas
fonte

0

Você pode acessar a interface de monitoramento do seu provedor de nuvem e verificar se não excedeu o máximo de IOps especificado para o seu armazenamento, isso explicaria por que demorou muito tempo para liberar os dados do cache.
O número máximo de IOps está disponível na sua página de atributos de armazenamento.

— Emmanuel
fonte