<div dir="ltr"><div dir="ltr">I've just worked out I had the same issue, been trying to work out the cause for the past few days!<div><br></div><div>However I am using brand new enterprise Toshiba drivers with 256MB write cache, was seeing I/O wait peaks of 40% even during a small writing operation to CEPH and commit / apply latency's in the 40ms+.</div><div><br></div><div>Just went through and disabled the write cache on each drive, and done a few tests with the exact same write performance, but I/O wait in the <1% and commit / apply latency's in the 1-3ms max.</div><div><br></div><div>Something somewhere definitely doesn't seem to like the write cache being enabled on the disks, this is a EC Pool in the latest Mimic version.</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, Nov 11, 2018 at 5:34 AM Vitaliy Filippov <<a href="mailto:vitalif@yourcmc.ru">vitalif@yourcmc.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
A weird thing happens in my test cluster made from desktop hardware.<br>
<br>
The command `for i in /dev/sd?; do hdparm -W 0 $i; done` increases  <br>
single-thread write iops (reduces latency) 7 times!<br>
<br>
It is a 3-node cluster with Ryzen 2700 CPUs, 3x SATA 7200rpm HDDs + 1x  <br>
SATA desktop SSD for system and ceph-mon + 1x SATA server SSD for  <br>
block.db/wal in each host. Hosts are linked by 10gbit ethernet (not the  <br>
fastest one though, average RTT according to flood-ping is 0.098ms). Ceph  <br>
and OpenNebula are installed on the same hosts, OSDs are prepared with  <br>
ceph-volume and bluestore with default options. SSDs have capacitors  <br>
('power-loss protection'), write cache is turned off for them since the  <br>
very beginning (hdparm -W 0 /dev/sdb). They're quite old, but each of them  <br>
is capable of delivering ~22000 iops in journal mode (fio -sync=1  <br>
-direct=1 -iodepth=1 -bs=4k -rw=write).<br>
<br>
However, RBD single-threaded random-write benchmark originally gave awful  <br>
results - when testing with `fio -ioengine=libaio -size=10G -sync=1  <br>
-direct=1 -name=test -bs=4k -iodepth=1 -rw=randwrite -runtime=60  <br>
-filename=./testfile` from inside a VM, the result was only 58 iops  <br>
average (17ms latency). This was not what I expected from the HDD+SSD  <br>
setup.<br>
<br>
But today I tried to play with cache settings for data disks. And I was  <br>
really surprised to discover that just disabling HDD write cache (hdparm  <br>
-W 0 /dev/sdX for all HDD devices) increases single-threaded performance  <br>
~7 times! The result from the same VM (without even rebooting it) is  <br>
iops=405, avg lat=2.47ms. That's a magnitude faster and in fact 2.5ms  <br>
seems sort of an expected number.<br>
<br>
As I understand 4k writes are always deferred at the default setting of  <br>
prefer_deferred_size_hdd=32768, this means they should only get written to  <br>
the journal device before OSD acks the write operation.<br>
<br>
So my question is WHY? Why does HDD write cache affect commit latency with  <br>
WAL on an SSD?<br>
<br>
I would also appreciate if anybody with similar setup (HDD+SSD with  <br>
desktop SATA controllers or HBA) could test the same thing...<br>
<br>
-- <br>
With best regards,<br>
   Vitaliy Filippov<br>
_______________________________________________<br>
ceph-users mailing list<br>
<a href="mailto:ceph-users@lists.ceph.com" target="_blank">ceph-users@lists.ceph.com</a><br>
<a href="http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com" rel="noreferrer" target="_blank">http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com</a><br>
</blockquote></div>