这个需要 Linux/Ubuntu 专家。
失控程序在 /var/log 中生成了大量（至少一百万？）文件。即使删除了所有（？）恶意文件，现在对文件夹/树的任何查询都需要大约 5 分钟，并且可能导致整个系统运行缓慢。
问题是 logrotate 创建的 .gz 文件被添加到其他 .gz 存档中，而这些存档正在被存档，然后……哎呀。因此，所有无效的 .gz 文件都已从 /var/log 中删除 - 源问题已得到修复。
我怎样才能准确找出造成延误的原因？
- /var/log 树中有 75 个目录，包含 1606 个文件，仅消耗 1GB。
ls /var/log需要5分钟以上的时间来处理。ls其他较大的文件夹树使用、、等进行查询所需的时间要少得多find。greptree/var/log 也需要大约 5 分钟，结果是一个完全正常的文件夹/文件树。df -i显示总共有 1000 万个 inode，其中已使用的不到 100 万个，未使用的有 900 多万个。系统已重启多次。
我会同意rm -rf整个日志树，然后重新启动。mv或者cp移动到不同的文件夹，“重置”，然后把所有东西都移回去，我担心我只是把问题从一个地方复制到了另一个地方。
我想知道我们是否可以扫描/清除损坏的 inode，或者是否有助于将 inode 数量减少到最低限度，然后在重新启动后将其重新启动。
这是一个简单的安装，/var 位于唯一的 /root 分区中，用于存放 OS/数据。因此无法卸载/替换。
我可以轻松运行诊断并提供相关信息。
这是一个完全修补的 v20.04.3 云服务器。如果需要，我可以打开控制台。
e4defrag没有显示碎片。如果建议，可以运行fsck（e2fsck或）。这些是我正在寻求的帮助诊断此类问题的实用程序类型的示例。shutdown -rF
10 个月后编辑：仍然需要帮助来诊断这个持续存在的问题。
- 我现在有两个系统由于相同的恶意脚本而处于类似的状态，现在已永久修复。
- 内存没有压力：已用 RAM/总计=2/4GB，已添加交换空间，1/4GB
- /var/log 上不带“.”的 ls 文件夹显示 48k 个块，但“ls -la”显示超过 800 个块，“.”别名显示 750MB
du/var/log 显示大约 1.2GB，与 --apparent-size 差别很小。- 正如预期的那样，姓名的自动完成也明显延迟。
- 除了少数大小达 80M 的普通“日志”文件外，没有异常大的文件。
- 连续访问多个目录后，速度会快得多。这似乎表明缓存。在此期间，RAM/Swap 使用率没有太大变化。
每隔几天，该系统就会发出一次锁定警告：
内核 [0.0] 看门狗：BUG：软锁定 - CPU#1 卡住 59 秒！[进程：0]
有时这将强制断开/终止卡住的任何随机进程。
由于这些问题，我计划重新安装，就像我们每隔几年需要对 Windows 进行的操作一样。但我真的很想知道如何诊断这些问题……并在这里进行诊断，以便每个人都能了解其工作原理。