MySQL and ceph volumes

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

 



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>


[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