On Mon, 2010-06-14 at 20:24 -0300, Hernan Saltiel wrote:
> Thanks, Scott & Steve for this clues!
> My situation is not the PgSQL 8.0.x one, I have 8.4.x x64 installed,
> and the replication schema uses an internet connection between two
> DB's, a master & a slave.
> Sometimes, the replication seems to stop working, I'm trying to figure
> out what's wrong, if there is something.
> I'll start a shell script right now to check the master & slave
> systems based on the clues you sent.
> Thanks again, and best regards,

Does your application do any commits where you are writing a lots of
data in a single transaction like batch inserts, deleting large tables
or updating a lot of rows?


>  
> On Mon, Jun 14, 2010 at 6:01 PM, Steve Singer
> <ssinger at ca.afilias.info> wrote:
>         Hernan Saltiel wrote:
>                 
>                 How can I meassure how much is too much use of my
>                 hardware when Slony is in place?
>                 I can meassure the CPU, memory, disk IO, and network
>                 use, but how much is needed in order to let Slony work
>                 well?
>                 Is there any way to calculate this on a transaction
>                 number and size basis?
>                 Thanks!
>         
>         
>         The other thing you should look into is if your having
>         performance issues on your database from improper/insufficient
>         vacuuming.  Back in the 8.0 days vacuuming issues where pretty
>         common (I think 8.0 was before auto-vacuum or at least before
>         auto-vacuum got good).
>         
>         Are your application tables bloated?
>         Are your slony tables bloated?
>         Are your vacuum processes taking a long time?
>         If your've had vacuum issues in the past have you exceeded the
>         size you've allocated to the free-space map.
>         
>         Vacuuming the entire database through a single "VACUUM"
>         command launched from cron is somtimes not the best approach,
>         sometimes you need to issue individual vacuum commands on a
>         per table basis where some tables get hit frequently (maybe a
>         few times an hour) while others might only get vacuumed once a
>         week.   It all depends on the acccess patterns to the tables
>         and with older versions of postgresql the DBA is often left to
>         figure this out on their own.
>         
>         Also slony should be issuing vacuum commands against the slony
>         tables so you probably don't want 'other' vacuum commands that
>         regularly get run to duplicate the work.
>         
>         
>         
>         
>         
>                  
>                 
>                     > Can someone point me where should i look into
>                 and how to improve
>                    replication
>                     > performance.
>                 
>                    More / faster drives and controllers.
>                 
>                     > As of now there is no chance for upgradation of
>                 version.
>                 
>                    That would be the first thing I'd recommend.  Since
>                 you can't do it,
>                    you're gonna have to have faster hardware,
>                 specifically the IO
>                    subsystem.
>                    _______________________________________________
>                    Slony1-general mailing list
>                 
>                    Slony1-general at lists.slony.info
>                 <mailto:Slony1-general at lists.slony.info> 
>                 
>                 
>                  http://lists.slony.info/mailman/listinfo/slony1-general
>                 
>                 
>                 
>                 
>                 -- 
>                 HeCSa
>                 
>                 
>                 
>                 ------------------------------------------------------------------------ 
>                 
>                 
>                 _______________________________________________
>                 Slony1-general mailing list
>                 Slony1-general at lists.slony.info
>                 http://lists.slony.info/mailman/listinfo/slony1-general
>                 
>         
>         
>         -- 
>         Steve Singer
>         Afilias Canada
>         Data Services Developer
>         416-673-1142
> 
> 
> 
> -- 
> HeCSa
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
-- 
Brad Nicholson  416-673-4106
Database Administrator, Afilias Canada Corp.