systemd-journald grava uma média de 16 MB por hora!

Pensei em fazer muitos comentários sobre sua pergunta, mas a) isso seria demais e b) provavelmente teria chegado ao que você queria saber de uma resposta, mesmo que não tivesse como foco principal responder suas perguntas específicas.

Então, aqui vai uma resposta.

sudo iotop -a[…] systemd-journald: Em 3h40m ele escreveu 60MB!

Você está confundindo taxa de transferência com dados acumulados. Se meu programa (neste caso, Python, mas qualquer linguagem de programação serve)

f = open("somelogfile.bin", "wb")
while(True):
  f.seek(0)
  f.write(b"x")

quando você apenas conta o número de bytes gravados por segundo, este programa grava muitos megabytes por segundo, mas tudo o que ele realmente faz é atualizar o primeiro byte repetidamente. ls -l somelogfile.binlhe diria que o arquivo tem 1 B de tamanho.

Uma das características do formato de log binário do systemd-journal é que ele é

• pesquisável e
• relativamente seguro contra colisões.

Para conseguir isso, ele provavelmente está atualizando alguns campos regularmente, mesmo que não esteja anexando novos dados. (O formato é documentado publicamente. Estou com preguiça de verificar.)

(observe que os buffers de gravação podem complicar ainda mais a relação entre o que significa atualizar um arquivo e gravar um arquivo no disco.)

Agora, primeiro verifique: Qual é o tamanho real do seu diário? journalctl --disk-usageEle informará algo como 512 MB (pelo menos na minha máquina). Esse número será aproximadamente constante, porque o systemd-journald limpa os registros anteriores quando eles são antigos o suficiente e você está executando acima de um determinado limite de tamanho.

Em seguida, verifique o que realmente acontece nas coisas que são registradas:

journalctl -b0 -x -f -e
#          ^   ^  ^   ^
#          |   |  |   |
#          \———————————— 0: current boot's logging only
#              |  |   |  (ignore things that were logged during previous boots)
#              |  |   |
#              \———————— add a bit more explanation
#                 |   |
#                 \————— follow the output as it comes in live
#                     |
#                     \— scroll to end

mostrará o que o seu sistema registra. Adicione --userpara ver o que os seus serviços de usuário registram.

Há algo rolando em alta velocidade? Se não, bem, então não há nada novo registrado. Se sim, esse é o problema, não o seu sistema de registro! (Não atire no mensageiro.)

Se muita coisa estiver acontecendo ao mesmo tempo, é possível obter algumas estatísticas sobre o que foi registrado e quantas mensagens foram registradas desde a última inicialização

journalctl -b0 --output=cat --output-fields=UNIT | sort | uniq --count | sort -n 

Na linha de comando que você já reconhece -b0como "esta inicialização atual", --output=catdiz journalctlpara gerar texto não formatado e --output-fields=UNITdiz para gerar somente a unidade que está registrando a mensagem (não a mensagem, não o registro de data e hora, etc.), sortclassifica as coisas em ordem alfabética, uniq -cpega a entrada classificada e imprime a contagem de linhas idênticas consecutivas e, por fim, sort -nclassifica a saída numericamente.

Devo me preocupar com meu disco de sistema SSD?

Não sei te dizer. Mas meus SSDs são classificados para um volume de gravação de 3 Petabytes (tempo médio até falha), então, supondo que você tenha um menor com memória de qualidade inferior, digamos, ele é classificado para 0,5 PB MTTF. Isso significa que a 16 MB/h,

0,5·10¹⁵ B / (16·10⁶ B/h) = 31250000 h = 3567,4 a;

em outras palavras, se você tivesse 1000 discos passando exatamente por essa carga de gravação, depois de 3567 anos, 500 teriam falhado.

Você tem um disco. Você precisaria assumir um modelo estatístico para quando os discos rígidos falham (obviamente, eles não falham todos no mesmo segundo em 3567 anos. Alguns falharão antes, outros depois; a questão é a *distribuição disso), que ninguém sabe (um fabricante de SSDs para data center pode compartilhar suas estatísticas com seus clientes de alto perfil; o próprio Google terá estatísticas suficientes para estimar isso. Simplesmente não temos como saber).

Um modelo estatístico comum para falhas de dispositivos é um modelo exponencial (uma lâmpada não pode falhar duas vezes). Isso não pode ser correto aqui em detalhes (devido ao nivelamento do desgaste, que necessariamente transforma o modelo de falha das células de flash individuais), mas é um ponto de partida. Ele tem uma função de distribuição cumulativa:

F ( t , λ ) = 1 - e ^{- λt} ,

onde t é o tempo e λ é a taxa , que ainda não sabemos.

Mas o que significa "tempo médio até a falha"?

F ( t _MTTF , λ ) = 0,5,

então (log sendo o logaritmo natural)

      0,5 = 1 - e ^{- λt _MTTF}
      0,5 = e ^{- λt _MTTF}
log 0,5 = log e ^{- λt _MTTF}
            = - λt _MTTF · log e
            = - λt _MTTF ,

produzindo a percepção de que

λ = - log 0,5 / t _MTTF ,

e no nosso caso,

λ = - 0,693147 / 3567,4 [1/a] = 0,00019430 / a.

Que, inserido na função de densidade cumulativa original,

F ( t ) = 1 - e ^{-0,00019430· t} ,

significa que após uma vida útil realista de t = 15 anos, seu SSD ainda estaria funcionando com uma probabilidade de 0,99709; em outras palavras, se seu SSD de baixa qualidade não fizesse nada além de gravar logs nessa taxa, você o perderia para carga de gravação dentro de 15 anos com uma probabilidade de 3 em 1000.

Você está bem.

Não é um problema systemd-journald, mas algo está registrando tanto. Verifique o que está nos logs:

journalctl -xef

Se você não precisar desses logs, tente descartá-los antes de enviá-los para o diário.

Se você não precisar dos seus logs após uma reinicialização, você pode adicioná Storage=volatil-los /etc/systemd/journald.confe reiniciar o diário: systemctl restart systemd-journald.