I am experiencing a complete system management lockup (WebUI and SSH unresponsive) during high-speed downloads via SABnzbd/NZBGet. The system remains in this "flatline" state for the duration of the download, though the downloads often complete in the background.

This setup was stable for over 20TB of traffic and recently started failing consistently.

I have tested downloading directly to RAM by mapping /tmp to the container. The freeze still occurs immediately. This rules out my ZFS pool and NVMe SSDs as the cause. The issue is strictly related to high-speed network throughput and how the system handles the load.

System Specs:

• CPU: Intel i5-12400

• Motherboard: Biostar B760MX2-E PRO D4 (BIOS C-States still on Auto)

• RAM: 48GB

• NIC: Onboard Realtek RTL8125 2.5GbE

• Storage: ZFS Stripe (Samsung 970 512GB + Corsair MP510 256GB)

• Unraid Version: 7.2.2

What I have already tried:

1. RAM Download Test: Mapped /tmp to /ramdownload in Docker. Freeze happens regardless of disk I/O.

2. Drivers: Installed the "Realtek RTL8125" out-of-tree driver plugin (verified loaded via lsmod).

3. Networking: Switched from macvlan to ipvlan.

4. Docker Config: Moved all paths to /mnt/cache/ (bypass FUSE) and pinned CPUs to keep Cores 0 & 1 free.

5. App Switch: Same behavior on both SABnzbd and NZBGet.

Observations: It seems like a massive "Interrupt Storm" is hitting Core 0, making the management layer (nginx/ssh) unresponsive, even though the actual download process (on pinned cores) continues to work.

root@SERVERDEONER2:~# zpool status -v cache
  pool: cache
 state: ONLINE
config:

        NAME                                     STATE     READ WRITE CKSUM
        cache                                    ONLINE       0     0     0
          nvme0n1p1                              ONLINE       0     0     0
          nvme-Force_MP510_19428205000127695377  ONLINE       0     0     0

errors: No known data errors
root@SERVERDEONER2:~#

root@SERVERDEONER2:~# mount | grep cache
cache on /mnt/cache type zfs (rw,relatime,xattr,posixacl,casesensitive)
cache/system on /mnt/cache/system type zfs (rw,relatime,xattr,posixacl,casesensitive)
cache/domains on /mnt/cache/domains type zfs (rw,relatime,xattr,posixacl,casesensitive)
cache/isos on /mnt/cache/isos type zfs (rw,relatime,xattr,posixacl,casesensitive)
cache/appdata on /mnt/cache/appdata type zfs (rw,relatime,xattr,posixacl,casesensitive)
cache/data on /mnt/cache/data type zfs (rw,relatime,xattr,posixacl,casesensitive)
cache/domains/HomeAssistant on /mnt/cache/domains/HomeAssistant type zfs (rw,relatime,xattr,posixacl,casesensitive)
/mnt/cache/system/docker/docker.img on /var/lib/docker type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/)
/mnt/cache/system/docker/docker.img on /var/lib/docker/btrfs type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/)
/mnt/cache/system/libvirt/libvirt.img on /etc/libvirt type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/)
root@SERVERDEONER2:~#

root@SERVERDEONER2:~# modinfo r8125 | grep version
version:        9.016.01-NAPI-RSS
srcversion:     BA104C0510886D056381E52
root@SERVERDEONER2:~#

serverdeoner2-diagnostics-20260123-1200.zip

FIXED

Status: Solved The Fix: Replaced a faulty Ethernet cable between the 16-port switch (where the server is connected) and the MikroTik router. The Discovery: The server was connected to a 16-port switch. Everything seemed fine, but I noticed the link between this switch and the main MikroTik router had dropped to 100Mbps and was likely producing massive CRC errors. Even though the server's local connection was Gigabit, the "bottlenecked" and faulty uplink to the router caused the system to choke.

Technical Summary for others: If your server freezes under load, check the entire chain of cables. A faulty uplink cable between switches can cause "Backpressure" and an "Interrupt Storm" on Core 0 of your Unraid server. The NIC driver struggles to handle the congestion and packet loss, leading to a complete UI lockup while the CPU is busy managing the network chaos.

Key Optimizations that stayed:

• ipvlan instead of macvlan.

• Realtek r8125 OOT Driver.

• Direct Cache Paths (/mnt/cache/) to bypass FUSE.

• CPU Pinning (keeping Cores 0 & 1 for the OS).

1 hour ago, deoner said:

1. Networking: Switched from macvlan to ipvlan.

2. Docker Config: Moved all paths to /mnt/cache/ (bypass FUSE) and pinned CPUs to keep Cores 0 & 1 free.

Regarding these few things. The macvlan issue was resolved on unraid not too long after it became an issue. No real need to use either over the other.I prefer macvlan)

The 2nd thing is that unraid introduced "exclusive shares" which bypasses FUSE for shares that reside on a single array disk or pool. This can be enabled in the global settings.

Lastly, unraid no longer prioritizes the core/thread 0/1 anymore it will just use whatever core/threads are most free. Pinning is probably doing more hard than good in this instance, I understand you were troubleshooting.