I use gmirror swap (with 2 drives) and I don't see this issue.
Let us know if disabling swap fix your issue.
Let us know if disabling swap fix your issue.
Touch wood, the system's been very stable since I got rid of gmirror swap. Time will tell if it stays this way...
To me spreading it out over 8 drives like the OP seems like a problem waiting to happen.
If I was using only-ZFS I would consider adding a zpool (or zvol ??) for swap.
To me that seems logical.
I was reviewing your graphs and this sticks out to me.
Physical Memory =33% used. Not bad but the amount seems concerning. 22GB of RAM consumed.
How much of that is allocated to your two VM's?
I have to ask this question too. Why two M1015 controllers. With an 8 drive arrangement one card would do.
Then put your SSD on the motherboard SATA3.
If you were running an array of SSD drives I would understand. Dual Path backplane too.
The M1015 is only PCIe 2 with x8 interface. 8 SSDs will soak the interface. Been there done that.
With today's rotating disks you cannot saturate that interface.
To me it seems sacrilegious to put a PCIe 2.0 card on a SM X11 board. The SAS3008 are not much more.
You will have to wait at least 9 days, before feeling at least feeling hopeful. Best wishes!
The GELI partitions are authenticated only, no encryption. I don't care about disk performance. I do care about data integrity. I have 3 variants:Just for my info how many drives are you spreading your gmirror swap over?
Any docs to back your worries up?
On larger systems with multiple SCSI disks or multiple IDE disks operating on different controllers, it is recommended that swap be configured on each drive, up to four drives. The swap partitions should be approximately the same size. The kernel can handle arbitrary sizes but internal data structures scale to 4 times the largest swap partition. Keeping the swap partitions near the same size will allow the kernel to optimally stripe swap space across disks. Large swap sizes are fine, even if swap is not used much. It might be easier to recover from a runaway program before being forced to reboot.