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 2018-03-13 21:00 GMT+01:00 Дробышевский, Владимир <v...@itgorod.ru>: > 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-te > st-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. > > 2018-03-13 21:33 GMT+05:00 Caspar Smit <caspars...@supernas.eu>: > >> 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: >> >> https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-tes >> t-if-your-ssd-is-suitable-as-a-journal-device/ >> >> 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/s >> 5 Jobs: 179 MB/s >> 10 Jobs: 179 MB/s >> >> I 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/s >> 5 Jobs: 110 MB/s >> 10 Jobs: 132 MB/s >> >> So 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@lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com >> >> > > > -- > > С уважением, > Дробышевский Владимир > Компания "АйТи Город" > +7 343 2222192 <+7%20343%20222-21-92> > > ИТ-консалтинг > Поставка проектов "под ключ" > Аутсорсинг ИТ-услуг > Аутсорсинг ИТ-инфраструктуры >
_______________________________________________ ceph-users mailing list ceph-users@lists.ceph.com http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
