Large file sync to Nextcloud in VM causes Proxmox 100% CPU load, Load Average over 50, sometimes unexpected restart of host

logan893

Member
Mar 23, 2022
15
0
6
Host is a 4-core Xeon (no HT) with 64GB RAM, ZFS mirror for local VM storage (2x Intel SSD DC S3520 1.6TB), and an Intel 2-port X540 10Gbase-T NIC plus onboard 2x1G.
I run a TrueNAS VM with HBA passthrough for storing photos, and Nextcloud in its own VM (with storage directly in TrueNAS) to easily synchronize photos from my client PC.

Proxmox VE 8.1.3
Nextcloud in an Ubuntu 22 VM using virtio network device.
TrueNAS Core in a VM using virtio network device.
pfSense in a VM using virtio network devices.

My client PC is connected directly using a 2.5G NIC to one of the 10G ports on the server NIC, at 1G interface speed (I previously had a Proxmox server-side change to allow for 2.5G speeds but it seems to have fallen off of the server).

Nextcloud and TrueNAS are on the same subnet with direct access to each other and the storage I upload files to in Nextcloud is a network device so files end up directly on the TrueNAS HDDs. Traffic between the client PC and the VM network flows via the pfSense router.

The system typically runs smoothly, with CPU usage around 20-30%, load average in the 1-1.5 range. Low level of network traffic. Most of the idle CPU usage comes from a Windows VM with 2 vCPUs that the Proxmox GUI tells me is idle at less than 30% CPU load.

Now to the problem.

When I synchronize a large batch of photos, and without any speed limit imposed from the Nextcloud client, I reach speeds of roughly 25-30 MB/s on average, with spikes around 50 MB/s. According to the Proxmox GUI, the Nextcloud VM which is currently allocated 3 vCPUs (I know this is high) and hits 50-55% CPU usage levels, the TrueNAS VM with 2 vCPUs hits around 30-30% CPU usage at the peak (typically idle at 2-4%), and the pfSense VM with two vCPUs also hits roughly 30-35% (typically idle at 4-5%). The other VMs are not seeing any spikes in CPU usage during this time.

CPU usage of the Proxmox host approaches 100%, and more notably the load average creeps up into the 50s!

Sometimes with a large batch of photos, where the sync runs for many minutes and unthrottled, the Proxmox server can quickly become unstable and unresponsive. It has even suffered automatic restarts which I suspect are watchdog related, if the behavior is the same as I see for partial service interruptions, but I do not have observational data from all the times it has happened and the logging is often incomplete or stopped prior to restarts.

I truly don't understand how the load average can exponentially explode up over 50 like this.

Lowering the Nextcloud VM "cpuunits" from default (100) to 25 seems to help during the brief testing I could do today, but it was perhaps too short. I will from next reboot of the Nextcloud VM also reduce the vCPUs from 3 to 2, perhaps that will at least help a bit.

Any ideas what this extreme load average comes from, or what I should monitor if I were to attempt to reproduce this in a controlled way?
Could there be some networking/NIC related settings that I need to change, on the host or for/in VMs?
 
I've dropped the number of CPU cores to 2 and set cpuunits=20. Mostly the system is running smoother with this. However, I still experienced a system load storm when performing an upgrade of Nextcloud today. During the pre-upgrade backup, everything seemed smooth. Once the mastercontainer was updated, I hit the "start and update" all other containers, and that is when this high load happened.

This time, load average spiked for over 2 minutes, to a high of 65.72 at 13:52 according to the server GUI, and CPU utilization was up around 100%. At least the system did not crash this time, but during these two minutes many of my open network connections to VMs were closed (SSH sessions).

I was keeping an eye on some stats from my SSH connection to the proxmox host itself (the SSH session went down while I had atop running), and noticed that the high load appears to stem from all the "zvol" processes. Looking into this a bit further, the number of threads by default is 32, acting like a kind of queue depth (but the parameter according to arc_summary is set to 0).

I have the final output from atop before the SSH session disconnected (the 1m load average was already at 52.38 here). Full system load (sys at 400% for a 4-core CPU).

