[Gluster-users] Improving afr performance

[Raghavendra G]

On Sat, Nov 21, 2009 at 1:23 AM, Pablo Godel <pablo.godel at gmail.com> wrote:

> What are the downsides of using performance improving translators ?


While there may not be any significant performance decreases, its just that
you will be adding an extra software layer in the path of processing a call.
For example,
* If applications are not issuing any re-reads and  io-cache is loaded,
there will be memory consumed by io-cache to cache  data which is not
required at all.
* If the applications are not reading the files at all and quick-read is
loaded, memory used by quick-read to store the files is an overhead.
* If the application is just doing random reads and read-ahead is loaded,
you are bound to incur memory overhead in storing the extra data which is
read in hope of application issuing sequential reads.
* If stat-prefetch is loaded and the application is not interested in doing
stat on the files after reading a directory, memory consumed to cache
directory entries is an extra overhead.

Glusterfs has performance translators which are designed for various
functionalities and based on your application needs, you should configure
appropriate translators.


> There has to be some, or otherwise why not have them on by default?
>
> Thanks
> Pablo
>
> On Fri, Nov 20, 2009 at 3:50 PM, Raghavendra G <raghavendra.hg at gmail.com>wrote:
>
>> On Fri, Nov 20, 2009 at 10:35 AM, Paras Fadte <plfgoa at gmail.com> wrote:
>>
>> > Hi Vikas,
>> >
>> > Thanks for the response.
>> >
>> > I am having performance issues upon migration to gluster. Follwoing
>> > should explain the issue.
>> >
>> > There are scripts running which access data from the gluster mount
>> > point . Earlier NFS was used . With NFS the scripts seem to have no
>> > problem getting completed faster but when same scripts run accessing
>> > same data from gluster  it runs about 3-4 times  slower .  Mostly the
>> > scripts do stat/unlinking/renaming operations on files. Number of
>> > files would be roughly 25k withe average file size 40KB . What can be
>> > done to increase the speed/performance ?
>> >
>>
>> If you are doing only operations like stat which modify metadata, without
>> reading or writing, stat-prefetch should be enough. If you are reading
>> files, you can try quick-read, since your file sizes happen to be smaller.
>> And if you are re-reading you can try io-cache. If you are writing to
>> files,
>> write-behind should help.
>>
>>
>> >
>> > Regarding stat-prefetch is the following usage correct ?
>> >
>> > volume afr
>> >  type cluster/replicate
>> >  subvolumes A B
>> > end-volume
>> >
>> > volume stat-prefetch
>> >  type performance/stat-prefetch
>> >  subvolumes afr
>> > end-volume
>> >
>>
>> yes.
>>
>>
>> >
>> > Thank you.
>> >
>> > -Paras
>> >
>> >
>> > On Fri, Nov 20, 2009 at 1:42 AM, Vikas Gorur <vikas at gluster.com> wrote:
>> > > Paras Fadte wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> Which  settings in AFR in  gluster directly affects performance when
>> > >> there are lots of "ls" and "stat" calls made on files mounted using
>> > >> gluster?
>> > >>
>> > >>
>> > >
>> > > There isn't any setting in afr that can affect ls or stat performance.
>> > You
>> > > can load
>> > > the stat-prefetch translator above afr to increase ls/stat
>> performance.
>> > >
>> > > Vikas
>> > >
>> > >
>> > _______________________________________________
>> > Gluster-users mailing list
>> > Gluster-users at gluster.org
>> > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>> >
>>
>>
>>
>> --
>> Raghavendra G
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>>
>>
>

regards,
-- 
Raghavendra G