Hi Vladimir,
Yeah, the results are pretty low compared to yours but i think this is due to the fact that this SSD is in a fairly old server (Supermicro X8, SAS2 expander backplane).
Controller is LSI/Broadcom 9207-8i on the latest IT firmware (Same LSI2308 chipset as yours)
Kind regards,
Caspar
Caspar
2018-03-13 21:00 GMT+01:00 Дробышевский, Владимир <vlad@xxxxxxxxxx>:
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 throughTest 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-testwhere XXX - number of jobsResults:numjobs: 1write: io=5068.6MB, bw=86493KB/s, iops=21623, runt= 60001msecclat (usec): min=38, max=8343, avg=45.01, stdev=32.10numjobs : 5write: io=14548MB, bw=248274KB/s, iops=62068, runt= 60001msecclat (usec): min=40, max=11291, avg=79.05, stdev=46.37numjobs : 10write: io=14762MB, bw=251939KB/s, iops=62984, runt= 60001msecclat (usec): min=52, max=10356, avg=157.16, stdev=65.69I 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-te ).st-if-your-ssd-is-suitable-as- a-journal-device/#comment-3273 882789 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.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
