<div dir="auto"><div>Hi Strahil, in the original email I included both the times for the first and subsequent reads on the fuse mounted gluster volume as well as the xfs filesystem the gluster data resides on (this is the brick, right?). </div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Apr 30, 2020, 7:44 AM Strahil Nikolov &lt;<a href="mailto:hunter86_bg@yahoo.com">hunter86_bg@yahoo.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On April 30, 2020 4:24:23 AM GMT+03:00, Artem Russakovskii &lt;<a href="mailto:archon810@gmail.com" target="_blank" rel="noreferrer">archon810@gmail.com</a>&gt; wrote:<br>
&gt;Hi all,<br>
&gt;<br>
&gt;We have 500GB and 10TB 4x1 replicate xfs-based gluster volumes, and the<br>
&gt;10TB one especially is extremely slow to do certain things with (and<br>
&gt;has<br>
&gt;been since gluster 3.x when we started). We&#39;re currently on 5.13.<br>
&gt;<br>
&gt;The number of files isn&#39;t even what I&#39;d consider that great - under<br>
&gt;100k<br>
&gt;per dir.<br>
&gt;<br>
&gt;Here are some numbers to look at:<br>
&gt;<br>
&gt;On gluster volume in a dir of 45k files:<br>
&gt;The first time<br>
&gt;<br>
&gt;time find | wc -l<br>
&gt;45423<br>
&gt;real  Â  8m44.819s<br>
&gt;user  Â  0m0.459s<br>
&gt;sys  Â  Â 0m0.998s<br>
&gt;<br>
&gt;And again<br>
&gt;<br>
&gt;time find | wc -l<br>
&gt;45423<br>
&gt;real  Â  0m34.677s<br>
&gt;user  Â  0m0.291s<br>
&gt;sys  Â  Â 0m0.754s<br>
&gt;<br>
&gt;<br>
&gt;If I run the same operation on the xfs block device itself:<br>
&gt;The first time<br>
&gt;<br>
&gt;time find | wc -l<br>
&gt;45423<br>
&gt;real  Â  0m13.514s<br>
&gt;user  Â  0m0.144s<br>
&gt;sys  Â  Â 0m0.501s<br>
&gt;<br>
&gt;And again<br>
&gt;<br>
&gt;time find | wc -l<br>
&gt;45423<br>
&gt;real  Â  0m0.197s<br>
&gt;user  Â  0m0.088s<br>
&gt;sys  Â  Â 0m0.106s<br>
&gt;<br>
&gt;<br>
&gt;I&#39;d expect a performance difference here but just as it was several<br>
&gt;years<br>
&gt;ago when we started with gluster, it&#39;s still huge, and simple file<br>
&gt;listings<br>
&gt;are incredibly slow.<br>
&gt;<br>
&gt;At the time, the team was looking to do some optimizations, but I&#39;m not<br>
&gt;sure this has happened.<br>
&gt;<br>
&gt;What can we do to try to improve performance?<br>
&gt;<br>
&gt;Thank you.<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;Some setup values follow.<br>
&gt;<br>
&gt;xfs_info /mnt/SNIP_block1<br>
&gt;meta-data=/dev/sdc  Â  Â  Â  Â  Â  Â  Â isize=512  Â  agcount=103,<br>
&gt;agsize=26214400<br>
&gt;blks<br>
&gt;  Â  Â  Â  Â =  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â sectsz=512  Â attr=2, projid32bit=1<br>
&gt;  Â  Â  =  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â crc=1  Â  Â  Â  finobt=1, sparse=0, rmapbt=0<br>
&gt;  Â  Â  Â  Â =  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â reflink=0<br>
&gt;data  Â  Â =  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â bsize=4096  Â blocks=2684354560,<br>
&gt;imaxpct=25<br>
&gt;  Â  Â  Â  Â =  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â sunit=0  Â  Â  swidth=0 blks<br>
&gt;naming  Â =version 2  Â  Â  Â  Â  Â  Â  bsize=4096  Â ascii-ci=0, ftype=1<br>
&gt;log  Â  Â  =internal log  Â  Â  Â  Â  Â bsize=4096  Â blocks=51200, version=2<br>
&gt;  Â  Â  Â  =  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â  Â sectsz=512  Â sunit=0 blks, lazy-count=1<br>
&gt;realtime =none  Â  Â  Â  Â  Â  Â  Â  Â  Â extsz=4096  Â blocks=0, rtextents=0<br>
&gt;<br>
&gt;Volume Name: SNIP_data1<br>
&gt;Type: Replicate<br>
&gt;Volume ID: SNIP<br>
&gt;Status: Started<br>
&gt;Snapshot Count: 0<br>
&gt;Number of Bricks: 1 x 4 = 4<br>
&gt;Transport-type: tcp<br>
&gt;Bricks:<br>
&gt;Brick1: nexus2:/mnt/SNIP_block1/SNIP_data1<br>
&gt;Brick2: forge:/mnt/SNIP_block1/SNIP_data1<br>
&gt;Brick3: hive:/mnt/SNIP_block1/SNIP_data1<br>
&gt;Brick4: citadel:/mnt/SNIP_block1/SNIP_data1<br>
&gt;Options Reconfigured:<br>
&gt;cluster.quorum-count: 1<br>
&gt;cluster.quorum-type: fixed<br>
&gt;network.ping-timeout: 5<br>
&gt;network.remote-dio: enable<br>
&gt;performance.rda-cache-limit: 256MB<br>
&gt;performance.readdir-ahead: on<br>
&gt;performance.parallel-readdir: on<br>
&gt;network.inode-lru-limit: 500000<br>
&gt;performance.md-cache-timeout: 600<br>
&gt;performance.cache-invalidation: on<br>
&gt;performance.stat-prefetch: on<br>
&gt;features.cache-invalidation-timeout: 600<br>
&gt;features.cache-invalidation: on<br>
&gt;cluster.readdir-optimize: on<br>
&gt;performance.io-thread-count: 32<br>
&gt;server.event-threads: 4<br>
&gt;client.event-threads: 4<br>
&gt;performance.read-ahead: off<br>
&gt;cluster.lookup-optimize: on<br>
&gt;performance.cache-size: 1GB<br>
&gt;cluster.self-heal-daemon: enable<br>
&gt;transport.address-family: inet<br>
&gt;nfs.disable: on<br>
&gt;performance.client-io-threads: on<br>
&gt;cluster.granular-entry-heal: enable<br>
&gt;cluster.data-self-heal-algorithm: full<br>
&gt;<br>
&gt;Sincerely,<br>
&gt;Artem<br>
&gt;<br>
&gt;--<br>
&gt;Founder, Android Police &lt;<a href="http://www.androidpolice.com" rel="noreferrer noreferrer" target="_blank">http://www.androidpolice.com</a>&gt;, APK Mirror<br>
&gt;&lt;<a href="http://www.apkmirror.com/" rel="noreferrer noreferrer" target="_blank">http://www.apkmirror.com/</a>&gt;, Illogical Robot LLC<br>
&gt;<a href="http://beerpla.net" rel="noreferrer noreferrer" target="_blank">beerpla.net</a> | @ArtemR &lt;<a href="http://twitter.com/ArtemR" rel="noreferrer noreferrer" target="_blank">http://twitter.com/ArtemR</a>&gt;<br>
<br>
Hi Artem,<br>
<br>
Have you checked the same on brick level ? How big is the difference ?<br>
<br>
Best Regards,<br>
Strahil Nikolov<br>
</blockquote></div></div></div>