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/f4d7529e/attachment.htm>
