On Sat, Aug 6, 2016 at 6:16 AM, Jan Wieck <j...@wi3ck.info> 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 Slony1-general@lists.slony.info http://lists.slony.info/mailman/listinfo/slony1-general