My response is without any context to ceph or any SDS, purely how to check the IO bottleneck. You can then determine if its Ceph or any other process or disk. >> MySQL can reach only 150 iops both read or writes showing 30% of IOwait. Lower IOPS is not issue with itself as your block size might be higher. But MySQL doing higher block not sure. You can check below iostat metrics to see why is the IO wait higher. * avgqu-sz(Avg queue length) --> Higher the Q length more the IO wait * avgrq-sz[The average size (in sectors)] --> Shows IOblock size( check this when using mysql). [ you need to calculate this based on your FS block size in KB & don?t just you the avgrq-sz # ] -- Deepak -----Original Message----- From: ceph-users [mailto:ceph-users-bounces@xxxxxxxxxxxxxx] On Behalf Of Matteo Dacrema Sent: Tuesday, March 07, 2017 12:52 PM To: ceph-users Subject: MySQL and ceph volumes Hi All, I have a galera cluster running on openstack with data on ceph volumes capped at 1500 iops for read and write ( 3000 total ). I can?t understand why with fio I can reach 1500 iops without IOwait and MySQL can reach only 150 iops both read or writes showing 30% of IOwait. I tried with fio 64k block size and various io depth ( 1.2.4.8.16?.128) and I can?t reproduce the problem. Anyone can tell me where I?m wrong? Thank you Regards Matteo _______________________________________________ ceph-users mailing list ceph-users at lists.ceph.com<mailto:ceph-users at lists.ceph.com> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ----------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ceph.com/pipermail/ceph-users-ceph.com/attachments/20170307/e3a3b24d/attachment.htm>