On Sat, Aug 6, 2016 at 6:16 AM, Jan Wieck <[email protected]> wrote:
> How are you monitoring the number of rows in the sl_log_* tables?
>
>
> Jan
>
>
I've got a couple of updates but first let me answer the question.
max => "SHOW max_connections",
cur => "SELECT COUNT(*) FROM pg_stat_activity",
log1 => "SELECT COUNT(*) FROM _cls.sl_log_1",
log2 => "SELECT COUNT(*) FROM _cls.sl_log_2",
siz1 => "SELECT (relpages*8) FROM pg_class where relname='sl_log_1'",
siz2 => "SELECT (relpages*8) FROM pg_class where relname='sl_log_2'"
We have a script that runs and monitors a few things in the dB, one is the
count of sl_log_1 and 2. This is added as an RRD
and graphed.
Now the update, graph above , is what we have been seeing, logs grow up
until 10:50am or so when the truncate is allowed (now backups are complete
at 4am and all heavy lifting is finished at 5am)
[image: idb01.gc - slonyTables]
I disabled the full backup on the standby unit last night.
[image: idb01.gc - slonyTables]
I still get some peeks and valleys, but the system is not backed up for 10
hours. So this tells me that the backup on the standby is causing a
situation where slon is blocked because tables are locked on the standby
unit. This is still not ideal but it's a big improvement from before where
the sl_log_? would grow to 14million rows from about 2am to 10:45am..
So I need to figure out how to reduce the overhead of the backup, I figured
it was better to run it on the standby but at this point that is not
looking like a great option..
Thanks for working on this with me!
Tory
_______________________________________________
Slony1-general mailing list
[email protected]
http://lists.slony.info/mailman/listinfo/slony1-general