code_language.shell:
ATOP - pvehost                            2025/09/02  13:51:42                             -----------------                             10s elapsed
PRC | sys   39.54s  | user   0.04s  | #proc    300  | #trun    115  | #tslpi   323 |  #tslpu    72 |  #zombie    0 |  clones     3 |  #exit      2 |
CPU | sys     400%  | user      0%  | irq       0%  | idle      0%  | wait      0% |  ipc     0.29 |  cycl 3.29GHz |  curf 3.30GHz |  curscal  94% |
cpu | sys     100%  | user      0%  | irq       0%  | idle      0%  | cpu000 w  0% |  ipc     0.29 |  cycl 3.29GHz |  curf 3.30GHz |  curscal  94% |
cpu | sys     100%  | user      0%  | irq       0%  | idle      0%  | cpu001 w  0% |  ipc     0.29 |  cycl 3.29GHz |  curf 3.30GHz |  curscal  94% |
cpu | sys     100%  | user      0%  | irq       0%  | idle      0%  | cpu002 w  0% |  ipc     0.29 |  cycl 3.29GHz |  curf 3.30GHz |  curscal  94% |
cpu | sys     100%  | user      0%  | irq       0%  | idle      0%  | cpu003 w  0% |  ipc     0.29 |  cycl 3.29GHz |  curf 3.30GHz |  curscal  94% |
CPL | numcpu     4  |               | avg1   52.38  | avg5   17.06  | avg15   7.72 |               |               |  csw     8142 |  intr   13684 |
MEM | tot    62.7G  | free    2.6G  | cache  58.9M  | dirty   0.1M  | buff    0.0M |  slab    3.3G |  slrec  87.2M |  pgtab 101.3M |               |
MEM | numnode    1  |               | shmem  51.4M  | shrss   0.0M  | shswp   0.0M |  tcpsk   0.0M |  udpsk   0.0M |               |  zfarc  23.5G |
SWP | tot     0.0M  | free    0.0M  | swcac   0.0M  |               | ksuse   5.1G |  kssav   6.2G |               |  vmcom  47.1G |  vmlim  31.4G |
PAG | scan   34234  | compact    0  | numamig    0  | migrate   14  | pgin       0 |  pgout   1958 |  swin       0 |  swout      0 |  oomkill    0 |
PSI | cpusome 100%  | memsome 100%  | memfull  99%  | iosome   48%  | iofull    0% |  cs  98/71/30 |  ms  98/64/20 |  mf  97/64/20 |  is   50/26/9 |
DSK |          sda  | busy      0%  | read       0  | write     44  | discrd     0 |  KiB/w     89 |  MBr/s    0.0 |  MBw/s    0.4 |  avio 0.64 ms |
DSK |          sdb  | busy      0%  | read       0  | write     44  | discrd     0 |  KiB/w     89 |  MBr/s    0.0 |  MBw/s    0.4 |  avio 0.64 ms |
NET | transport     | tcpi       5  | tcpo       5  | udpi       0  | udpo       0 |  tcpao      0 |  tcppo      1 |  tcprs      0 |  udpie      5 |
NET | network       | ipi      635  | ipo        5  | ipfrw      0  | deliv     19 |               |               |  icmpi      7 |  icmpo      0 |
NET | eno2      0%  | pcki    1319  | pcko       0  | sp 1000 Mbps  | si  241 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | eno1      0%  | pcki    1103  | pcko       6  | sp 1000 Mbps  | si  138 Kbps |  so    1 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | tap100i ----  | pcki       0  | pcko     144  | sp    0 Mbps  | si    0 Kbps |  so   30 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | vmbr0   ----  | pcki     229  | pcko       6  | sp    0 Mbps  | si   20 Kbps |  so    1 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwpr110 ----  | pcki       0  | pcko     227  | sp    0 Mbps  | si    0 Kbps |  so   21 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwln110 ----  | pcki     227  | pcko       0  | sp    0 Mbps  | si   21 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | veth105 ----  | pcki       0  | pcko     224  | sp    0 Mbps  | si    0 Kbps |  so   21 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwpr105 ----  | pcki       0  | pcko     224  | sp    0 Mbps  | si    0 Kbps |  so   21 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwln105 ----  | pcki     224  | pcko       0  | sp    0 Mbps  | si   21 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwpr104 ----  | pcki       0  | pcko     224  | sp    0 Mbps  | si    0 Kbps |  so   21 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwln104 ----  | pcki     224  | pcko       0  | sp    0 Mbps  | si   21 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwpr114 ----  | pcki       0  | pcko     224  | sp    0 Mbps  | si    0 Kbps |  so   21 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwln114 ----  | pcki     224  | pcko       0  | sp    0 Mbps  | si   21 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwbr110 ----  | pcki     224  | pcko       0  | sp    0 Mbps  | si   18 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwbr105 ----  | pcki     224  | pcko       0  | sp    0 Mbps  | si   18 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwbr104 ----  | pcki     224  | pcko       0  | sp    0 Mbps  | si   18 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | fwbr114 ----  | pcki     224  | pcko       0  | sp    0 Mbps  | si   18 Kbps |  so    0 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | tap101i ----  | pcki       0  | pcko     121  | sp    0 Mbps  | si    0 Kbps |  so   12 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | tap100i ----  | pcki       0  | pcko     113  | sp    0 Mbps  | si    0 Kbps |  so   11 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | tap114i ----  | pcki       0  | pcko      86  | sp    0 Mbps  | si    0 Kbps |  so    9 Kbps |  erri       0 |  erro       0 |  drpo       0 |
NET | tap107i ----  | pcki       0  | pcko      82  | sp    0 Mbps  | si    0 Kbps |  so    7 Kbps |  erri       0 |  erro       0 |  drpo       0 |

