kjournald razões para alto uso

Question

Estou tentando descobrir por que kjournald está enlouquecendo na minha máquina. É uma caixa de 8 núcleos com muita memória. Tem ~ 50% de carga da CPU.

O iotop não parece apontar para nenhum processo específico - algumas rajadas de escritas aqui e ali (principalmente o cron começando, algumas estatísticas de monitoramento geradas, etc.) Quando eu usei sys/vm/block_dump para reunir as estatísticas de gravação, listas como esta:

kjournald(1352): 1909
sendmail(28934): 13
cron(28910): 12
cron(28912): 11
munin-node(29015): 3
cron(28913): 3
check_asterisk_(28917): 3
sh(28917): 2
munin-node(29022): 2
munin-node(29021): 2

Onde kjournald actions são apenas WRITEs.

Por que isso está acontecendo? O que mais eu deveria olhar para limitar um pouco a atividade do kjournald? Parece desproporcional ao que realmente está sendo escrito.

    

Answer 1

kjournald é responsável pelo diário do ext3 (journaling filesystem). Sabe-se que usa muito CPU sob certas cargas. Não há muito o que fazer exceto usar outro sistema de arquivos ou desabilitar o registro no diário (efetivamente fazendo o fs ext2).

Teoricamente, você pode usar um dos outros modos de registro no diário ext3 e verificar se o uso da CPU cai, mas lembre-se de que cada método compromete a segurança dos dados gravados no disco. Você ordenou o modo, o modo de writeback e o modo 'tudo'.

1. Pedidos: registram apenas metadados, mas garantem que os dados relacionados a um metadado sejam salvos antes de confirmar as alterações de metadados no diário.
2. writeback: registra apenas metadados, mas não garante que os dados sejam salvos antes do registro no diário.
3. journal: tudo é registrado em diário, dados e metadados. Pode ser lento, mas YMMV.

Você define o modo usando a opção data= ao montar o sistema, como data=ordered .

    

Answer 2

Por padrão, seu sistema de arquivos ext3 será montado com atimes ativado. Cada vez que um arquivo ou diretório é lido / acessado, o sistema de arquivos terá que gravar de volta nos discos para atualizar este registro de tempo. Isso significa que, mesmo que sua carga de trabalho seja basicamente baseada em leitura, você ainda precisará acessar os discos para atualizar os tempos de acesso de cada arquivo & diretório, e este é o meu palpite a respeito de porque o processo kjournald estava escrevendo tantos blocos.

Desativar o atime resultará em um grande aumento no desempenho, mas quebrará a conformidade com POSIX. Confira este artigo da Wikipédia para discussão sobre as críticas do atime.

Para desligar, basta adicionar noatime às opções de montagem do seu sistema de arquivos, ou você pode remontar conforme sugerido pelo poige. Aqui está um exemplo para o seu sistema de arquivos raiz:

mount -o remount,noatime /

    

Answer 3

Se a perfeição dos dados não é importante: faça isso

iostat -o -a

Certifique-se de que é realmente kjournald. É o que faz meu servidor travar.

Mudar o disco rígido para o SSD funcionaria.

Quando você vê o kjournald escrevendo 5-10MB de dados que você faz

link

sudo tune2fs -O ^has_journal /dev/sda1
sudo e2fsck /dev/sda1

em que sda1 é o nome da sua partição

Reportar o resultado no comentário para que eu possa verificar mais.

    

Answer 4

Não na ordem de fazer, apenas para mencionar:

1. mount -oremount,noatime /fs/being_over/journaled - como uma rápida suposição (você não nos mostrou como é seu mount )
2. Tente reduzir o tamanho do diário ( tune2fs -J … )
3. Mude para Reiser3 (robusto por um bom tempo, sim. E não há um diário tão ruim assim.)