<div dir="ltr"><div>Hi Dmitri, <br><br></div><div>I was getting 8 - 10 MB/s on the gluster mount before the changes, which was really slow and the VMs where sluggish and impractical to use. <br></div><div>After the changes, I am getting 70 MB/s which is the expected considering I am using 1 Gbit network for the storage. <br></div><div>The VMs also became way more responsive and are giving a normal user experience.<br></div><div><br></div><div>For a quick test on the mount point on the host I am using: <br>dd if=/dev/zero of=testfile bs=1M count=1024 oflag=direct<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 11, 2017 at 7:27 PM, Dmitri Chebotarov <span dir="ltr">&lt;<a href="mailto:4dimach@gmail.com" target="_blank">4dimach@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Abi<div><br></div><div>Can you please share your current transfer speeds after you made the change?</div><div><br></div><div>Thank you.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 11, 2017 at 9:55 AM, Ben Turner <span dir="ltr">&lt;<a href="mailto:bturner@redhat.com" target="_blank">bturner@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>----- Original Message -----<br>
&gt; From: &quot;Abi Askushi&quot; &lt;<a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a>&gt;<br>
</span><span>&gt; To: &quot;Ben Turner&quot; &lt;<a href="mailto:bturner@redhat.com" target="_blank">bturner@redhat.com</a>&gt;<br>
&gt; Cc: &quot;Krutika Dhananjay&quot; &lt;<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>&gt;, &quot;gluster-user&quot; &lt;<a href="mailto:gluster-users@gluster.org" target="_blank">gluster-users@gluster.org</a>&gt;<br>
&gt; Sent: Monday, September 11, 2017 1:40:42 AM<br>
&gt; Subject: Re: [Gluster-users] Slow performance of gluster volume<br>
&gt;<br>
</span><span>&gt; Did not upgrade yet gluster. I am stillĀ  using 3.8.12. Only the mentioned<br>
&gt; changes did provide the performance boost.<br>
&gt;<br>
&gt; From which version to which version did you see such performance boost? I<br>
&gt; will try to upgrade and check difference also.<br>
<br>
</span>Unfortunately I didn&#39;t record the package versions, I also may have done the same thing as you :)<br>
<span class="m_-7540587932374600458HOEnZb"><font color="#888888"><br>
-b<br>
</font></span><div class="m_-7540587932374600458HOEnZb"><div class="m_-7540587932374600458h5"><br>
&gt;<br>
&gt; On Sep 11, 2017 2:45 AM, &quot;Ben Turner&quot; &lt;<a href="mailto:bturner@redhat.com" target="_blank">bturner@redhat.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Great to hear!<br>
&gt;<br>
&gt; ----- Original Message -----<br>
&gt; &gt; From: &quot;Abi Askushi&quot; &lt;<a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a>&gt;<br>
&gt; &gt; To: &quot;Krutika Dhananjay&quot; &lt;<a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a>&gt;<br>
&gt; &gt; Cc: &quot;gluster-user&quot; &lt;<a href="mailto:gluster-users@gluster.org" target="_blank">gluster-users@gluster.org</a>&gt;<br>
&gt; &gt; Sent: Friday, September 8, 2017 7:01:00 PM<br>
&gt; &gt; Subject: Re: [Gluster-users] Slow performance of gluster volume<br>
&gt; &gt;<br>
&gt; &gt; Following changes resolved the perf issue:<br>
&gt; &gt;<br>
&gt; &gt; Added the option<br>
&gt; &gt; /etc/glusterfs/glusterd.vol :<br>
&gt; &gt; option rpc-auth-allow-insecure on<br>
&gt;<br>
&gt; Was it this setting or was it the gluster upgrade, do you know for sure?<br>
&gt; It may be helpful to others to know for sure(Im interested too:).<br>
&gt;<br>
&gt; -b<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; restarted glusterd<br>
&gt; &gt;<br>
&gt; &gt; Then set the volume option:<br>
&gt; &gt; gluster volume set vms server.allow-insecure on<br>
&gt; &gt;<br>
&gt; &gt; I am reaching now the max network bandwidth and performance of VMs is<br>
&gt; quite<br>
&gt; &gt; good.<br>
&gt; &gt;<br>
&gt; &gt; Did not upgrade the glusterd.<br>
&gt; &gt;<br>
&gt; &gt; As a next try I am thinking to upgrade gluster to 3.12 + test libgfapi<br>
&gt; &gt; integration of qemu by upgrading to ovirt 4.1.5 and check vm perf.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Sep 6, 2017 1:20 PM, &quot;Abi Askushi&quot; &lt; <a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a> &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I tried to follow step from<br>
&gt; &gt; <a href="https://wiki.centos.org/SpecialInterestGroup/Storage" rel="noreferrer" target="_blank">https://wiki.centos.org/Specia<wbr>lInterestGroup/Storage</a> to install latest<br>
&gt; &gt; gluster on the first node.<br>
&gt; &gt; It installed 3.10 and not 3.11. I am not sure how to install 3.11 without<br>
&gt; &gt; compiling it.<br>
&gt; &gt; Then when tried to start the gluster on the node the bricks were reported<br>
&gt; &gt; down (the other 2 nodes have still 3.8). No sure why. The logs were<br>
&gt; showing<br>
&gt; &gt; the below (even after rebooting the server):<br>
&gt; &gt;<br>
&gt; &gt; [2017-09-06 10:56:09.023777] E [rpcsvc.c:557:rpcsvc_check_and<wbr>_reply_error]<br>
&gt; &gt; 0-rpcsvc: rpc actor failed to complete successfully<br>
&gt; &gt; [2017-09-06 10:56:09.024122] E [server-helpers.c:395:server_a<wbr>lloc_frame]<br>
&gt; &gt; (--&gt;/lib64/libgfrpc.so.0(rpcsv<wbr>c_handle_rpc_call+0x325) [0x7f2d0ec20905]<br>
&gt; &gt; --&gt;/usr/lib64/glusterfs/3.10.5<wbr>/xlator/protocol/server.so(+0x<wbr>3006b)<br>
&gt; &gt; [0x7f2cfa4bf06b]<br>
&gt; &gt; --&gt;/usr/lib64/glusterfs/3.10.5<wbr>/xlator/protocol/server.so(+0x<wbr>db34)<br>
&gt; &gt; [0x7f2cfa49cb34] ) 0-server: invalid argument: client [Invalid argument]<br>
&gt; &gt;<br>
&gt; &gt; Do I need to upgrade all nodes before I attempt to start the gluster<br>
&gt; &gt; services?<br>
&gt; &gt; I reverted the first node back to 3.8 at the moment and all restored.<br>
&gt; &gt; Also tests with eager lock disabled did not make any difference.<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Wed, Sep 6, 2017 at 11:15 AM, Krutika Dhananjay &lt; <a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a> &gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Do you see any improvement with 3.11.1 as that has a patch that improves<br>
&gt; perf<br>
&gt; &gt; for this kind of a workload<br>
&gt; &gt;<br>
&gt; &gt; Also, could you disable eager-lock and check if that helps? I see that max<br>
&gt; &gt; time is being spent in acquiring locks.<br>
&gt; &gt;<br>
&gt; &gt; -Krutika<br>
&gt; &gt;<br>
&gt; &gt; On Wed, Sep 6, 2017 at 1:38 PM, Abi Askushi &lt; <a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a> &gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Krutika,<br>
&gt; &gt;<br>
&gt; &gt; Is it anything in the profile indicating what is causing this bottleneck?<br>
&gt; In<br>
&gt; &gt; case i can collect any other info let me know.<br>
&gt; &gt;<br>
&gt; &gt; Thanx<br>
&gt; &gt;<br>
&gt; &gt; On Sep 5, 2017 13:27, &quot;Abi Askushi&quot; &lt; <a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a> &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Krutika,<br>
&gt; &gt;<br>
&gt; &gt; Attached the profile stats. I enabled profiling then ran some dd tests.<br>
&gt; Also<br>
&gt; &gt; 3 Windows VMs are running on top this volume but did not do any stress<br>
&gt; &gt; testing on the VMs. I have left the profiling enabled in case more time is<br>
&gt; &gt; needed for useful stats.<br>
&gt; &gt;<br>
&gt; &gt; Thanx<br>
&gt; &gt;<br>
&gt; &gt; On Tue, Sep 5, 2017 at 12:48 PM, Krutika Dhananjay &lt; <a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a> &gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; OK my understanding is that with preallocated disks the performance with<br>
&gt; and<br>
&gt; &gt; without shard will be the same.<br>
&gt; &gt;<br>
&gt; &gt; In any case, please attach the volume profile[1], so we can see what else<br>
&gt; is<br>
&gt; &gt; slowing things down.<br>
&gt; &gt;<br>
&gt; &gt; -Krutika<br>
&gt; &gt;<br>
&gt; &gt; [1] -<br>
&gt; &gt; <a href="https://gluster.readthedocs.io/en/latest/Administrator%" rel="noreferrer" target="_blank">https://gluster.readthedocs.io<wbr>/en/latest/Administrator%</a><br>
&gt; 20Guide/Monitoring%20Workload/<wbr>#running-glusterfs-volume-prof<wbr>ile-command<br>
&gt; &gt;<br>
&gt; &gt; On Tue, Sep 5, 2017 at 2:32 PM, Abi Askushi &lt; <a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a> &gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Krutika,<br>
&gt; &gt;<br>
&gt; &gt; I already have a preallocated disk on VM.<br>
&gt; &gt; Now I am checking performance with dd on the hypervisors which have the<br>
&gt; &gt; gluster volume configured.<br>
&gt; &gt;<br>
&gt; &gt; I tried also several values of shard-block-size and I keep getting the<br>
&gt; same<br>
&gt; &gt; low values on write performance.<br>
&gt; &gt; Enabling client-io-threads also did not have any affect.<br>
&gt; &gt;<br>
&gt; &gt; The version of gluster I am using is glusterfs 3.8.12 built on May 11 2017<br>
&gt; &gt; 18:46:20.<br>
&gt; &gt; The setup is a set of 3 Centos 7.3 servers and ovirt 4.1, using gluster as<br>
&gt; &gt; storage.<br>
&gt; &gt;<br>
&gt; &gt; Below are the current settings:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Volume Name: vms<br>
&gt; &gt; Type: Replicate<br>
&gt; &gt; Volume ID: 4513340d-7919-498b-bfe0-d836b5<wbr>cea40b<br>
&gt; &gt; Status: Started<br>
&gt; &gt; Snapshot Count: 0<br>
&gt; &gt; Number of Bricks: 1 x (2 + 1) = 3<br>
&gt; &gt; Transport-type: tcp<br>
&gt; &gt; Bricks:<br>
&gt; &gt; Brick1: gluster0:/gluster/vms/brick<br>
&gt; &gt; Brick2: gluster1:/gluster/vms/brick<br>
&gt; &gt; Brick3: gluster2:/gluster/vms/brick (arbiter)<br>
&gt; &gt; Options Reconfigured:<br>
&gt; &gt; server.event-threads: 4<br>
&gt; &gt; client.event-threads: 4<br>
&gt; &gt; performance.client-io-threads: on<br>
&gt; &gt; features.shard-block-size: 512MB<br>
&gt; &gt; cluster.granular-entry-heal: enable<br>
&gt; &gt; performance.strict-o-direct: on<br>
&gt; &gt; network.ping-timeout: 30<br>
&gt; &gt; storage.owner-gid: 36<br>
&gt; &gt; storage.owner-uid: 36<br>
&gt; &gt; user.cifs: off<br>
&gt; &gt; features.shard: on<br>
&gt; &gt; cluster.shd-wait-qlength: 10000<br>
&gt; &gt; cluster.shd-max-threads: 8<br>
&gt; &gt; cluster.locking-scheme: granular<br>
&gt; &gt; cluster.data-self-heal-algorit<wbr>hm: full<br>
&gt; &gt; cluster.server-quorum-type: server<br>
&gt; &gt; cluster.quorum-type: auto<br>
&gt; &gt; cluster.eager-lock: enable<br>
&gt; &gt; network.remote-dio: off<br>
&gt; &gt; performance.low-prio-threads: 32<br>
&gt; &gt; performance.stat-prefetch: on<br>
&gt; &gt; performance.io-cache: off<br>
&gt; &gt; performance.read-ahead: off<br>
&gt; &gt; performance.quick-read: off<br>
&gt; &gt; transport.address-family: inet<br>
&gt; &gt; performance.readdir-ahead: on<br>
&gt; &gt; nfs.disable: on<br>
&gt; &gt; nfs.export-volumes: on<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I observed that when testing with dd if=/dev/zero of=testfile bs=1G<br>
&gt; count=1 I<br>
&gt; &gt; get 65MB/s on the vms gluster volume (and the network traffic between the<br>
&gt; &gt; servers reaches ~ 500Mbps), while when testing with dd if=/dev/zero<br>
&gt; &gt; of=testfile bs=1G count=1 oflag=direct I get a consistent 10MB/s and the<br>
&gt; &gt; network traffic hardly reaching 100Mbps.<br>
&gt; &gt;<br>
&gt; &gt; Any other things one can do?<br>
&gt; &gt;<br>
&gt; &gt; On Tue, Sep 5, 2017 at 5:57 AM, Krutika Dhananjay &lt; <a href="mailto:kdhananj@redhat.com" target="_blank">kdhananj@redhat.com</a> &gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; I&#39;m assuming you are using this volume to store vm images, because I see<br>
&gt; &gt; shard in the options list.<br>
&gt; &gt;<br>
&gt; &gt; Speaking from shard translator&#39;s POV, one thing you can do to improve<br>
&gt; &gt; performance is to use preallocated images.<br>
&gt; &gt; This will at least eliminate the need for shard to perform multiple steps<br>
&gt; as<br>
&gt; &gt; part of the writes - such as creating the shard and then writing to it and<br>
&gt; &gt; then updating the aggregated file size - all of which require one network<br>
&gt; &gt; call each, which further get blown up once they reach AFR (replicate) into<br>
&gt; &gt; many more network calls.<br>
&gt; &gt;<br>
&gt; &gt; Second, I&#39;m assuming you&#39;re using the default shard block size of 4MB (you<br>
&gt; &gt; can confirm this using `gluster volume get &lt;VOL&gt; shard-block-size`). In<br>
&gt; our<br>
&gt; &gt; tests, we&#39;ve found that larger shard sizes perform better. So maybe change<br>
&gt; &gt; the shard-block-size to 64MB (`gluster volume set &lt;VOL&gt; shard-block-size<br>
&gt; &gt; 64MB`).<br>
&gt; &gt;<br>
&gt; &gt; Third, keep stat-prefetch enabled. We&#39;ve found that qemu sends quite a<br>
&gt; lot of<br>
&gt; &gt; [f]stats which can be served from the (md)cache to improve performance. So<br>
&gt; &gt; enable that.<br>
&gt; &gt;<br>
&gt; &gt; Also, could you also enable client-io-threads and see if that improves<br>
&gt; &gt; performance?<br>
&gt; &gt;<br>
&gt; &gt; Which version of gluster are you using BTW?<br>
&gt; &gt;<br>
&gt; &gt; -Krutika<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Tue, Sep 5, 2017 at 4:32 AM, Abi Askushi &lt; <a href="mailto:rightkicktech@gmail.com" target="_blank">rightkicktech@gmail.com</a> &gt;<br>
&gt; &gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi all,<br>
&gt; &gt;<br>
&gt; &gt; I have a gluster volume used to host several VMs (managed through oVirt).<br>
&gt; &gt; The volume is a replica 3 with arbiter and the 3 servers use 1 Gbit<br>
&gt; network<br>
&gt; &gt; for the storage.<br>
&gt; &gt;<br>
&gt; &gt; When testing with dd (dd if=/dev/zero of=testfile bs=1G count=1<br>
&gt; oflag=direct)<br>
&gt; &gt; out of the volume (e.g. writing at /root/) the performance of the dd is<br>
&gt; &gt; reported to be ~ 700MB/s, which is quite decent. When testing the dd on<br>
&gt; the<br>
&gt; &gt; gluster volume I get ~ 43 MB/s which way lower from the previous. When<br>
&gt; &gt; testing with dd the gluster volume, the network traffic was not exceeding<br>
&gt; &gt; 450 Mbps on the network interface. I would expect to reach near 900 Mbps<br>
&gt; &gt; considering that there is 1 Gbit of bandwidth available. This results<br>
&gt; having<br>
&gt; &gt; VMs with very slow performance (especially on their write operations).<br>
&gt; &gt;<br>
&gt; &gt; The full details of the volume are below. Any advise on what can be<br>
&gt; tweaked<br>
&gt; &gt; will be highly appreciated.<br>
&gt; &gt;<br>
&gt; &gt; Volume Name: vms<br>
&gt; &gt; Type: Replicate<br>
&gt; &gt; Volume ID: 4513340d-7919-498b-bfe0-d836b5<wbr>cea40b<br>
&gt; &gt; Status: Started<br>
&gt; &gt; Snapshot Count: 0<br>
&gt; &gt; Number of Bricks: 1 x (2 + 1) = 3<br>
&gt; &gt; Transport-type: tcp<br>
&gt; &gt; Bricks:<br>
&gt; &gt; Brick1: gluster0:/gluster/vms/brick<br>
&gt; &gt; Brick2: gluster1:/gluster/vms/brick<br>
&gt; &gt; Brick3: gluster2:/gluster/vms/brick (arbiter)<br>
&gt; &gt; Options Reconfigured:<br>
&gt; &gt; cluster.granular-entry-heal: enable<br>
&gt; &gt; performance.strict-o-direct: on<br>
&gt; &gt; network.ping-timeout: 30<br>
&gt; &gt; storage.owner-gid: 36<br>
&gt; &gt; storage.owner-uid: 36<br>
&gt; &gt; user.cifs: off<br>
&gt; &gt; features.shard: on<br>
&gt; &gt; cluster.shd-wait-qlength: 10000<br>
&gt; &gt; cluster.shd-max-threads: 8<br>
&gt; &gt; cluster.locking-scheme: granular<br>
&gt; &gt; cluster.data-self-heal-algorit<wbr>hm: full<br>
&gt; &gt; cluster.server-quorum-type: server<br>
&gt; &gt; cluster.quorum-type: auto<br>
&gt; &gt; cluster.eager-lock: enable<br>
&gt; &gt; network.remote-dio: off<br>
&gt; &gt; performance.low-prio-threads: 32<br>
&gt; &gt; performance.stat-prefetch: off<br>
&gt; &gt; performance.io-cache: off<br>
&gt; &gt; performance.read-ahead: off<br>
&gt; &gt; performance.quick-read: off<br>
&gt; &gt; transport.address-family: inet<br>
&gt; &gt; performance.readdir-ahead: on<br>
&gt; &gt; nfs.disable: on<br>
&gt; &gt; nfs.export-volumes: on<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Thanx,<br>
&gt; &gt; Alex<br>
&gt; &gt;<br>
&gt; &gt; ______________________________<wbr>_________________<br>
&gt; &gt; Gluster-users mailing list<br>
&gt; &gt; <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
&gt; &gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; ______________________________<wbr>_________________<br>
&gt; &gt; Gluster-users mailing list<br>
&gt; &gt; <a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
&gt; &gt; <a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
&gt;<br>
______________________________<wbr>_________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="http://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://lists.gluster.org/mailm<wbr>an/listinfo/gluster-users</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>