Ji-Hyeon Gim
2017-Nov-09 10:29 UTC
[Gluster-users] [Gluster-devel] Poor performance of block-store with RDMA
Hi Kalever! First of all, I really appreciate your test results for block-store(https://github.com/pkalever/iozone_results_gluster/tree/master/block-store) :-) My teammate and I tested block-store(glfs backstore with tcmu-runner) but we have met a problem of performance. We tested some cases with one server that has RDMA volume and one client that is connected to same RDMA network. two machines have same environment like below. - Distro : CentOS 6.9 - Kernel : 4.12.9 - GlusterFS : 3.10.5 - tcmu-runner : 1.2.0 - iscsi-initiator-utils : 6.2.0.873 and these are results from test. 1st. FILEIO on FUSE mounted - 333MB/sec 2nd. glfs user backstore - 140MB/sec 3rd. FILEIO on FUSE mounted with tgtd - 235MB/sec 4th. glfs user backstore with tgtd - 220MB/sec 5th. FILEIO on FUSE mounted (iSER) - 643MB/sec 6th. glfs user backstore (iSER) - 149MB/sec 7th. FILEIO on FUSE mounted with tgtd (iSER) - 677MB/sec 8th. glfs user backstore with tgtd(iSER) - 535MB/sec Every tests were done with dd command. As shown above, 6th test showed similar results in 2nd test. IMOH, It may be caused by tcmu-runner itself or glfs backstore handler so I will take similar tests with other handlers(like qcow) in order to find this point. If there's anything I missed, Could you give me some tips for resolving this issue? :-) Best regards. -- Ji-Hyeon Gim Research Engineer, Gluesys Address. Gluesys R&D Center, 5F, 11-31, Simin-daero 327beon-gil, Dongan-gu, Anyang-si, Gyeonggi-do, Korea (14055) Phone. +82-70-8787-1053 Fax. +82-31-388-3261 Mobile. +82-10-7293-8858 E-Mail. potatogim at potatogim.net Website. www.potatogim.net The time I wasted today is the tomorrow the dead man was eager to see yesterday. - Sophocles -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 516 bytes Desc: OpenPGP digital signature URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20171109/21c06ef4/attachment.sig>