Network error: Software caused connection abortELAY   VGROW   RGROW   RDDSK  WRDSK  RUID      EUID      ST  EXC  THR  S  CPUNR   CPU CMD         1/3
 630152 host--------   2.06s   0.00s   7.05s  0.00s      0B      0B      0B   4.0K  root      root      --    -    1  R      3   21% zvol
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 630151 host--------   2.03s   0.00s   7.00s  0.00s      0B      0B      0B 300.0K  root      root      --    -    1  R      3   20% zvol
Session stopped-----   2.03s   0.00s   7.60s  0.00s      0B      0B      0B   4.0K  root      root      --    -    1  R      2   20% zvol
    - Press <return> to exit tab.00s   7.80s  0.00s      0B      0B      0B   4.0K  root      root      --    -    1  R      0   18% zvol
    - Press R to restart session.00s   7.62s  0.00s      0B      0B      0B   4.0K  root      root      --    -    1  R      1   18% zvol
    - Press S to save terminal output to file 0.00s      0B      0B      0B   1.0M  root      root      --    -    1  R      3   18% zvol
    212 host--------   1.75s   0.00s   6.33s  0.00s      0B      0B      0B   1.3M  root      root      --    -    1  R      0   18% zvol
 630150 host--------   1.75s   0.00s   7.40s  0.00s      0B      0B      0B   4.0K  root      root      --    -    1  R      0   18% zvol
 630157 host--------   1.49s   0.00s   8.63s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      2   15% zvol
 630168 host--------   1.49s   0.00s   8.56s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      2   15% zvol
 630146 host--------   1.43s   0.00s   8.15s  0.00s      0B      0B      0B   4.0K  root      root      --    -    1  R      3   14% zvol
 630139 host--------   1.38s   0.00s   8.18s  0.00s      0B      0B      0B 472.0K  root      root      --    -    1  R      3   14% zvol
 630138 host--------   1.36s   0.00s   8.21s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      1   14% zvol
 630162 host--------   1.34s   0.00s   8.72s  0.00s      0B      0B      0B   4.0K  root      root      --    -    1  R      0   13% zvol
 630147 host--------   1.33s   0.00s   8.21s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      3   13% zvol
 630167 host--------   1.33s   0.00s   8.72s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      1   13% zvol
 630161 host--------   1.31s   0.00s   8.72s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      0   13% zvol
 630156 host--------   1.29s   0.00s   8.78s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      0   13% zvol
 630142 host--------   1.28s   0.00s   8.13s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      1   13% zvol
 630140 host--------   1.22s   0.00s   8.28s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      1   12% zvol
 630141 host--------   1.22s   0.00s   8.28s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      1   12% zvol
    277 host--------   1.18s   0.00s   8.75s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      0   12% z_wr_iss
 631797 host--------   1.18s   0.00s   8.92s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      0   12% z_wr_iss
 630163 host--------   1.15s   0.00s   8.91s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      1   12% zvol
 631796 host--------   1.12s   0.00s   8.99s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      1   11% z_wr_iss
 626397 host--------   0.02s   0.02s   1.84s  0.00s      0B      0B  103.5K     0B  root      root      --    -    1  R      1    0% atop
     16 host--------   0.02s   0.00s   2.08s  0.00s      0B      0B      0B     0B  root      root      --    -    1  R      0    0% rcu_preempt
   1881 host--------   0.02s   0.00s   2.88s  0.00s      0B      0B      0B     0B  root      root      --    -    1  S      1    0% kvm-pit/1762
   2080 host--------   0.02s   0.00s   2.92s  0.00s      0B      0B      0B     0B  root      root      --    -    1  S      1    0% kvm-pit/1980
   2247 host--------   0.02s   0.00s   2.76s  0.00s      0B      0B      0B     0B  root      root      --    -    1  S      1    0% kvm-pit/2198
  43026 host--------   0.02s   0.00s   0.00s  0.00s      0B      0B      0B     0B  root      root      --    -    1  I      2    0% kworker/2:3-ev
 415907 host--------   0.02s   0.00s   0.29s  0.00s      0B      0B      0B     0B  root      root      --    -    1  I      0    0% kworker/0:2-ev
 415917 host--------   0.02s   0.00s   0.05s  0.00s      0B      0B      0B     0B  root      root      --    -    1  I      3    0% kworker/3:0-ev
 611488 host--------   0.02s   0.00s   0.55s  0.00s      0B      0B      0B     0B  root      root      --    -    1  I      2    0% kworker/u8:3-e
