Re: [Gluster-devel] Throttling xlator on the bricks

2016-02-26 Thread Ravishankar N
016 11:15 PM To: Shreyas Siravara Cc: Richard Wareing; Vijay Bellur; Gluster Devel Subject: Re: [Gluster-devel] Throttling xlator on the bricks Hello, On 01/29/2016 06:51 AM, Shreyas Siravara wrote: So the way our throttling works is (intentionally) very simplistic. (1) When someone mounts an NFS s

Re: [Gluster-devel] Throttling xlator on the bricks

2016-02-12 Thread Richard Wareing
ned intentries_processed; unsigned intalready_healed; Richard From: Ravishankar N [ravishan...@redhat.com] Sent: Sunday, February 07, 2016 11:15 PM To: Shreyas Siravara Cc: Richard Wareing; Vijay Bellur; Gluster Devel Subject: R

Re: [Gluster-devel] Throttling xlator on the bricks

2016-02-12 Thread Pranith Kumar Karampuri
edhat.com] Sent: Sunday, February 07, 2016 11:15 PM To: Shreyas Siravara Cc: Richard Wareing; Vijay Bellur; Gluster Devel Subject: Re: [Gluster-devel] Throttling xlator on the bricks Hello, On 01/29/2016 06:51 AM, Shreyas Siravara wrote: So the way our throttling works is (intentionally) very

Re: [Gluster-devel] Throttling xlator on the bricks

2016-02-07 Thread Ravishankar N
Hello, On 01/29/2016 06:51 AM, Shreyas Siravara wrote: So the way our throttling works is (intentionally) very simplistic. (1) When someone mounts an NFS share, we tag the frame with a 32 bit hash of the export name they were authorized to mount. (2) io-stats keeps track of the "current rate"

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-28 Thread Shreyas Siravara
So the way our throttling works is (intentionally) very simplistic. (1) When someone mounts an NFS share, we tag the frame with a 32 bit hash of the export name they were authorized to mount. (2) io-stats keeps track of the "current rate" of fops we're seeing for that particular mount, using a

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-28 Thread Jeff Darcy
> TBF isn't complicated at all - it's widely used for traffic shaping, cgroups, > UML to rate limit disk I/O. It's not complicated and it's widely used, but that doesn't mean it's the right fit for our needs. Token buckets are good to create a *ceiling* on resource utilization, but what if you

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-27 Thread Ravishankar N
On 01/26/2016 08:41 AM, Richard Wareing wrote: In any event, it might be worth having Shreyas detail his throttling feature (that can throttle any directory hierarchy no less) to illustrate how a simpler design can achieve similar results to these more complicated (and it followsbug

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-27 Thread Raghavendra Bhat
There is already a patch submitted for moving TBF part to libglusterfs. It is under review. http://review.gluster.org/#/c/12413/ Regards, Raghavendra On Mon, Jan 25, 2016 at 2:26 AM, Venky Shankar wrote: > On Mon, Jan 25, 2016 at 11:06:26AM +0530, Ravishankar N wrote: > >

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Joe Julian
On 01/25/16 18:24, Ravishankar N wrote: On 01/26/2016 01:22 AM, Shreyas Siravara wrote: Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)? For

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Pranith Kumar Karampuri
On 01/26/2016 08:14 AM, Vijay Bellur wrote: On 01/25/2016 12:36 AM, Ravishankar N wrote: Hi, We are planning to introduce a throttling xlator on the server (brick) process to regulate FOPS. The main motivation is to solve complaints about AFR selfheal taking too much of CPU resources. (due

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Venky Shankar
t: Monday, January 25, 2016 6:44 PM > To: Ravishankar N; Gluster Devel > Subject: Re: [Gluster-devel] Throttling xlator on the bricks > > On 01/25/2016 12:36 AM, Ravishankar N wrote: > > Hi, > > > > We are planning to introduce a throttling xlator on the server (bric

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Joe Julian
16 6:44 PM To: Ravishankar N; Gluster Devel Subject: Re: [Gluster-devel] Throttling xlator on the bricks On 01/25/2016 12:36 AM, Ravishankar N wrote: Hi, We are planning to introduce a throttling xlator on the server (brick) process to regulate FOPS. The main motivation is to solve complaints about AFR selfh

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Shreyas Siravara
Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)? > On Jan 25, 2016, at 12:29 AM, Venky Shankar wrote: > > On Mon, Jan 25, 2016

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Venky Shankar
On Mon, Jan 25, 2016 at 01:08:38PM +0530, Ravishankar N wrote: > On 01/25/2016 12:56 PM, Venky Shankar wrote: > >Also, it would be beneficial to have the core TBF implementation as part of > >libglusterfs so as to be consumable by the server side xlator component to > >throttle dispatched FOPs and

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Ravishankar N
On 01/26/2016 01:22 AM, Shreyas Siravara wrote: Just out of curiosity, what benefits do we think this throttling xlator would provide over the "enable-least-priority" option (where we put all the fops from SHD, etc into a least pri queue)? For one, it could provide more granularity on

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Vijay Bellur
On 01/25/2016 12:36 AM, Ravishankar N wrote: Hi, We are planning to introduce a throttling xlator on the server (brick) process to regulate FOPS. The main motivation is to solve complaints about AFR selfheal taking too much of CPU resources. (due to too many fops for entry self-heal, rchecksums

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-25 Thread Richard Wareing
bug prone) approaches. Richard From: gluster-devel-boun...@gluster.org [gluster-devel-boun...@gluster.org] on behalf of Vijay Bellur [vbel...@redhat.com] Sent: Monday, January 25, 2016 6:44 PM To: Ravishankar N; Gluster Devel Subject: Re: [Gluster-devel] T

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-24 Thread Venky Shankar
On Mon, Jan 25, 2016 at 11:06:26AM +0530, Ravishankar N wrote: > Hi, > > We are planning to introduce a throttling xlator on the server (brick) > process to regulate FOPS. The main motivation is to solve complaints about > AFR selfheal taking too much of CPU resources. (due to too many fops for >

[Gluster-devel] Throttling xlator on the bricks

2016-01-24 Thread Ravishankar N
Hi, We are planning to introduce a throttling xlator on the server (brick) process to regulate FOPS. The main motivation is to solve complaints about AFR selfheal taking too much of CPU resources. (due to too many fops for entry self-heal, rchecksums for data self-heal etc.) The throttling is

Re: [Gluster-devel] Throttling xlator on the bricks

2016-01-24 Thread Ravishankar N
On 01/25/2016 12:56 PM, Venky Shankar wrote: Also, it would be beneficial to have the core TBF implementation as part of libglusterfs so as to be consumable by the server side xlator component to throttle dispatched FOPs and for daemons to throttle anything that's outside "brick" boundary (such