<div dir="ltr">Hi Vlad,<div><br></div><div>I actually saw that post already and even asked a question 4 days ago (<a href="https://serverfault.com/questions/517775/glusterfs-direct-i-o-mode#comment1172497_540917">https://serverfault.com/questions/517775/glusterfs-direct-i-o-mode#comment1172497_540917</a>). The accepted answer also seems to go against your suggestion to enable direct-io-mode as it says it should be disabled for better performance when used just for file accesses.</div><div><br></div><div>It&#39;d be great if someone from the Gluster team chimed in about this thread.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Sincerely,<br>Artem<br><br>--<br>Founder, <a href="http://www.androidpolice.com" target="_blank">Android Police</a>, <a href="http://www.apkmirror.com/" style="font-size:12.8000001907349px" target="_blank">APK Mirror</a><span style="font-size:12.8000001907349px">, Illogical Robot LLC</span></div><div dir="ltr"><a href="http://beerpla.net/" target="_blank">beerpla.net</a> | <a href="https://plus.google.com/+ArtemRussakovskii" target="_blank">+ArtemRussakovskii</a> | <a href="http://twitter.com/ArtemR" target="_blank">@ArtemR</a><br></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Apr 10, 2018 at 7:01 AM, Vlad Kopylov <span dir="ltr">&lt;<a href="mailto:vladkopy@gmail.com" target="_blank">vladkopy@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"><div><div>Wish I knew or was able to get detailed description of those options myself.<br></div><div>here is 
direct-io-mode 

<a href="https://serverfault.com/questions/517775/glusterfs-direct-i-o-mode" target="_blank">https://serverfault.com/<wbr>questions/517775/glusterfs-<wbr>direct-i-o-mode</a><br></div>Same as you I ran tests on a large volume of files, finding that main delays are in attribute calls, ending up with those mount options to add performance.<br></div><div>I discovered those options through basically googling this user list with people sharing their tests.<br></div>Not sure I would share your optimism, and rather then going up I downgraded to 3.12 and have no dir view issue now. Though I had to recreate the cluster and had to re-add bricks with existing data.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 10, 2018 at 1:47 AM, Artem Russakovskii <span dir="ltr">&lt;<a href="mailto:archon810@gmail.com" target="_blank">archon810@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 Vlad,<div><br></div><div>I&#39;m using only localhost: mounts.</div><div><br></div><div>Can you please explain what effect each option has on performance issues shown in my posts? &quot;negative-timeout=10,attribute<wbr>-timeout=30,fopen-keep-cache,d<wbr>irect-io-mode=enable,fetch-att<wbr>empts=5&quot; From what I remember, direct-io-mode=enable didn&#39;t make a difference in my tests, but I suppose I can try again. The explanations about direct-io-mode are quite confusing on the web in various guides, saying enabling it could make performance worse in some situations and better in others due to OS file cache.</div><div><br></div><div>There are also these gluster volume settings, adding to the confusion:</div><div><div>Option: performance.strict-o-direct</div><div>Default Value: off</div><div>Description: This option when set to off, ignores the O_DIRECT flag.</div><div><br></div><div>Option: performance.nfs.strict-o-direc<wbr>t</div><div>Default Value: off</div><div>Description: This option when set to off, ignores the O_DIRECT flag.</div></div><div><br></div><div>Re: 4.0. I moved to 4.0 after finding out that it fixes the disappearing dirs bug related to cluster.readdir-optimize if you remember (<a href="http://lists.gluster.org/pipermail/gluster-users/2018-April/033830.html" target="_blank">http://lists.gluster.org/pipe<wbr>rmail/gluster-users/2018-April<wbr>/033830.html</a>). I was already on 3.13 by then, and 4.0 resolved the issue. It&#39;s been stable for me so far, thankfully.</div><div class="gmail_extra"><span><br clear="all"><div><div class="m_-2442537929453809111m_3104514395859481521m_-9168214684418515114gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Sincerely,<br>Artem<br><br>--<br>Founder, <a href="http://www.androidpolice.com" target="_blank">Android Police</a>, <a href="http://www.apkmirror.com/" style="font-size:12.8000001907349px" target="_blank">APK Mirror</a><span style="font-size:12.8000001907349px">, Illogical Robot LLC</span></div><div dir="ltr"><a href="http://beerpla.net/" target="_blank">beerpla.net</a> | <a href="https://plus.google.com/+ArtemRussakovskii" target="_blank">+ArtemRussakovskii</a> | <a href="http://twitter.com/ArtemR" target="_blank">@ArtemR</a><br></div></div></div></div></div></div></div></div></div></div></div>
<br></span><div><div class="m_-2442537929453809111h5"><div class="gmail_quote">On Mon, Apr 9, 2018 at 10:38 PM, Vlad Kopylov <span dir="ltr">&lt;<a href="mailto:vladkopy@gmail.com" target="_blank">vladkopy@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">
<div><div>you definitely need mount options to 
/etc/fstab<br></div>use ones from here <a href="http://lists.gluster.org/pipermail/gluster-users/2018-April/033811.html" target="_blank">http://lists.gluster.org/piper<wbr>mail/gluster-users/2018-April/<wbr>033811.html</a><br><br></div><div>I went on with using local mounts to achieve performance as well<br></div><div><br></div>Also, 3.12 or 3.10 branches would be preferable for production

<br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-2442537929453809111m_3104514395859481521m_-9168214684418515114h5">On Fri, Apr 6, 2018 at 4:12 AM, Artem Russakovskii <span dir="ltr">&lt;<a href="mailto:archon810@gmail.com" target="_blank">archon810@gmail.com</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-2442537929453809111m_3104514395859481521m_-9168214684418515114h5"><div dir="ltr">Hi again,<div><br></div><div>I&#39;d like to expand on the performance issues and plead for help. Here&#39;s one case which shows these odd hiccups: <a href="https://i.imgur.com/CXBPjTK.gifv" target="_blank">https://i.imgur.com/C<wbr>XBPjTK.gifv</a>.<div><br></div><div>In this GIF where I switch 

<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">back and forth</span>

between copy operations on 2 servers, I&#39;m copying a 10GB dir full of .apk and image files.</div><div><br></div><div>On server &quot;hive&quot; I&#39;m copying straight from the main disk to an attached volume block (xfs). As you can see, the transfers are relatively speedy and don&#39;t hiccup.</div><div>On server &quot;citadel&quot; I&#39;m copying the same set of data to a 4-replicate gluster which uses block storage as a brick. As you can see, performance is much worse, and there are frequent pauses for many seconds where nothing seems to be happening - just freezes.<br></div><div><br></div><div>All 4 servers have the same specs, and all of them have performance issues with gluster and no such issues when raw xfs block storage is used.</div><div><br></div><div>hive has long finished copying the data, while citadel is barely chugging along and is expected to take probably half an hour to an hour. I have over 1TB of data to migrate, at which point if we went live, I&#39;m not even sure gluster would be able to keep up instead of bringing the machines and services down.</div><div><br></div><div><br></div><div><br></div><div>Here&#39;s the cluster config, though it didn&#39;t seem to make any difference performance-wise before I applied the customizations vs after.</div><div><br></div><div><div>Volume Name: apkmirror_data1</div><div>Type: Replicate</div><div>Volume ID: 11ecee7e-d4f8-497a-9994-ceb144<wbr>d6841e</div><div>Status: Started</div><div>Snapshot Count: 0</div><div>Number of Bricks: 1 x 4 = 4</div><div>Transport-type: tcp</div><div>Bricks:</div><div>Brick1: nexus2:/mnt/nexus2_block1/apkm<wbr>irror_data1</div><div>Brick2: forge:/mnt/forge_block1/apkmir<wbr>ror_data1</div><div>Brick3: hive:/mnt/hive_block1/apkmirro<wbr>r_data1</div><div>Brick4: citadel:/mnt/citadel_block1/ap<wbr>kmirror_data1</div><div>Options Reconfigured:</div><div>cluster.quorum-count: 1</div><div>cluster.quorum-type: fixed</div><div>network.ping-timeout: 5</div><div>network.remote-dio: enable</div><div>performance.rda-cache-limit: 256MB</div><div>performance.readdir-ahead: on</div><div>performance.parallel-readdir: on</div><div>network.inode-lru-limit: 500000</div><div>performance.md-cache-timeout: 600</div><div>performance.cache-invalidation<wbr>: on</div><div>performance.stat-prefetch: on</div><div>features.cache-invalidation-ti<wbr>meout: 600</div><div>features.cache-invalidation: on</div><div>cluster.readdir-optimize: on</div><div>performance.io-thread-count: 32</div><div>server.event-threads: 4</div><div>client.event-threads: 4</div><div>performance.read-ahead: off</div><div>cluster.lookup-optimize: on</div><div>performance.cache-size: 1GB</div><div>cluster.self-heal-daemon: enable</div><div>transport.address-family: inet</div><div>nfs.disable: on</div><div>performance.client-io-threads: on</div></div><div><br></div><div><br></div><div>The mounts are done as follows in /etc/fstab:</div><div>/dev/disk/by-id/scsi-0Linode_V<wbr>olume_citadel_block1 /mnt/citadel_block1 xfs defaults 0 2<br></div><div>localhost:/apkmirror_data1 /mnt/apkmirror_data1 glusterfs defaults,_netdev 0 0<br></div><div><br></div><div>I&#39;m really not sure if direct-io-mode mount tweaks would do anything here, what the value should be set to, and what it is by default.</div><div><br></div><div>The OS is OpenSUSE 42.3, 64-bit. 80GB of RAM, 20 CPUs, hosted by Linode.</div><div><br></div><div>I&#39;d really appreciate any help in the matter. </div><div><br></div><div>Thank you.</div></div></div><div class="gmail_extra"><span><br clear="all"><div><div class="m_-2442537929453809111m_3104514395859481521m_-9168214684418515114m_-7640979976631609660m_7374879952101670984gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Sincerely,<br>Artem<br><br>--<br>Founder, <a href="http://www.androidpolice.com" target="_blank">Android Police</a>, <a href="http://www.apkmirror.com/" style="font-size:12.8000001907349px" target="_blank">APK Mirror</a><span style="font-size:12.8000001907349px">, Illogical Robot LLC</span></div><div dir="ltr"><a href="http://beerpla.net/" target="_blank">beerpla.net</a> | <a href="https://plus.google.com/+ArtemRussakovskii" target="_blank">+ArtemRussakovskii</a> | <a href="http://twitter.com/ArtemR" target="_blank">@ArtemR</a><br></div></div></div></div></div></div></div></div></div></div></div>
<br></span><div><div class="m_-2442537929453809111m_3104514395859481521m_-9168214684418515114m_-7640979976631609660h5"><div class="gmail_quote">On Thu, Apr 5, 2018 at 11:13 PM, Artem Russakovskii <span dir="ltr">&lt;<a href="mailto:archon810@gmail.com" target="_blank">archon810@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,<div><br></div><div>I&#39;m trying to squeeze performance out of gluster on 4 80GB RAM 20-CPU machines where Gluster runs on attached block storage (Linode) in (4 replicate bricks), and so far everything I tried results in sub-optimal performance.</div><div><br></div><div>There are many files - mostly images, several million - and many operations take minutes, copying multiple files (even if they&#39;re small) suddenly freezes up for seconds at a time, then continues, iostat frequently shows large r_await and w_awaits with 100% utilization for the attached block device, etc.</div><div><br></div><div>But anyway, there are many guides out there for small-file performance improvements, but more explanation is needed, and I think more tweaks should be possible.<br></div><div><br></div><div>My question today is about performance.cache-size. Is this a size of cache in RAM? If so, how do I view the current cache size to see if it gets full and I should increase its size? Is it advisable to bump it up if I have many tens of gigs of RAM free? </div><div><br></div><div><br></div><div><br></div><div>More generally, in the last 2 months since I first started working with gluster and set a production system live, I&#39;ve been feeling frustrated because Gluster has a lot of poorly-documented and confusing options. I really wish documentation could be improved with examples and better explanations.</div><div><br></div><div>Specifically, it&#39;d be absolutely amazing if the docs offered a strategy for setting each value and ways of determining more optimal values. For example, for performance.cache-size, if it said something like &quot;run command abc to see your current cache size, and if it&#39;s hurting, up it, but be aware that it&#39;s limited by RAM,&quot; it&#39;d be already a huge improvement to the docs. And so on with other options.</div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">The gluster team is quite helpful on this mailing list, but in a reactive rather than proactive way. Perhaps it&#39;s tunnel vision once you&#39;ve worked on a project for so long where less technical explanations and even proper documentation of options takes a back seat, but I encourage you to be more proactive about helping us understand and optimize Gluster.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial">Thank you.</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration-style:initial;text-decoration-color:initial"><br></div><div><div class="m_-2442537929453809111m_3104514395859481521m_-9168214684418515114m_-7640979976631609660m_7374879952101670984m_1420630595765814996gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Sincerely,<br>Artem<br><br>--<br>Founder, <a href="http://www.androidpolice.com" target="_blank">Android Police</a>, <a href="http://www.apkmirror.com/" style="font-size:12.8px" target="_blank">APK Mirror</a><span style="font-size:12.8px">, Illogical Robot LLC</span></div><div dir="ltr"><a href="http://beerpla.net/" target="_blank">beerpla.net</a> | <a href="https://plus.google.com/+ArtemRussakovskii" target="_blank">+ArtemRussakovskii</a> | <a href="http://twitter.com/ArtemR" target="_blank">@ArtemR</a><br></div></div></div></div></div></div></div></div></div></div></div>
</div></div>
</blockquote></div><br></div></div></div>
<br></div></div><span>______________________________<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></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>