http://www.slony.info/bugzilla/show_bug.cgi?id=235

--- Comment #4 from Christopher Browne <cbbrowne at ca.afilias.info> 2011-08-24 08:02:59 PDT ---
(In reply to comment #3)
> I think the logic behind the "ramping up" is that if the admin says "group at
> most 3000 SYNCs at a time" (sync_group_maxsize) and "i want each run to take
> about 60 seconds" (desired_sync_time), and it turns out that we can process
> about 10 SYNCs per second, then if we just jump straight to 3000 SYNCs, the run
> would take 5 times the recommended maximum duration.
> 
> So the current logic does a small number of SYNCs and then tries to predict
> (based on some implicit assumption that the number of SYNCs varies linearly
> with the duration of the SYNC group) what the ideal number of SYNCs would be to
> hit the desired_sync_time.

That's pretty much right.

We also had a little bit of paranoia about making sure that if there's a
problem at sync #314314 that we replicate at least up to #314313 before giving
up.  That's why it starts by processing 1 SYNC at a time, and ramps up.

> Aside from overflow issues, the big problem with this approach is that the
> number of SYNCs processed per group does *not* necessarily vary linearly with
> the time it takes for the group to be processed.  Or, if it does vary linearly,
> it is with a constant offset that can grow substantially if there are a large
> number of elements in sl_log_1 or sl_log_2.

Quite right, the "linearity" assumption is not particularly valid.  

It's notably invalidated in the case where someone has some huge "UPDATE
some_big_table SET [something] WHERE [most of the tuples in the table]" query;
when this commits, it'll add a *huge* amount of work to one and only one SYNC.

> In my case, with > 8 GiB in sl_log_1, a SYNC group of size 1 takes several
> hundred seconds, and a sync group of size 3000 *also* takes several hundred
> seconds.  (maybe due to the full tablescan of sl_log_1?) 

That SEQ SCAN is a problem, and further invalidates that "linearity
assumption."

I'll note that the SEQ SCAN was recognized and fixed in Bug #167, in version
2.1.  We haven't backpatched because, 2.1 not yet being fully released, there's
not as much feedback on that as we'd like.

> As a result, the estimate of how many SYNCs to process in a group stays low,
> which makes slony take even longer to finish processing its data :(

Yep.

If the Seq Scan issue goes away in 2.1, prior to changes to this algorithm,
then  I think we can treat that as being likely irrelevant.

I'm inclined to revise the logic to get rid of the "desired sync time" part, as
there's something inherently nonsensical to it.

The direction I'm thinking is to have slon do "start with 1, and then quickly
increment towards sync_group_maxsize".  

"How quickly?" is a good question that'll get discussed, for sure.  Another
parameter might be a useful idea, but I'm not sure there's necessarily much 
value to adding configuration knobs.

-- 
Configure bugmail: http://www.slony.info/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
You are the assignee for the bug.