[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