2765759 host--------   0.02s   0.00s   2.60s  0.00s      0B      0B      0B     0B  root      root      --    -    1  S      1    0% kvm-pit/276569
2765954 host--------   0.02s   0.00s   1.53s  0.00s      0B      0B      0B     0B  root      root      --    -    1  S      0    0% kvm-pit/276588

Any ideas why the zvol threads cause such high load, when all they should do is wait for IO?

Should I try to reduce the number of zvol threads to at least make this less severe if and when it happens again?

Could this be in any way related to my motherboard SATA controller or driver?
It's an ASUS P10S-I using the C232 chipset for its SATA ports.
 
For good measure, I'll also post some output from dmesg during startup. There is no additional output in dmesg during the high CPU load event.

code_language.shell:
[    1.133676] ahci 0000:00:17.0: version 3.0


[    1.148142] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps 0x3f impl SATA mode
[    1.148150] ahci 0000:00:17.0: flags: 64bit ncq sntf pm led clo only pio slum part ems deso sadm sds apst

[    1.205766] scsi host0: ahci

[    1.206153] scsi host1: ahci
[    1.206455] scsi host2: ahci
[    1.206655] scsi host3: ahci
[    1.206752] scsi host4: ahci
[    1.206835] scsi host5: ahci
[    1.206879] ata1: SATA max UDMA/133 abar m2048@0xde61d000 port 0xde61d100 irq 126
[    1.206888] ata2: SATA max UDMA/133 abar m2048@0xde61d000 port 0xde61d180 irq 126
[    1.206892] ata3: SATA max UDMA/133 abar m2048@0xde61d000 port 0xde61d200 irq 126
[    1.206896] ata4: SATA max UDMA/133 abar m2048@0xde61d000 port 0xde61d280 irq 126
[    1.206900] ata5: SATA max UDMA/133 abar m2048@0xde61d000 port 0xde61d300 irq 126
[    1.206904] ata6: SATA max UDMA/133 abar m2048@0xde61d000 port 0xde61d380 irq 126
[    1.249008] igb 0000:05:00.0 eno1: renamed from eth1
[    1.265093] igb 0000:04:00.0 eno2: renamed from eth0
[    1.485149] tsc: Refined TSC clocksource calibration: 2999.988 MHz
[    1.485158] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2b3e39bd40e, max_idle_ns: 440795214891 ns
[    1.485203] clocksource: Switched to clocksource tsc
[    1.521694] ata2: SATA link down (SStatus 0 SControl 300)
[    1.521719] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.521741] ata4: SATA link down (SStatus 0 SControl 300)
[    1.521762] ata3: SATA link down (SStatus 0 SControl 300)
[    1.521799] ata1: SATA link down (SStatus 0 SControl 300)
[    1.521850] ata6: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.522048] ata5.00: ATA-10: SSDSC2BB016T7R, N201DL43, max UDMA/133
[    1.522384] ata6.00: ATA-10: INTEL SSDSC2BB016T7, N2010112, max UDMA/133
[    1.522392] ata6.00: 3125627568 sectors, multi 1: LBA48 NCQ (depth 32)
[    1.523089] ata6.00: configured for UDMA/133
[    1.523773] ata5.00: 3125627568 sectors, multi 1: LBA48 NCQ (depth 32)
[    1.523782] ata5.00: Features: NCQ-prio
[    1.526203] ata5.00: configured for UDMA/133
[    1.526438] scsi 4:0:0:0: Direct-Access     ATA      SSDSC2BB016T7R   DL43 PQ: 0 ANSI: 5
[    1.526863] sd 4:0:0:0: Attached scsi generic sg0 type 0
[    1.526905] sd 4:0:0:0: [sda] 3125627568 512-byte logical blocks: (1.60 TB/1.46 TiB)
[    1.526912] sd 4:0:0:0: [sda] 4096-byte physical blocks
[    1.526974] sd 4:0:0:0: [sda] Write Protect is off
[    1.526980] sd 4:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    1.526989] scsi 5:0:0:0: Direct-Access     ATA      INTEL SSDSC2BB01 0112 PQ: 0 ANSI: 5
[    1.527001] sd 4:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.527090] sd 4:0:0:0: [sda] Preferred minimum I/O size 4096 bytes
[    1.527329] sd 5:0:0:0: Attached scsi generic sg1 type 0
[    1.527331] ata6.00: Enabling discard_zeroes_data
[    1.527348] sd 5:0:0:0: [sdb] 3125627568 512-byte logical blocks: (1.60 TB/1.46 TiB)
[    1.527354] sd 5:0:0:0: [sdb] 4096-byte physical blocks
[    1.527364] sd 5:0:0:0: [sdb] Write Protect is off
[    1.527367] sd 5:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    1.527378] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    1.527404] sd 5:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes
[    1.527598] ata6.00: Enabling discard_zeroes_data
[    1.529664]  sdb: sdb1 sdb2 sdb3
[    1.529969] sd 5:0:0:0: [sdb] Attached SCSI disk
[    1.534835]  sda: sda1 sda2 sda3
[    1.535205] sd 4:0:0:0: [sda] Attached SCSI disk


