Virtual Machines incredibly slow during parity check (including the Unraid VM Web UI!)

[tmchow]

I've got 2 VMs, one for Windows 10 and second one for Linux where I'm running Home Assistant.

While my parity check is running, the VMs are incredibly slow. Operations within Home Assistant will timeout, things are super slow to load, etc.   Windows 10 VM is also slow, but not as noticeable as the Linux VM for Home Assistant.

 

Even more so, the Unraid Web UI for the VMs is also slow. I get the perpetual loading screen sometimes and the VM list can take minutes to load.  Sometimes it won't load at all. If the parity check isn't running, things are super smooth.  

 

I'm trying to figure out what's going on and what I could be doing wrong. At first, I thought the issue was the fact my VM images were on the array and not the cache disk, but this wouldn't explain why the Unraid VM Web UI would be slow too, right?

 

I've tried searching for answers to this, but can't find anything I keep seeing results for slow parity checks which isn't info I'm looking for.

 

Anyone have any ideas?

[Squid]

The VMs will definitely grind to a halt if the vdisks are stored on the array during a parity check.  Why not schedule the parity checks for when you're sleeping and use the parity check tuning plugin to pause and resume them so that they only run for a couple of hours a night?

[tmchow]

1 hour ago, Squid said:

The VMs will definitely grind to a halt if the vdisks are stored on the array during a parity check.  Why not schedule the parity checks for when you're sleeping and use the parity check tuning plugin to pause and resume them so that they only run for a couple of hours a night?

I've got a 27TB array and parity check runs at 110MB/s so takes about 20 hours to complete so it's inevitably running while we are awake.

[JonathanM]

21 minutes ago, tmchow said:

I've got a 27TB array and parity check runs at 110MB/s so takes about 20 hours to complete so it's inevitably running while we are awake.

Exactly, which is why he suggested...

2 hours ago, Squid said:

use the parity check tuning plugin to pause and resume them so that they only run for a couple of hours a night?

 

[tmchow]

4 hours ago, Squid said:

The VMs will definitely grind to a halt if the vdisks are stored on the array during a parity check.  Why not schedule the parity checks for when you're sleeping and use the parity check tuning plugin to pause and resume them so that they only run for a couple of hours a night?

 

I missed this part of your reply.. doh!  I didn't know you could pause and resume the parity check like this. I had incorrectly assumed that it needed to be run continuously in one shot.  I'll look into this, thanks!

[Kosmos]

On 6/16/2020 at 6:28 AM, tmchow said:

Even more so, the Unraid Web UI for the VMs is also slow. I get the perpetual loading screen sometimes and the VM list can take minutes to load.  Sometimes it won't load at all. If the parity check isn't running, things are super smooth.  

Hey,

did you ever find out what's the issue with the slow ui during heavy hdd loads?

Best regards

[tmchow]

On 8/23/2021 at 11:27 AM, Kosmos said:

Hey,

did you ever find out what's the issue with the slow ui during heavy hdd loads?

Best regards

No

[Kosmos]

On 9/13/2021 at 8:31 PM, tmchow said:

No

Too bad,

I guess the problem might be that the docker vdisk can only be read very slowly when it's stored on a busy HDD.

I solved the problem by moving it to a SSD cache instead.

[pawael]

Hi,I know this thread is very old but in my case the problem is still current.

I use 1 zfs array with one hdd and one parity hdd and I use a mirrored zfs pool with 2 ssd.

All my vms, libvirt, docker engine and container data reside on the ssd pool. But still when parity check is running the web ui is extremely slow sometimes with no response and my linux debmatic vm (1 core, 1GB ram) is crashing (Log: shutting down, reason=crashed). First I used a HP Microserver Gen 10+ with 4c/8t Xeon CPU. Now I use the Ugreen DXP6800 pro with 10c/12t and 8GB ram (32GB are on the way). But both machines have the same behavior. 

Does someone have an idea why this happens while all virtualization is running on a ssd pool?

 

edit: After parity check everything runs flawlessly

Edited June 11 by pawael