Or maybe just turn off automatic self-heal if it is possible? If it is, is there some way to still do a manual self heal? --- Carl Boberg Operations Memnon Networks AB Tegn?rgatan 34, SE-113 59 Stockholm Mobile: +46(0)70 467 27 12 www.memnonnetworks.com On Sat, Mar 3, 2012 at 12:09, Carl Boberg <carl.boberg at memnonnetworks.com>wrote: > Im thinking of maybe trying this as a solution to my needs: > > http://community.gluster.org/a/nfs-performance-with-fuse-client-redundancy/ > > > Is that something people on this list would recommend for performance in > my situation, where we use find commands quite a lot on the volumes? Is it > a "supported"/common solution? > > As I understand it this will let me get NFS performance with Gluster > automatic failover in a replicated setup? > > > Cheers > --- > Carl Boberg > Operations > > Memnon Networks AB > Tegn?rgatan 34, SE-113 59 Stockholm > > Mobile: +46(0)70 467 27 12 > www.memnonnetworks.com > > > > On Fri, Mar 2, 2012 at 15:17, Greg Swift <gregswift at gmail.com> wrote: > >> oh... and the majority of that was tested on 3.2.1 on RHEL 5.7 systems. >> We have recently upgraded to 3.2.5 but this did not change noticeably. >> >> On Fri, Mar 2, 2012 at 08:16, Greg Swift <gregswift at gmail.com> wrote: >> >>> I'd like to point out that I've had similar experience to Carl but >>> without the +mtime in my finds and we did try Gluster's NFS. At one point >>> recently I threw together a spreadsheet documenting the differences that >>> also includes details regarding the various things I tried as I compared a >>> direct SAN (our previous environment) to our current Gluster based system, >>> to Gluster's NFS implementation on the same volumes. The most surprising >>> point was that the Gluster NFS did so well. >>> >>> its attached. >>> >>> -greg >>> >>> On Fri, Mar 2, 2012 at 07:17, Carl Boberg < >>> carl.boberg at memnonnetworks.com> wrote: >>> >>>> There are about 4000 files in the dir. >>>> >>>> Ran it again after clearing the caches and now it took over 3 minutes >>>> on the gfs and about 4 seconds on the nfs (this is not gluster nfs but an >>>> old, classic nfs share) >>>> >>>> All clients are centos 5.6 and the 2 servers are centos 6.2 >>>> Runnig Gluster 3.2.5 rpm install with replicate setup from the docs. >>>> >>>> If it is the self heal operation that is the cause of the slowdown is >>>> there away around not triggering it? Or better yet, any custom options to >>>> add to the config to make this kind of find command go a bit quicker? >>>> >>>> Our application read and write files to the volume but we also have a >>>> section for admins in the application that utilizes find and grep to find >>>> specific files by date or content. This tool is vital for problem >>>> solving and if it takes so much more time to do such operations its just >>>> not usable... >>>> >>>> Ideas? >>>> >>>> Cheers >>>> >>>> --- >>>> Carl Boberg >>>> Operations >>>> >>>> Memnon Networks AB >>>> Tegn?rgatan 34, SE-113 59 Stockholm >>>> >>>> Mobile: +46(0)70 467 27 12 >>>> www.memnonnetworks.com >>>> >>>> >>>> >>>> On Fri, Mar 2, 2012 at 11:58, Brian Candler <B.Candler at pobox.com>wrote: >>>> >>>>> On Fri, Mar 02, 2012 at 11:43:27AM +0100, Carl Boberg wrote: >>>>> > time find /mnt/nfs/<datadir> -type f -mtime -2 >>>>> > >>>>> > real 2m0.067s <-- >>>>> > user 0m0.030s >>>>> > sys 0m0.252s >>>>> >>>>> The -mtime -2 is forcing gluster to do a stat() on every file, and this >>>>> makes gluster do a self-heal operation where it needs to access the >>>>> file on >>>>> both volumes: >>>>> >>>>> >>>>> http://www.gluster.org/community/documentation/index.php/Gluster_3.1:_Triggering_Self-Heal_on_Replicate >>>>> http://www.youtube.com/watch?v=AsgtE7Ph2_k >>>>> >>>>> Having said that, 2 minutes seems pretty slow. How many files are >>>>> there in >>>>> total, i.e. without the -mtime filter? >>>>> >>>>> Is it possible the NFS test had the inode data in cache, so was an >>>>> unfair >>>>> comparison? I suggest you do >>>>> echo 3 >/proc/sys/vm/drop_caches >>>>> (as root) on both client and server before each test. >>>>> >>>>> Regards, >>>>> >>>>> Brian. >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Gluster-users mailing list >>>> Gluster-users at gluster.org >>>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://gluster.org/pipermail/gluster-users/attachments/20120303/95222969/attachment-0001.htm>