And from the journalctl output there are a few events around the time of the high load. Not sure if there is anything useful here...



code_language.shell:
Sep 02 13:22:25 pvehost pveproxy[615957]: worker exit

Sep 02 13:22:26 pvehost pveproxy[1738]: worker 615957 finished
Sep 02 13:22:26 pvehost pveproxy[1738]: starting 1 worker(s)
Sep 02 13:22:26 pvehost pveproxy[1738]: worker 624310 started
Sep 02 13:26:24 pvehost pvedaemon[607695]: <root@pam> successful auth for user 'root@pam'
Sep 02 13:28:24 pvehost pvedaemon[608929]: <root@pam> successful auth for user 'root@pam'
Sep 02 13:29:04 pvehost smartd[851]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Case_Temperature changed from 63 to 62
Sep 02 13:29:53 pvehost pveproxy[619308]: worker exit
Sep 02 13:29:53 pvehost pveproxy[1738]: worker 619308 finished
Sep 02 13:29:53 pvehost pveproxy[1738]: starting 1 worker(s)
Sep 02 13:29:53 pvehost pveproxy[1738]: worker 626273 started
Sep 02 13:39:52 pvehost pveproxy[621261]: worker exit
Sep 02 13:39:52 pvehost pveproxy[1738]: worker 621261 finished
Sep 02 13:39:52 pvehost pveproxy[1738]: starting 1 worker(s)
Sep 02 13:39:52 pvehost pveproxy[1738]: worker 628871 started
Sep 02 13:41:24 pvehost pvedaemon[622778]: <root@pam> successful auth for user 'root@pam'
Sep 02 13:44:24 pvehost pvedaemon[622778]: <root@pam> successful auth for user 'root@pam'
Sep 02 13:50:42 pvehost pvestatd[1703]: closing with write buffer at /usr/share/perl5/IO/Multiplex.pm line 928.
Sep 02 13:50:52 pvehost pve-firewall[1701]: firewall update time (11.561 seconds)
Sep 02 13:50:53 pvehost pvestatd[1703]: status update time (16.576 seconds)
Sep 02 13:50:53 pvehost pmxcfs[1597]: [status] notice: RRDC update error /var/lib/rrdcached/db/pve2-vm/105: -1
Sep 02 13:50:53 pvehost pmxcfs[1597]: [status] notice: RRDC update error /var/lib/rrdcached/db/pve2-storage/pvehost/local: -1
Sep 02 13:50:53 pvehost pmxcfs[1597]: [status] notice: RRDC update error /var/lib/rrdcached/db/pve2-storage/pvehost/local-zfs: -1
Sep 02 13:51:11 pvehost pve-firewall[1701]: firewall update time (8.092 seconds)
Sep 02 13:51:16 pvehost pvestatd[1703]: status update time (13.080 seconds)
Sep 02 13:51:46 pvehost pvestatd[1703]: VM 104 qmp command failed - VM 104 qmp command 'query-proxmox-support' failed - got timeout
Sep 02 13:52:00 pvehost pvestatd[1703]: closing with write buffer at /usr/share/perl5/IO/Multiplex.pm line 928.
Sep 02 13:52:08 pvehost pve-ha-lrm[1747]: loop take too long (46 seconds)
Sep 02 13:52:09 pvehost pvestatd[1703]: VM 101 qmp command failed - VM 101 qmp command 'query-proxmox-support' failed - got timeout
Sep 02 13:52:09 pvehost pveproxy[624310]: detected empty handle
Sep 02 13:52:09 pvehost pveproxy[624310]: detected empty handle
Sep 02 13:52:09 pvehost pveproxy[626273]: detected empty handle
Sep 02 13:52:09 pvehost pveproxy[624310]: detected empty handle
Sep 02 13:52:09 pvehost pveproxy[626273]: detected empty handle
Sep 02 13:52:09 pvehost pveproxy[626273]: detected empty handle
Sep 02 13:52:09 pvehost pve-firewall[1701]: firewall update time (42.640 seconds)
Sep 02 13:52:10 pvehost pvestatd[1703]: status update time (53.449 seconds)
Sep 02 13:52:20 pvehost sshd[631974]: Accepted password for root from X.X.X.X port 61943 ssh2
Sep 02 13:52:20 pvehost sshd[631974]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Sep 02 13:52:20 pvehost systemd-logind[858]: New session 3077 of user root.
Sep 02 13:52:20 pvehost systemd[1]: Started session-3077.scope - Session 3077 of User root.
Sep 02 13:52:20 pvehost sshd[631974]: pam_env(sshd:session): deprecated reading of user environment enabled
Sep 02 13:52:20 pvehost sshd[632003]: Accepted password for root from X.X.X.X port 61959 ssh2
Sep 02 13:52:20 pvehost sshd[632003]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Sep 02 13:52:20 pvehost systemd-logind[858]: New session 3078 of user root.
Sep 02 13:52:20 pvehost systemd[1]: Started session-3078.scope - Session 3078 of User root.
Sep 02 13:52:20 pvehost sshd[632003]: pam_env(sshd:session): deprecated reading of user environment enabled
Sep 02 13:52:26 pvehost pvestatd[1703]: status update time (6.088 seconds)
Sep 02 13:53:09 pvehost pveproxy[628871]: detected empty handle
Sep 02 13:53:10 pvehost pvestatd[1703]: status update time (6.832 seconds)
Sep 02 13:53:29 pvehost pvestatd[1703]: status update time (5.868 seconds)
Sep 02 13:54:35 pvehost pveproxy[624310]: worker exit
Sep 02 13:54:35 pvehost pveproxy[1738]: worker 624310 finished
Sep 02 13:54:35 pvehost pveproxy[1738]: starting 1 worker(s)
Sep 02 13:54:35 pvehost pveproxy[1738]: worker 632696 started
Sep 02 13:54:41 pvehost pvedaemon[607695]: worker exit
Sep 02 13:54:41 pvehost pvedaemon[1729]: worker 607695 finished
Sep 02 13:54:41 pvehost pvedaemon[1729]: starting 1 worker(s)
Sep 02 13:54:41 pvehost pvedaemon[1729]: worker 632729 started
Sep 02 13:56:31 pvehost pveproxy[626273]: worker exit
Sep 02 13:56:31 pvehost pveproxy[1738]: worker 626273 finished
Sep 02 13:56:31 pvehost pveproxy[1738]: starting 1 worker(s)
Sep 02 13:56:31 pvehost pveproxy[1738]: worker 633204 started
Sep 02 13:57:24 pvehost pvedaemon[622778]: <root@pam> successful auth for user 'root@pam'
Sep 02 13:59:24 pvehost pvedaemon[632729]: <root@pam> successful auth for user 'root@pam'
Sep 02 14:01:15 pvehost pveproxy[628871]: worker exit


