SSD as DB/WAL performance with/without drive write cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux