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.

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-
> test-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

ИТ-консалтинг
Поставка проектов "под ключ"
Аутсорсинг ИТ-услуг
Аутсорсинг ИТ-инфраструктуры
_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to