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

Reply via email to