From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
---|---|
To: | PostgreSQL - Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
Cc: | Boszormenyi Zoltan <zb(at)cybertec(dot)at>, Antonin Houska <antonin(dot)houska(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Backup throttling |
Date: | 2013-08-21 08:57:15 |
Message-ID: | 20130821085715.GA5185@awork2.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2013-08-21 08:10:42 +0200, PostgreSQL - Hans-Jürgen Schönig wrote:
>
> On Aug 19, 2013, at 9:11 PM, Andres Freund wrote:
>
> > On 2013-08-19 20:15:51 +0200, Boszormenyi Zoltan wrote:
> >> 2013-08-19 19:20 keltezéssel, Andres Freund írta:
> >>> Hi,
> >>>
> >>> On 2013-07-24 09:20:52 +0200, Antonin Houska wrote:
> >>>> Hello,
> >>>> the purpose of this patch is to limit impact of pg_backup on running server.
> >>>> Feedback is appreciated.
> >>> Based on a quick look it seems like you're throttling on the receiving
> >>> side. Is that a good idea? Especially over longer latency links, TCP
> >>> buffering will reduce the effect on the sender side considerably.
> >
> >> Throttling on the sender side requires extending the syntax of
> >> BASE_BACKUP and maybe START_REPLICATION so both can be
> >> throttled but throttling is still initiated by the receiver side.
> >
> > Seems fine to me. Under the premise that the idea is decided to be
> > worthwile to be integrated. Which I am not yet convinced of.
>
> i think there is a lot of value for this one. the scenario we had a couple of times is pretty simple:
> just assume a weak server - maybe just one disk or two - and a slave.
> master and slave are connected via a 1 GB network.
> pg_basebackup will fetch data full speed basically putting those lonely disks out of business.
> we actually had a case where a client asked if "PostgreSQL is locked during base backup". of
> course it was just disk wait caused by a full speed pg_basebackup.
> regarding the client side implementation: we have chosen this way because it is less invasive.
> i cannot see a reason to do this on the server side because we won't have 10
> pg_basebackup-style tools making use of this feature anyway.
The problem is that receiver side throttling over TCP doesn't always
work all that nicely unless you have a low rate of transfer and/or very
low latency . Quite often you will have OS buffers/the TCP Window being
filled in bursts where the sender sends at max capacity and then a
period where nothing happens on the sender. That's often not what you
want when you need to throttle.
Besides, I can see some value in e.g. normal streaming replication also
being rate limited...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Vik Fearing | 2013-08-21 10:32:20 | Re: [BUGS] BUG #8335: trim() un-document behaviour |
Previous Message | PostgreSQL - Hans-Jürgen Schönig | 2013-08-21 06:10:42 | Re: Backup throttling |