[BALUG-Admin] balug VM just got a performance/reliability boost

[Michael Paoli]

The balug VM (which also hosts SF-LUG non-list content),
just got a performance/reliability boost for at least its
nominal hosting environment.  It's virtual disk had been on
ZFS (under fuse) with aggressive compression and deduplication,
which optimized for space (atop SSD), but gave performance
that was sometimes problematic (notably on a physical host
not having an overabundance of RAM).  Anyway, just moved
that to SSD - with none of those space (but not performance)
optimized ZFS layers ... much snappier and faster now.

As for drive(s) on the alternate ("vicki") physical host,
those are mirrored spinning rust ... but quite "fast enough"
for balug VM purposes.  On the nominal location, that SSD
for the balug VM isn't (yet) mirrored ... but fairly likely
I'll add that in near future (the VM not only gets
relatively regular backups, but also each time a live
migration is done, that also creates an inherent backup upon
the physical host it moves from - and that's generally done
at least 4 times per month).  Both hosting environments
do have LVM layers (negligible performance hit, substantially
aids manageability), and the nominal host also has LUKS
encryption layer (again negligible performance hit given the
power of non-ancient CPU(s)/cores).
before:
# time dd if=balug-sda bs=512 of=/dev/null
33554432+0 records in
33554432+0 records out
17179869184 bytes (17 GB) copied, 288.979 s, 59.5 MB/s

real    4m48.980s
user    0m2.920s
sys     0m20.852s
#
after:
# time dd if=balug-sda bs=512 of=/dev/null
33554432+0 records in
33554432+0 records out
17179869184 bytes (17 GB) copied, 44.2483 s, 388 MB/s

real    0m44.251s
user    0m2.852s
sys     0m29.280s
#
Or with a different block size (128 KiB is optimal for my ZFS
configuration), and even with it no longer having any (notably RAM)
contention of the VM running from the older storage:
old:
# time dd if=balug-sda.old bs=131072 of=/dev/null
131072+0 records in
131072+0 records out
17179869184 bytes (17 GB) copied, 75.5826 s, 227 MB/s

real    1m15.589s
user    0m0.096s
sys     0m5.060s
#
new:
# time dd if=balug-sda bs=131072 of=/dev/null
131072+0 records in
131072+0 records out
17179869184 bytes (17 GB) copied, 40.3681 s, 426 MB/s

real    0m40.372s
user    0m0.072s
sys     0m19.776s
#
But it did have that space optimization (note physical vs. logical):
# ls -hls balug-sda.old
5.2G -rw------- 1 root root 16G Nov  5 16:10 balug-sda.old
#
Within the VM itself, we see much more than 5.2G used:
# df -h -t ext3; swapon -s
Filesystem              Size  Used Avail Use% Mounted on
/dev/dm-0               469M  237M  209M  54% /
/dev/dm-1               1.7G  1.4G  178M  89% /usr
/dev/sda1               244M   33M  201M  15% /boot
/dev/mapper/balug-home  1.1G  635M  432M  60% /home
/dev/mapper/balug-var   4.6G  3.9G  560M  88% /var
Filename                                Type            Size    Used    
  Priority
/dev/dm-4                               partition       131068  130944  -1
/dev/dm-9                               partition       131068  130924  -2
/dev/dm-6                               partition       131068  130816  -3
/dev/dm-7                               partition       131068  94456   -4
/dev/dm-5                               partition       131068  0       -5
/dev/dm-11                              partition       131068  0       -6
/dev/dm-10                              partition       131068  0       -7
/dev/dm-8                               partition       131068  0       -8
#
That's 16 GiB virtual drive, about 9.1 G of filesystem+swap space,
in 5.2 of physical.

The VM could certainly still use more RAM - that's its
main performance bottleneck (given workloads & software and
such).  The constraints on that is the physical hosts upon
which it runs.  One of them ("vicki") only has 2 GiB of
physical RAM total ... hence the VM is still at 1 GiB (the
other physical host where it's nominally located, has 8 GiB,
but that host also does lots of other stuff too, so also doesn't
exactly have lots of RAM to spare).  Anyway, may also come up
with some more RAM resources in future (may shift the "alternate"
physical host to one where more RAM is available).  Ideally
I'd like to bump the balug VM up to something in the 1.5 to 2 GiB
range - possibly more ... but have to reasonably have that to spare
from the physical hosting environments first.  The balug VM does
also have and use swap ... but that swap now also benefits from
the improved virtual drive performance - at least on its nominal
host.