Ce comportement de journald n'est en effet pas sympa, mais quelle quantité de logs a-t-il eu à traiter en entrée pour en arriver à une telle extrémité ? Une quantité "normale", disons jusqu'à quelques dizaines de lignes de syslog par seconde, auquel cas le paramétrage par défaut est totalement inadéquat / journald est buggé jusqu'à la moelle pour ne pas avoir respecté le paramétrage, ou bien une quantité excessive, suffisante pour ralentir l'exécution de la machine (milliers de lignes par seconde) ?
L'info m'intéresse, car j'ai déjà vu des machines ralenties par le logging complet des opérations effectuées dans un chroot (avec un kernel systemd), sur des Debian, ou plus proche de ta config, par l'Advanced Error Reporting du bus PCI-Express sur une machine qui fait en permanence beaucoup d'erreurs corrigées, et qui tournait à l'époque Fedora 29 ou 30. Et cette dernière machine ayant 32 GB de RAM, je peux avoir raté une consommation excessive de RAM par journald.

Chez nous, c'est plutôt le pro-virus corporate, propriétaire et géré par une entité connue pour des liens avec le gouvernement d'un pays hostile, dont les binaires en code natif manquent gravement des mitigations devenues standard (mais ça s'explique en partie parce les chaînes d'identification compilo suggèrent que cette saloperie a été compilée en partie avec GCC 3.3 et 3.4...), qui fait du DoS sur les machines à cause de consommation excessive de RAM + swap (14 GB sur une machine équipée de 16 GB ? No problem !) et/ou création du nombre de processus seulement bornée par la limite du système (5K processus par défaut). Du coup on met parfois des cronjobs qui font un killall de certains processus du pro-virus, sur les machines qui ont été infectées avec cette merde...