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
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
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
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"
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
> 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
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
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:
> >
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
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
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
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
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
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
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
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
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
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
>
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
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
20 matches
Mail list logo