求救 PVE ZFS 概率出现崩溃 - V2EX
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 3077 次点击
    这是一个创建于 863 天前的主题,其中的信息可能已经有所发展或是发生改变。
    机器是自己组的 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 尽量不去碰了。
    linkzz
        10
    linkzz  
       2023-05-31 09:02:00 +08:00
    问题类似:
    linkzz
        11
    linkzz  
       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 , 不知是不是上面提到的电源问题
    linkzz
        12
    linkzz  
       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......
    linkzz
        16
    linkzz  
       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     Solana     1144 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 36ms UTC 23:25 PVG 07:25 LAX 16:25 JFK 19:25
    Do have faith in what you're doing.
    ubao snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86