[ovirt-users] [ANN] oVirt 4.1.9 Release is now available
Darrell Budic
budic at onholyground.com
Mon Jan 29 18:28:58 UTC 2018
Ok, so only for the HA engine eh? Been meaning to ask about that, since my hosted engine wasn’t using it. Tolerable, live disk migrations are way less valuable to me than better disk performance :) Other comments inline:
> From: Sahina Bose <sabose at redhat.com>
> Subject: Re: [ovirt-users] [ANN] oVirt 4.1.9 Release is now available
> Date: January 25, 2018 at 12:24:34 AM CST
> To: Darrell Budic
> Cc: Lev Veyde; users
>
> - it doesn’t seem to affect my HA vms, I’ve seen my 4.1.8 system properly restart systems using it (node/libvirtd crash that seems to have been related to spectre/meltdown firmwares)
>
> HA is an issue only when the gluster server used to provide volume information is down. For instance, if you have provided the "serverA:/volumeA" in your storage domain path , and if the other servers in replica are up but serverA is down, VM cannot restart. Have you tested this?
I’m using a DNS based methods & backup server mount options to ensure the volume info is always available, so this particular problem shouldn’t affect me (and hasn’t in my testing).
>
> Can you share any performance improvement numbers that you have seen after turning on libgfapi access, also information about your workload would be helpful.
>
> thanks!
Some not-very-scientific testing (can’t arrange dedicated disk time on this system) on a VM that hadn’t been covered yet gives me:
Before using gfapi:
]# dd if=/dev/urandom of=test.file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 90.1843 s, 11.9 MB/s
# echo 3 > /proc/sys/vm/drop_caches
# dd if=test.file of=/dev/null
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 3.94715 s, 272 MB/s
# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 17322 MB in 2.00 seconds = 8673.49 MB/sec
Timing buffered disk reads: 996 MB in 3.00 seconds = 331.97 MB/sec
#bonnie++ -d . -s 8G -n 0 -m pre-glapi -f -b -u root
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
pre-glapi 8G 196245 30 105331 15 962775 49 1638 34
Latency 1578ms 1383ms 201ms 301ms
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
pre-glapi 8G 155937 27 102899 14 1030285 54 1763 45
Latency 694ms 1333ms 114ms 229ms
(note, sequential reads seem to have been influenced by caching somewhere…)
After switching to gfapi:
# dd if=/dev/urandom of=test.file bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 80.8317 s, 13.3 MB/s
# echo 3 > /proc/sys/vm/drop_caches
# dd if=test.file of=/dev/null
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 3.3473 s, 321 MB/s
# hdparm -tT /dev/vda
/dev/vda:
Timing cached reads: 17112 MB in 2.00 seconds = 8568.86 MB/sec
Timing buffered disk reads: 1406 MB in 3.01 seconds = 467.70 MB/sec
#bonnie++ -d . -s 8G -n 0 -m glapi -f -b -u root
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
glapi 8G 359100 59 185289 24 489575 31 2079 67
Latency 160ms 355ms 36041us 185ms
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
glapi 8G 341307 57 180546 24 472572 35 2655 61
Latency 153ms 394ms 101ms 116ms
So excellent improvement in write throughput, but the significant improvement in latency is what was most noticed by users. Anecdotal reports of 2x+ performance improvements, with one remarking that it’s like having dedicated disks :)
This system is on my production cluster, so it’s not getting exclusive disk access, but this VM is not doing anything else itself. The cluster is 3 xeon E5-2609 v3 @ 1.90GHz servers w/ 64G ram, SATA2 disks; 2 with 9x spindles each, 1 with 8x slightly faster disks (all spinners). Using ZFS stripes with lz4 compression and 10G connectivity to 8 hosts. Running gluster 3.12.3 at the moment. The cluster itself has about 70 running VMs in varying states of switching to gfapi use, but my main sql servers are using their own volumes and not competing for this one. These have not yet had the spectre/meltdown patches applied.
This will be skewed because I forced it to not steal all the ram on the server (reads will certainly be cached), but an idea of what it can do disk wise, on the volume used above:
# bonnie++ -d . -s 8G -n 0 -m zfs-server -f -b -u root -r 4096
Version 1.97 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
zfs-server 8G 604940 79 510410 87 1393862 99 3164 91
Latency 99545us 100ms 247us 152ms
Just for fun from one of the servers showing base load and this testing:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180129/69ca3228/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PastedGraphic-1.png
Type: image/png
Size: 95175 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180129/69ca3228/attachment.png>
More information about the Users
mailing list