[Gluster-users] Gluster performance is paramount!

Karan Sandha ksandha at redhat.com
Mon Feb 27 09:14:25 UTC 2017


Hi Ernie,

For small-files, there are few tunables you would go for a good performance.

first stop the volume and then set the below parameters:-

**

*gluster volume set *<volname>* cluster.lookup-optimize on*

*

gluster volume set **<volname>** server.event-threads 4

gluster volume set **<volname>** client.event-threads 4

*

Start the volume and do a rebalance on the volume using :- gluster 
volume rebalance <volname> start ; check the status using the gluster 
volume rebalance <volname> status . you will be seeing a bump in 
performance of small files workload.

Thanks & Regards
Karan Sandha




On 02/25/2017 02:46 PM, Vahric Muhtaryan wrote:
> Hello Ernie ,
>
> Actually why not really set it Raid0 also for mail server raid10 
> should be fine , you can do it both .
> Actually I m not real gluster user but just only tried for vm 
> instances . I find from blogs fro small io you should also care and 
> tune about LOOKUP issues
> One more actually I don’t know how you are handling HA but with 
> glusterfs but I believe that if you are not using NFS Ganesha you have 
> single point of failure everytime , isn't it ?
>
> Regards
> VM
>
> From: <gluster-users-bounces at gluster.org 
> <mailto:gluster-users-bounces at gluster.org>> on behalf of Ernie Dunbar 
> <maillist at lightspeed.ca <mailto:maillist at lightspeed.ca>>
> Date: Friday, 24 February 2017 at 22:36
> To: Gluster-users <gluster-users at gluster.org 
> <mailto:gluster-users at gluster.org>>
> Subject: **SPAM** [Gluster-users] Gluster performance is paramount!
>
> Hi everyone!
>
> We have a gluster array of three servers supporting a large mail 
> server with about 10,000 e-mail accounts with the Maildir file format. 
> This means lots of random small file reads and writes. Gluster's 
> performance hasn't been great since we switched to it from a local 
> disk on a single server, but we're aiming for high availability here, 
> since simply restoring that mail from backups (or even backing it up 
> in the first place) takes a day or two. Clearly, some kind of network 
> drive is what we need, and Gluster does the job better than every 
> other solution we've looked at so far.
>
> The problem comes from the fact that when I set out on this project, 
> I'd never done any kind of performance tuning before. We didn't need 
> it. All three of our Gluster servers are set up in a RAID5 array with 
> a hot spare. I'm starting to think that the performance woes we have 
> all stem from this fact, and speaking to one of my colleagues, it was 
> suggested that Gluster can handle the data integrity just fine on its 
> own, so why don't we just switch to the fastest possible type, RAID0 
> and completely toss out any data integrity on each individual node in 
> the cluster?
>
> While this sounds good in theory, I'd like to know how well this works 
> in practice before subjecting our 10,000 e-mail clients to this 
> experiment. The other possibility is to switch our Gluster nodes to 
> RAID1 or 10, which might be faster than RAID5 while still keeping some 
> semblance of data integrity.
>
> _______________________________________________ Gluster-users mailing 
> list Gluster-users at gluster.org <mailto:Gluster-users at gluster.org> 
> http://lists.gluster.org/mailman/listinfo/gluster-users
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20170227/beba3e47/attachment.html>


More information about the Gluster-users mailing list