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

Posted 2023-03-16

技术标签:

【中文标题】Snapd一直运行，导致jbd2/sda2-8无读写访问磁盘，消耗大量io和系统负载【英文标题】：Snapd keeps running, causing jbd2/sda2-8 accessing the disk with no read or write, consuming lots of io and system load 【发布时间】：2020-09-25 08:14:34 【问题描述】：

当我什么都不做时，jbd2/sda2-8 的 io 使用率很高。

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

后来我去了电脑所在的房间，发现硬盘的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。

我尝试过的

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

mysql

负载立即降到 1.2，然后又升到 1.6

auth.log

有人通过 ssh 猜测我的 root 密码来攻击我的服务器

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

就是这样。那么 snapd 有什么问题，我现在该怎么办呢？

【问题讨论】：

我认为这会有所帮助：serverfault.com/questions/450611/…. 我以前看过那个页面。我只使用了一个磁盘，根本没有raid，而且我的磁盘状况良好。像ningx这样的进程也有消耗io，所以对我没有帮助。嗨 @sffred 欢迎来到 SO，您可以在此处查看此链接 linuxquestions.org/questions/linux-software-2/… 是的，我也检查了日志，现在我已经完全关闭了我的 ipv4 端口到公共网络，问题仍然存在。正如我上面提到的，我在问这个问题之前尝试过这个。我在 Ubuntu 19 上确认了这个问题——它已经把我吓坏了！我现在在系统启动后冥想了大约 45 分钟，等待 snap 完成一些“非常重要的工作”，将千兆字节的垃圾（主要是浏览器缓存）从 ~/snap 的一个子文件夹移动到另一个。 【参考方案1】：

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

【讨论】：

如何从 Ubuntu 中删除 snap 存储？ askubuntu.com/questions/1035915/…【参考方案2】：

我也有同样的问题，我的系统是刚安装的ubuntu 20.04。我通过中止正在运行的 snapd 作业修复了它。

找出正在运行的作业快速更改

这会给你一个工作编号 X

中止工作

快速中止 X

在 snap 中禁用 gtk 方案

快速禁用 ....

似乎只有某种强大的防火墙或其他东西背后的人会遇到这个问题。

【讨论】：