V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
请不要把任何和邀请码有关的内容发到 NAS 节点。

邀请码相关的内容请使用 /go/in 节点。

如果没有发送到 /go/in,那么会被移动到 /go/pointless 同时账号会被降权。如果持续触发这样的移动,会导致账号被禁用。
qpwo005451mark2
V2EX  ›  NAS

求救 PVE ZFS 概率出现崩溃

  •  
  •   qpwo005451mark2 · 2023-05-30 17:17:06 +08:00 · 2329 次点击
    这是一个创建于 543 天前的主题,其中的信息可能已经有所发展或是发生改变。
    机器是自己组的 ALL IN BOOM ,平台是 I5 12400+B660 ,目前在家里,平常在同城异地上班

    PVE 系统采用 ZFS mirror 安装在两块致钛的 SATA 固态上(安装于主板自带的 SATA 控制器),大部分 VM 的系统盘安装在 SATA 上,NAS 系统选用的是 unraid ,阵列卡和 2 块 NVME 固态直通给了 unraid 。

    PVE 的 VM 和 LXC 容器提供服务,unraid ( unraid 上自己也跑了一些 docker )通过 NFS/SMB 方式对一些服务提供存储

    其中一台 VM 运行的是 windows11 ,核显 SR-IOV 直通给 win11 虚拟机上班的时候通过远程串流玩玩舰娘+安卓模拟器,24h 运行,目前问题是最近 PVE 的 ZFS 文件系统有概率崩溃(多次和 win11 这台虚拟机里的读写操作有关,比如启动 win11 里的安卓模拟器,但是故障没法稳定复现),具体情况是 CPU 占用率低,但是 DISK IO 、IO wait 、服务器负载巨高,所有 VM 和 LXC 容器只要是在 zpool 上的基本失去响应。看起来就像 SATA 控制器被占满了一样,iosata 结果也是这样,但是 htop/iotop 在后台看不到任何读高写的进程,并且情况会逐渐恶化,最后就是 PVE 控制台也崩溃,SSH 可以进去但是运行 htop 后也不会有响应,严重到最后甚至 SSH 也无法远程登录,一般我在 ssh 还能登录的时候就选择把 unraid 数据保存以后 reboot 之后服务会恢复正常。

    zpool 看起来也没问题,两块致钛的 SATA 固态 smart 也没问题,这属于 PVE ZFS 的 BUG 吗?

    因为目前人在异地,周末才能回去,基本属于 all in boom 的状态了,但是 unraid 因为是 U 盘直通的系统,PVE 控制台崩溃了也不受影响,还能正常运行,今天又复现了这个问题,目前在 PVE 控制台崩溃前把 win11 VM 磁盘转移到了 unraid 直通的两块 NVME 上,目前和 unraid 一样可以正常运行。
    https://upload.cc/i1/2023/05/30/vVfmaI.png
    https://upload.cc/i1/2023/05/30/sfr6Bn.png
    https://upload.cc/i1/2023/05/30/wF95ZD.png
    https://upload.cc/i1/2023/05/30/1ViGXY.png
    https://upload.cc/i1/2023/05/30/s2KlHD.png
    17 条回复    2023-06-13 14:19:36 +08:00
    happyn
        1
    happyn  
       2023-05-30 17:29:40 +08:00
    我也碰过类似的问题,当时的环境是:
    PVE7.1
    内核:5.13.19-6-pve
    zfs-2.1.6-pve1
    zfs-kmod-2.1.4-pve1

    三块日立 12T 做了 RaidZ1 ;刚开始用的一切都好,但是就过了一个来月,发现跟老哥一样的问题;中间各种排查各种折腾,把 zfs 的手册翻了一个遍;最后发现神奇的是电源问题,只要 IO 一上来,电源就有一个峰值,散热不好风扇呼呼吹;

    后来换了个电源可以了.....
    happyn
        2
    happyn  
       2023-05-30 17:33:56 +08:00
    老哥回去以后可以注意一下电源输出,没有仪器的话可以人肉看看电源风扇;

    我的环境当时表现是硬盘咔咔响,比常见的炒豆子声还要大好多,电源风扇直接起飞;

    这个时候 zpool 的性能惨不忍睹,拷贝文件都 <10MB/s 了...,iostat 看占用都 100%;

    不过神奇的是,同样的电源,我换了 PVE 默认的 LVM thinpool 卷管理之后,就一点问题都没有了;
    qpwo005451mark2
        3
    qpwo005451mark2  
    OP
       2023-05-30 17:44:37 +08:00 via Android
    @happyn 有可能,电源是机箱自带的服务器单电 1200w (二手不知道工况),两块 sata 都是从机箱里给的大 4pin 取电的,用的一分二的供电线,看来线或者电源都可能有问题?不过之前其实也稳定运行了 60 几天了,然后接入了后背式 ups ,机箱不太想换了,感觉只能放弃 pve 使用 zfs 了
    qpwo005451mark2
        4
    qpwo005451mark2  
    OP
       2023-05-30 17:47:23 +08:00 via Android
    @happyn 感谢了,之前没有考虑过这方面的可能性,回去排插了,看来捡垃圾中奖了
    dode
        5
    dode  
       2023-05-30 22:25:07 +08:00
    支持限制 win11 硬盘 IO 吗
    sNullp
        6
    sNullp  
       2023-05-31 03:10:30 +08:00
    另外如果开了 dedup 且内存不够也会这样
    busier
        7
    busier  
       2023-05-31 07:36:36 +08:00 via iPhone
    虽然没踩这个坑,但是也刚换了电源,原因是最近总出现硬盘开机不识别,插拔线折腾下又好了,偶尔硬盘还哒哒响,C5C6 错误数上涨,硬盘经常被 Linux 给 remount 成 ro 。一顿排查就是电源毛病!
    qpwo005451mark2
        8
    qpwo005451mark2  
    OP
       2023-05-31 08:38:23 +08:00
    @sNullp PVE 的 ZFS pool 默认是不开 dedup 的吧,内存不够确实会这样,我刚开始折腾才发现 PVE 的 ZFS 非常坑,默认 L2 ARC 设置的是一半内存,开 VM 直通硬件就容易出现过内存不够机器跑 4-5 天固定直接 ZFS 直接卡死,后面限制过了使用 4G ,就稳定了好久,然后最近又莫名其妙发病了。
    qpwo005451mark2
        9
    qpwo005451mark2  
    OP
       2023-05-31 08:46:31 +08:00
    @dode 但是不可避免的总会进行读写,windows 使用还是比较频繁的,安卓模拟器使用总会进行大量的读写。目前决定 win11 存储由 unraid 来提供,zpool 尽量不去碰了。
    anguliuyun
        10
    anguliuyun  
       2023-05-31 09:02:00 +08:00
    问题类似:
    anguliuyun
        11
    anguliuyun  
       2023-05-31 09:07:37 +08:00
    @anguliuyun

    pve-manager/7.3-3/c3928077 (running kernel: 5.15.74-1-pve)

    两块希捷库狼的 zmirror, 不过我只用他做存储服务, 还有两块 m2 固态做系统盘。
    IO 上来的时候会有一块硬盘断掉,内核报错 ata offline , 不知是不是上面提到的电源问题
    anguliuyun
        12
    anguliuyun  
       2023-05-31 09:14:05 +08:00
    @qpwo005451mark2 问下 OP 你的核显直通 win11 有 hdmi 输出吗, 我的 10 代 i5 核显 UHD630 能直通到 win11 ,正常安装驱动以及核显加速能生效, 但是 hdmi 无信号。
    qpwo005451mark2
        13
    qpwo005451mark2  
    OP
       2023-05-31 10:37:23 +08:00   ❤️ 1
    @anguliuyun hdmi 输出不好意思不太清楚,因为我是 12 代使用的是 SR-IOV 虚拟化,是没有 HDMI 输出的,所以我是通过 parsec/moon light 这种串流的形式远程使用,因为我确实也不需要 hdmi 输出所以没有特地研究过
    sNullp
        14
    sNullp  
       2023-05-31 10:40:04 +08:00
    @qpwo005451mark2 默认是不开 dedup 的,但也可以看一下。我感觉 l2 arc 的内存很容易 evict 掉其实不怎么影响系统,但是 dedup 吃不够内存就巨卡。
    zx900930
        15
    zx900930  
       2023-05-31 11:14:39 +08:00
    FS readonly 还有一个可能是 RAM 问题
    你可以去下一个 memtest86+的 iso, 让你的虚拟机从 iso 启动跑一个 pass 就差不多知道 RAM 有没有问题了.

    我最近出现的也是随机 crash.... 最后发现是 我的 4x16G 内存条跑 memtest86+会 failed.
    但是实际上 RAM 并没有物理损坏, 而是因为 intel 12 代不带 k 的 cpu 锁了内存控制器电压, 导致 4 根 RAM 插满开 xmp 的时候, 偶尔电压不够导致内存工作异常得完全断电重启 PVE......
    anguliuyun
        16
    anguliuyun  
       2023-05-31 12:21:42 +08:00
    @qpwo005451mark2 感谢回复,串流确实可以使用,我是因为核显的串流性能差所以想试试 hdmi 直接显示这种方式。
    qpwo005451mark2
        17
    qpwo005451mark2  
    OP
       2023-06-13 14:19:36 +08:00
    这边更新一下处理结果,回去之后在 ssh shell 中使用 reboot 无法关机,使用 reboot -nf 强制重启后无法重启系统,因为是 all in boom 机器,接上显示器后显示系统启动卡在 zfs 文件系统 rpool 加载的过程中,内核识别到了 rpool 并且进行加载,出现了一连串错误没有办法继续下去,每个 40s 刷新一下进度但是报错依旧,基本就是卡在系统的启动阶段,随将 PVE 系统更换为传统的 LVM 逻辑区的安装方式,导入 U 盘引导的 unraid 存储底层虚拟机后再重新将各虚拟机的备份导入,到目前为止系统稳定没有出现报错,后续继续观察是否会有类似故障出现

    另外我只能分析出是某些原因导致(不清楚是硬件 /软件 /不过可以确定和 ZFS 有关)原因导致的系统日志进程报错,并且产生了大量 systemd-journald.service 子进程,HTOP 中看为上千个左右,并且为表示进程状态为 "Disk Sleep",大量 systemd-journald.service 进程造成了 DISK IO 出现无读写无负载但是 IO some 和 IO Full 100%卡死的状态,只是不知道这是原因还是硬件报错以后造成的后果

    PVE 系统日志报错情况,显示 systemd-journald.service: Watchdog timeout 看门狗超时
    Jun 05 06:37:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    Jun 05 07:18:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    Jun 05 07:47:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    Jun 05 08:17:51 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    Jun 05 08:48:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    Jun 05 09:17:11 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    Jun 05 09:47:51 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    Jun 05 10:18:01 pve systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
    很多都是一样的....

    systemctl status systemd-journald.service 结果
    ● systemd-journald.service - Journal Service
    Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
    Active: deactivating (final-sigterm) (Result: timeout) since Mon 2023-06-05 20:47:11 CST; 3 days ago
    TriggeredBy: ● systemd-journald-dev-log.socket
    ● systemd-journald.socket
    ● systemd-journald-audit.socket
    Docs: man:systemd-journald.service(8)
    man:journald.conf(5)
    Main PID: 774005 (systemd-journal)
    Tasks: 673 (limit: 76751)
    Memory: 750.2M
    CPU: 17ms
    CGroup: /system.slice/systemd-journald.service
    ├─595309 /lib/systemd/systemd-journald
    ├─623455 /lib/systemd/systemd-journald
    ├─630728 /lib/systemd/systemd-journald
    ├─638521 /lib/systemd/systemd-journald
    ├─646418 /lib/systemd/systemd-journald
    ├─653880 /lib/systemd/systemd-journald
    ├─660401 /lib/systemd/systemd-journald
    ├─665886 /lib/systemd/systemd-journald
    ├─671968 /lib/systemd/systemd-journald
    ├─676206 /lib/systemd/systemd-journald
    ├─678308 /lib/systemd/systemd-journald
    ├─680379 /lib/systemd/systemd-journald
    ├─682449 /lib/systemd/systemd-journald
    ├─684574 /lib/systemd/systemd-journald
    ├─686661 /lib/systemd/systemd-journald
    ├─688812 /lib/systemd/systemd-journald
    ├─690917 /lib/systemd/systemd-journald
    ├─693026 /lib/systemd/systemd-journald
    ├─695087 /lib/systemd/systemd-journald
    ├─697191 /lib/systemd/systemd-journald
    ├─699286 /lib/systemd/systemd-journald
    ├─701796 /lib/systemd/systemd-journald
    非常长下面全是 /lib/systemd/systemd-journald 子进程

    重装前顺便跑了 memtest ,没有跑了一晚上没有发现问题...所以目前只能怀疑 ZFS 加我的硬件造成了系统崩溃,因为已经不使用 ZFS.加上本人也不是 linux 专业,所以也无法深究原因了。
    系统备份方面最后也还是使用了传统的 dd 备份整个分区到另一硬盘的方式,并且目前个人感觉家用环境 PVE 宿主机系统备份意义貌似也不是很大,因为也不需要严格保证服务不中断,把所有的虚拟机进行备份之后即使宿主机系统出现故障,重装 PVE 后把所有的虚拟机通过之前的备份就可以快速导入。所以之前 pve 系统安装时使用 zfs mirror 仅仅是看起来很美好,最后发现 zpool 反而是最容易出问题的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   912 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 21:53 · PVG 05:53 · LAX 13:53 · JFK 16:53
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.