The nextcloud VM ID is 110 and does not show up. And even though two other VMs show up in this list, 101 (TrueNAS) and 104 (Windows 10), I suspect that is mostly coincidence as they are both essentially idle during all of this. 105 (LXC for docker) shows up too, and is also idle.
 
How are you connecting everything? NFS? I found that at least in the case of an update, Nextcloud requires some work arounds for using NFS storage. I had to change the update directory to something local, and not use the NFS share. You do that by adding the following to your config.php file for Nextcloud
Code:
'updatedirectory' => '/var/nc_update',

Use whatever local directory you desire. I created and used /var/nc-update, which is not a pre-existing directory. Make sure you change the ownership (chown) to www-data:www-data when you creat the directory
 
You also should probably look into running Nextcloud in a docker container. It will for sure use less resources. Here is my docker-compose.yml for my nextcloud stack if you want to try it out. You could spin this up in the TrueNAS VM and use mapped directories instead of NFS shares as well. My advice though is to install portainer and do it that way. I am not a fan of the apps function in TrueNAS


YAML:
services:
  nextcloud:
    image: nextcloud
    container_name: nextcloud
    restart: unless-stopped
    networks:
      - cloud
      - nginx
    depends_on:
      - nextclouddb
      - redis
    ports:
      - 9090:80 # use whatever port you have free on the left of the colon
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - NEXTCLOUD_DATA_DIR=/mnt/ncdata
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_PASSWORD=password1 # change this. Must match password1 below when changed
      - MYSQL_HOST=nextclouddb
      - REDIS_HOST=redis
    volumes:
      - type: volume
        source: html
        target: /var/www/html
        volume:
          nocopy: true
      - type: volume
        source: data
        target: /mnt/ncdata
        volume:
          nocopy: true

  nextclouddb:
    image: mariadb:11.4
    container_name: nextcloud-db
    restart: unless-stopped
    command: --transaction-isolation=READ-COMMITTED --binlog-format=ROW
    networks:
      - cloud
    volumes:
      - type: volume
        source: database
        target: /var/lib/mysql
        volume:
          nocopy: true
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - MYSQL_ROOT_PASSWORD=password2 # change this, must match password2 below
      - MYSQL_PASSWORD=password1      # change this, must match password1 above
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
     
  collabora:
    image: collabora/code
    container_name: collabora
    restart: unless-stopped
    networks:
      - cloud
      - nginx
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - password=password3          # change this
      - username=nextcloud
      - domain=collabora.louiecloud.com
      - extra_params=--o:ssl.enable=true
    ports:
      - 9980:9980                  # use whatever ports you have open that don't conflict

  redis:
    image: redis:alpine
    container_name: redis
    restart: unless-stopped
    volumes:
      - type: volume
        source: redis
        target: /data
        volume:
          nocopy: true
    networks:
      - cloud
 
  nginx-proxy:
    image: 'jc21/nginx-proxy-manager:latest'
    container_name: nginx-proxy
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
    restart: unless-stopped
    ports:
      - '80:80'
      - '81:81'
      - '443:443'
    networks:
      - nginx
    volumes:
      - type: volume
        source: nginx
        target: /data
        volume:
          nocopy: true
      - type: volume
        source: letsencrypt
        target: /etc/letsencrypt
        volume:
          nocopy: true

