similar to: Gluster native mount is really slow compared to nfs

Hello Vijay, ? ? What do you mean exactly? What info is missing? ? PS: I already found out that for this particular test all the difference is made by :?negative-timeout=600 , when removing it, it's much much slower again. ? ? Regards Jo ? -----Original message----- From:Vijay Bellur <vbellur at redhat.com> Sent:Tue 11-07-2017 18:16 Subject:Re: [Gluster-users] Gluster native mount is

On Tue, Jul 11, 2017 at 11:39 AM, Jo Goossens <jo.goossens at hosted-power.com> wrote: > Hello Joe, > > > > > > I just did a mount like this (added the bold): > > > mount -t glusterfs -o > *attribute-timeout=600,entry-timeout=600,negative-timeout=600,fopen-keep-cache* > ,use-readdirp=no,log-level=WARNING,log-file=/var/log/glusterxxx.log >

Hello Joe, ? ? I just did a mount like this (added the bold): ? mount -t glusterfs -o attribute-timeout=600,entry-timeout=600,negative-timeout=600,fopen-keep-cache,use-readdirp=no,log-level=WARNING,log-file=/var/log/glusterxxx.log 192.168.140.41:/www /var/www ?Results: ? root at app1:~/smallfile-master# ./smallfile_cli.py ?--top /var/www/test --host-set 192.168.140.41 --threads 8 --files 5000

On 07/11/2017 08:14 AM, Jo Goossens wrote: > RE: [Gluster-users] Gluster native mount is really slow compared to nfs > > Hello Joe, > > I really appreciate your feedback, but I already tried the opcache > stuff (to not valildate at all). It improves of course then, but not > completely somehow. Still quite slow. > > I did not try the mount options yet, but I will now!

Hello, ? ? Here is some speedtest with a new setup we just made with gluster 3.10, there are no other differences, except glusterfs versus nfs. The nfs is about 80 times faster: ? ? root at app1:~/smallfile-master# mount -t glusterfs -o use-readdirp=no,log-level=WARNING,log-file=/var/log/glusterxxx.log 192.168.140.41:/www /var/www root at app1:~/smallfile-master# ./smallfile_cli.py ?--top

My standard response to someone needing filesystem performance for www traffic is generally, "you're doing it wrong". https://joejulian.name/blog/optimizing-web-performance-with-glusterfs/ That said, you might also look at these mount options: attribute-timeout, entry-timeout, negative-timeout (set to some large amount of time), and fopen-keep-cache. On 07/11/2017 07:48 AM, Jo

Hello Joe, ? ? I really appreciate your feedback, but I already tried the opcache stuff (to not valildate at all). It improves of course then, but not completely somehow. Still quite slow. ? I did not try the mount options yet, but I will now! ? ? With nfs (doesnt matter much built-in version 3 or ganesha version 4) I can even host the site perfectly fast without these extreme opcache settings.

Hello, ? ? Here is the volume info as requested by soumya: ? #gluster volume info www ?Volume Name: www Type: Replicate Volume ID: 5d64ee36-828a-41fa-adbf-75718b954aff Status: Started Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: 192.168.140.41:/gluster/www Brick2: 192.168.140.42:/gluster/www Brick3: 192.168.140.43:/gluster/www Options Reconfigured:

Hi all, ? ? One more thing, we have 3 apps servers with the gluster on it, replicated on 3 different gluster nodes. (So the gluster nodes are app servers at the same time). We could actually almost work locally if we wouldn't need to have the same files on the 3 nodes and redundancy :) ? Initial cluster was created like this: ? gluster volume create www replica 3 transport tcp

I did a quick test on one of my lab clusters with no tuning except for quota being enabled: [root at dell-per730-03 ~]# gluster v info Volume Name: vmstore Type: Replicate Volume ID: 0d2e4c49-334b-47c9-8e72-86a4c040a7bd Status: Started Snapshot Count: 0 Number of Bricks: 1 x (2 + 1) = 3 Transport-type: tcp Bricks: Brick1: 192.168.50.1:/rhgs/brick1/vmstore Brick2:

+ Ambarish On 07/11/2017 02:31 PM, Jo Goossens wrote: > Hello, > > > > > > We tried tons of settings to get a php app running on a native gluster > mount: > > > > e.g.: 192.168.140.41:/www /var/www glusterfs > defaults,_netdev,backup-volfile-servers=192.168.140.42:192.168.140.43,direct-io-mode=disable > 0 0 > > > > I tried some mount variants

Hello, ? ? We tried tons of settings to get a php app running on a native gluster mount: ? e.g.:?192.168.140.41:/www /var/www glusterfs defaults,_netdev,backup-volfile-servers=192.168.140.42:192.168.140.43,direct-io-mode=disable 0 0 ? I tried some mount variants in order to speed up things without luck. ? ? After that I tried nfs (native gluster nfs 3 and ganesha nfs 4), it was a crazy

Hello Atin, ? ? Could you confirm this should have been fixed in 3.10.8? If so we'll test it for sure! Regards Jo ? ? -----Original message----- From:Atin Mukherjee <amukherj at redhat.com> Sent:Mon 30-10-2017 17:40 Subject:Re: [Gluster-users] BUG: After stop and start wrong port is advertised To:Jo Goossens <jo.goossens at hosted-power.com>; CC:gluster-users at

On Sat, 2 Dec 2017 at 19:29, Jo Goossens <jo.goossens at hosted-power.com> wrote: > Hello Atin, > > > > > > Could you confirm this should have been fixed in 3.10.8? If so we'll test > it for sure! > Fix should be part of 3.10.8 which is awaiting release announcement. > > Regards > > Jo > > > > > > > -----Original

The patch was definitely there in 3.12.3. Do you have the glusterd and brick logs handy with you when this happened? On Sun, Jan 21, 2018 at 10:21 PM, Alan Orth <alan.orth at gmail.com> wrote: > For what it's worth, I just updated some CentOS 7 servers from GlusterFS > 3.12.1 to 3.12.4 and hit this bug. Did the patch make it into 3.12.4? I had > to use Mike Hulsman's

3.10 doesn't have this regression, so you're safe. On Tue, Jan 23, 2018 at 1:28 PM, Jo Goossens <jo.goossens at hosted-power.com> wrote: > Hello, > > > > > > Will we also suffer from this regression in any of the (previously) fixed > 3.10 releases? We kept 3.10 and hope to stay stable :/ > > > > Regards > > Jo > > > > > >

On Sat, 28 Oct 2017 at 02:36, Jo Goossens <jo.goossens at hosted-power.com> wrote: > Hello Atin, > > > > > > I just read it and very happy you found the issue. We really hope this > will be fixed in the next 3.10.7 version! > 3.10.7 - no I guess as the patch is still in review and 3.10.7 is getting tagged today. You?ll get this fix in 3.10.8. > > >

For what it's worth, I just updated some CentOS 7 servers from GlusterFS 3.12.1 to 3.12.4 and hit this bug. Did the patch make it into 3.12.4? I had to use Mike Hulsman's script to check the daemon port against the port in the volume's brick info, update the port, and restart glusterd on each node. Luckily I only have four servers! Hoping I don't have to do this every time I

So from the logs what it looks to be a regression caused by commit 635c1c3 ( and the good news is that this is now fixed in release-3.12 branch and should be part of 3.12.5. Commit which fixes this issue: COMMIT: https://review.gluster.org/19146 committed in release-3.12 by \"Atin Mukherjee\" <amukherj at redhat.com> with a commit message- glusterd: connect to an existing brick

Hello Atin, ? ? I just read it and very happy you found the issue. We really hope this will be fixed in the next 3.10.7 version! ? ? PS: Wow nice all that c code and those "goto out" statements (not always considered clean but the best way often I think). Can remember the days I wrote kernel drivers myself in c :) ? ? Regards Jo Goossens ? ? ? -----Original message----- From:Atin