Hello, Caspar!
Would you mind to share controller model you use? I would say these results are pretty low.
Here are my results on Intel RMS25LB LSI2308 based SAS controller in IT mode:
I set write_cache to write through
Test command, fio 2.2.10:
sudo fio --filename=/dev/sdb --direct=1 --sync=1 --rw=write --bs=4k --numjobs=XXX --iodepth=1 --runtime=60 --time_based --group_reporting --name=journal-test
where XXX - number of jobs
Results:
numjobs: 1
write: io=5068.6MB, bw=86493KB/s, iops=21623, runt= 60001msec
clat (usec): min=38, max=8343, avg=45.01, stdev=32.10
numjobs
: 5
write: io=14548MB, bw=248274KB/s, iops=62068, runt= 60001msec
clat (usec): min=40, max=11291, avg=79.05, stdev=46.37
numjobs
: 10
write: io=14762MB, bw=251939KB/s, iops=62984, runt= 60001msec
clat (usec): min=52, max=10356, avg=157.16, stdev=65.69
I have got even better results on z97 integrated SATA controller, you can find them in comments to the post you have mentioned (https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is-suitable-as-a-journal-device/#comment-3273882789 ).
Still don't know why LSI 2308 SAS performance worse than z97 SATA and can't find any info on why write back cache setting has slower write than write through.
But I would offer to pay more attention to IOPS than to the sequential write speed, especially on the small blocks workload.
But I would offer to pay more attention to IOPS than to the sequential write speed, especially on the small blocks workload.
2018-03-13 21:33 GMT+05:00 Caspar Smit <casparsmit@xxxxxxxxxxx>:
Hi all,I've tested some new Samsung SM863 960GB and Intel DC S4600 240GB SSD's using the method described at Sebastien Han's blog:The first thing stated there is to disable the drive's write cache, which i did.For the Samsungs i got these results:1 Job: 85 MB/s5 Jobs: 179 MB/s10 Jobs: 179 MB/sI was curious what the results would be with the drive write cache on, so i turned it on.Now i got these results:1 Job: 49 MB/s5 Jobs: 110 MB/s10 Jobs: 132 MB/sSo i didn't expect these results to be worse because i would assume a drive write cache would make it faster.For the Intels i got more or less the same conclusion (with different figures) but the performance with drive write cache was about half the performance as without drive write cache.
Questions:1) Is this expected behaviour (for all/most SSD's)? If yes, why?2) Is this only with this type of test?3) Should i always disable drive write cache for SSD's during boot?4) Is there any negative side-effect of disabling the drive's write cache?5) Are these tests still relevant for DB/WAL devices? The blog is written for Filestore and states all journal writes are sequential but is that also true for bluestore DB/WAL writes? Do i need to test differently for DB/WAL?Kind regards,
Caspar
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph. com
С уважением,
Дробышевский Владимир
Компания "АйТи Город"
+7 343 2222192
ИТ-консалтинг
Поставка проектов "под ключ"
Аутсорсинг ИТ-услуг
Аутсорсинг ИТ-инфраструктуры
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