networks:
  cloud:
    name: cloud
    driver: bridge
  nginx:
    name: nginx
    driver: bridge

volumes:
  html:
    driver_opts:
      type: "nfs"
      o: "vers=4,addr=192.168.50.3,nolock,soft,rw"
      device: ":/mnt/slow_pool/nextcloud/html"
  data:
    driver_opts:
      type: "nfs"
      o: "vers=4,addr=192.168.50.3,nolock,soft,rw"
      device: ":/mnt/slow_pool/nextcloud/data"
  database:
    driver_opts:
      type: "nfs"
      o: "vers=4,addr=192.168.50.3,nolock,soft,rw"
      device: ":/mnt/slow_pool/nextcloud/database"
  redis:
    driver_opts:
      type: "nfs"
      o: "vers=4,addr=192.168.50.3,nolock,soft,rw"
      device: ":/mnt/slow_pool/nextcloud/redis"
  nginx:
    driver_opts:
      type: "nfs"
      o: "vers=4,addr=192.168.50.3,nolock,soft,rw"
      device: ":/mnt/slow_pool/nextcloud/nginx"
  letsencrypt:
    driver_opts:
      type: "nfs"
      o: "vers=4,addr=192.168.50.3,nolock,soft,rw"
      device: ":/mnt/slow_pool/nextcloud/letsencrypt"
 
