[Gluster-users] Very slow ls - WARNING

[Franco Broi]

All the client filesystems core-dumped. Lost a lot of production time.

I've disabled the cluster.readdir-optimize option and remounted all the filesystems.
________________________________________
From: gluster-users-bounces at gluster.org [gluster-users-bounces at gluster.org] on behalf of Franco Broi [Franco.Broi at iongeo.com]
Sent: Friday, February 21, 2014 10:57 PM
To: Vijay Bellur
Cc: gluster-users at gluster.org
Subject: Re: [Gluster-users] Very slow ls

Amazingly setting cluster.readdir-optimize has fixed the problem, ls is still slow but there's no long pause on the last readdir call.

What does this option do and why isn't it enabled by default?
_______________________________________
From: gluster-users-bounces at gluster.org [gluster-users-bounces at gluster.org] on behalf of Franco Broi [Franco.Broi at iongeo.com]
Sent: Friday, February 21, 2014 7:25 PM
To: Vijay Bellur
Cc: gluster-users at gluster.org
Subject: Re: [Gluster-users] Very slow ls

On 21 Feb 2014 22:03, Vijay Bellur <vbellur at redhat.com> wrote:
>
> On 02/18/2014 12:42 AM, Franco Broi wrote:
> >
> > On 18 Feb 2014 00:13, Vijay Bellur <vbellur at redhat.com> wrote:
> >  >
> >  > On 02/17/2014 07:00 AM, Franco Broi wrote:
> >  > >
> >  > > I mounted the filesystem with trace logging turned on and can see that
> >  > > after the last successful READDIRP there is a lot of other connections
> >  > > being made the clients repeatedly which takes minutes to complete.
> >  >
> >  > I did not observe anything specific which points to clients repeatedly
> >  > reconnecting. Can you point to the appropriate line numbers for this?
> >  >
> >  > Can you also please describe the directory structure being referred here?
> >  >
> >
> > I was tailing the log file while the readdir script was running and
> > could see respective READDIRP calls for each readdir, after the last
> > call all the rest of the stuff in the log file was returning nothing but
> > took minutes to complete. This particular example was a directory
> > containing a number of directories, one for each of the READDIRP calls
> > in the log file.
> >
>
> One possible tuning that can possibly help:
>
> volume set <volname> cluster.readdir-optimize on
>
> Let us know if there is any improvement after enabling this option.

I'll give it a go but I think this is a bug and not a performance issue. I've filed a bug report on bugzilla.

>
> Thanks,
> Vijay
>
>

________________________________


This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.

________________________________


This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.

_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users

________________________________


This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify the sender and delete the original.