Home > Archive > Slony1 PostgreSQL Replication > August 2005 > Slow catchup









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Slow catchup
Marc Munro

2005-08-15, 8:25 pm

____________________
____________________
_______
Slony1-general mailing list
Slony1-general- AuKwsB3Fm+ugFIWk8tvy
RWD2FQJk+8+b@public.gmane.org
http://gborg.postgresql.org/mailman.../slony1-general

Brad Nicholson

2005-08-16, 1:27 pm

Marc Munro wrote:

>I'm having trouble with a subscriber failing to catch up with a
>provider. I have just performed a sync which succeeded with no problem.
>Initially after the sync, about 4 minutes worth a provider updates were
>being processed per minute at the subscriber.
>
>Now it is down to less than a tenth of the speed of the provider. The
>subscriber machine itself is running mostly idle.
>
>What can I look for in order to track down this problem?
>
>


A few things:

1) Have a look at pg_stat_activity on the subscriber and see what's
going on with the database. Slony doesn't like 'idle in transacation'
transacations (they cause the pg_listener). Look for anything else out
of the ordinary, like long running transactions.

2) On the subscriber, try
VACUUM ANALYZE VERBOSE pg_listener;
And have a look at the output. pg_listener bloat can cause the replicas
to fall behind. You may have to kill off some connections to get the
vacuum to actaully do anything.

3)Again, on the subscriber, run
VACUUM ANALYZE VERBOSE _clustername.sl_log_1;

I've seen replica's fall behind due to a heavily bloated index on sl_log_1

4)Are you vacumming your subsciber?

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.
Sponsored Links





Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive | Programming forum archive

Copyright 2008 droptable.com