Last edited:
How are you connecting everything? NFS? I found that at least in the case of an update, Nextcloud requires some work arounds for using NFS storage. I had to change the update directory to something local, and not use the NFS share. You do that by adding the following to your config.php file for Nextcloud
Code:
'updatedirectory' => '/var/nc_update',

Use whatever local directory you desire. I created and used /var/nc-update, which is not a pre-existing directory. Make sure you change the ownership (chown) to www-data:www-data when you creat the directory
Storage for the Proxmox server is two local fairly matched (Intel DC S3520 1.6TB, one DELL and one vanilla Intel) drives in a ZFS mirror, using SATA ports from the motherboard C232 chipset.

The Nextcloud VM is an Ubuntu VM running Nextcloud AIO. The VM is allocated a 96GB VM disk from this local ZFS mirror storage. I have approximately 20GB stored locally on this drive for my user in Nextcloud, but the bulk (all photos) of it is via an SMB share. The SMB share is served by a TrueNAS VM on the same Proxmox host, with the storage from drives hooked up to an HBA in passthrough mode.

My initial issue was seemingly when there was a lot of network traffic during heavy uploads, but I suspect there were a lot of writes to the local ZFS mirror involved also, like the second example highlights, because I cannot fathom how simply a lot of network traffic would result in such high server load.
 
I may have a lead, hopefully... Looking at the memory usage in the VM for Nextcloud after the fact, I see it has been using about 700 MB of swap. I didn't consider the swap when creating the VM and installing Ubuntu, and so it just grabbed a small part of the one and only drive I allocated.

If the VM at some point during this container update procedure had to do a fair bit of swapping, I can see this causing a lot of sync writes to the ZFS pool.

I'll try to reproduce this behavior (without crashing my system again) now that I have an idea of what might be the cause. After, as a short term fix, bump up the allocated RAM for this VM.

To prevent a single VM from causing this, if it turns out to be related to swapping (or excessive disk reads/writes in general), I will look at suitable mitigation. Limiting read/write both in terms of MB/s and IOPS per disk seems possible, but seems tedious if you need to do it manually.
 
Swap usage means its running out of memory. Increase the memory available to that VM. I know I said this before, but I think it bears repeating: Running Nextcloud in its own VM is kind of a waste of resources. You can run it right in TrueNAS and you would likely be better off.
 
Swap usage means its running out of memory. Increase the memory available to that VM. I know I said this before, but I think it bears repeating: Running Nextcloud in its own VM is kind of a waste of resources. You can run it right in TrueNAS and you would likely be better off.
I prefer to keep the services separate from the NAS, especially since I may separate them into different hosts at some point. I keep my TrueNAS Core VM lean.

And, the swapping hypothesis might be a dud, at least so far.

I tried to drop the Nextcloud VM RAM down to a mere 2 GB, which is forcing it to grow to using 2 GB of swap just by booting and starting all containers. The zvol threads stay at only 2% CPU and do not enter the previous runaway state.

There must be something else going on here, perhaps at a driver level. If it was on the device/SSD level, I would expect one of them to misbehave but not both at the same time.

But, nothing showed up in the logs. "atop" at the time of disconnect from SSH shows essentially no disk activity, but each zvol thread is using a lot of CPU time waiting for something. The first time shown in the third column is SYSCPU, and fifth is RDELAY (runqueue delay).

What may have caused the zvol thread to spaz out like this?