Snapd一直运行，导致jbd2/sda2-8访问磁盘无读写，消耗大量io和系统负载

Question

我正在体验 jbd2/sda2-8 的高 io 使用率，而我什么都不做。

问题是我没有运行性能密集型程序，但系统负载仍然很高。其实正常负荷在0.05以下，但从昨天开始一直高于1.5。经过一段时间的挖掘，我认为是jbd2/sda2-8的io使用导致了问题。

后来我去了PC所在的房间，发现硬盘的LED灯一直闪烁，可能一秒钟内闪烁很多次。这意味着io使用确实是一个问题。

在这里，https ://www.webhostingtalk.com/showthread.php?t=1148545 ，它告诉我 jbd2 不是根本原因，我必须找出哪个程序真正在写入或读取磁盘。所以我发现真正的原因是snapd。

我尝试暂时停止 snapd 服务，负载立即下降。

这是在旧 PC 上运行的 Ubuntu Server 20.04。以下是系统总结：

OS: Ubuntu 20.04 focal
Kernel: x86_64 Linux 5.4.0-33-generic
Uptime: 12h 8m
Packages: 985
Shell: bash 5.0.16
Disk: 11G / 231G (5%)
CPU: Intel Core2 Duo E8600 @ 2x 3.336GHz
GPU: GeForce 9300 GE
RAM: 766MiB / 3935MiB

你可以看到它是一个双核cpu，所以负载1.5真的很高。

这是iotop的反馈

Total DISK READ:         0.00 B/s | Total DISK WRITE:       844.51 K/s
Current DISK READ:       0.00 B/s | Current DISK WRITE:    1643.16 K/s
    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
    306 be/3 root        0.00 B/s    0.00 B/s  0.00 % 69.00 % [jbd2/sda2-8]
    972 be/4 root        0.00 B/s  324.81 K/s  0.00 %  0.15 % snapd
    919 be/4 root        0.00 B/s  259.85 K/s  0.00 %  0.12 % snapd
    926 be/4 root        0.00 B/s  259.85 K/s  0.00 %  0.12 % snapd
      1 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % init maybe-ubiquity
      2 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kthreadd]
      3 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_gp]
      4 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_par_gp]
      6 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/0:0H-kblockd]
      8 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [mm_percpu_wq]
      9 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/0]
     10 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_sched]
     11 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/0]
     12 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [idle_inject/0]
     14 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [cpuhp/0]
     15 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [cpuhp/1]
     16 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [idle_inject/1]
     17 rt/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [migration/1]
     18 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [ksoftirqd/1]
     20 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/1:0H-kblockd]
     21 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kdevtmpfs]
     22 be/0 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [netns]
     23 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [rcu_tasks_kthre]
     24 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kauditd]
     26 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [khungtaskd]
  keys:  any: refresh  q: quit  i: ionice  o: active  p: procs  a: accum                                                  
  sort:  r: asc  left: SWAPIN  right: COMMAND  home: TID  end: COMMAND                                                  

jbd2/sda2-8 使用 69.00% 的 io 但速度为零，就像之前提到的一些问题一样。但这里的区别在于我什么都不做，我不知道是哪个程序导致了问题。最近我没有对软件进行大的改动。我所做的唯一更改是我安装了然后卸载了 vsftpd。

我试过的

我一直在网上寻找解决方案，我找到了以下方法并尝试了其中的大部分：

1. 更新内核。由于我使用的是最新的操作系统，因此我认为没有必要。
2. 更改磁盘的提交频率。我很害怕，并没有对其进行更改。
3. 重启。重启后问题依旧。
4. 更改mysql的配置。我认为 mysql 不是原因，因为我的数据库很小。我关闭了 mysql，负载立即下降到 1.2，然后又上升到 1.6。
5. 查找那些异常大的日志并找出发生了什么。我发现auth.log非常大并且继续膨胀。我发现有人通过 ssh 猜测我的 root 密码来攻击我的服务器。真的让我很震惊。来自大量 IP 地址的大量请求！幸运的是，我拒绝了 root 的远程登录。我向我的 ISP 请求了一个新的 IP 地址并阻止了攻击。
6. 在我的磁盘上运行智能检查。检查通过，我的磁盘状况良好。
7. 检查磁盘使用情况。你可以从上面看到有足够的空间。

现在我已经通过停止 snapd 服务暂时解决了这个问题

就这样。那么 snapd 有什么问题，我现在应该怎么做？

Answer 1

我卸载了 snapd，问题解决了。