<br><br>
<div class="gmail_quote">On Tue, Jun 15, 2010 at 1:15 PM, Brad Nicholson <span dir="ltr"><<a href="mailto:bnichols@ca.afilias.info">bnichols@ca.afilias.info</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Mon, 2010-06-14 at 20:24 -0300, Hernan Saltiel wrote:<br>> Thanks, Scott & Steve for this clues!<br>> My situation is not the PgSQL 8.0.x one, I have 8.4.x x64 installed,<br>> and the replication schema uses an internet connection between two<br>
> DB's, a master & a slave.<br>> Sometimes, the replication seems to stop working, I'm trying to figure<br>> out what's wrong, if there is something.<br>> I'll start a shell script right now to check the master & slave<br>
> systems based on the clues you sent.<br>> Thanks again, and best regards,<br><br></div>Does your application do any commits where you are writing a lots of<br>data in a single transaction like batch inserts, deleting large tables<br>
or updating a lot of rows?<br></blockquote>
<div> </div>
<div>Yes, it does!</div>
<div>We're working to insert massive records, almos 1 millon in a single batch.</div>
<div>This is why I'm concerned about performance issues.</div>
<div>Thanks a lot, and best regards,</div>
<div> </div>
<div>HeCSa.</div>
<div> </div>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div>
<div></div>
<div class="h5"><br><br>><br>> On Mon, Jun 14, 2010 at 6:01 PM, Steve Singer<br>> <<a href="mailto:ssinger@ca.afilias.info">ssinger@ca.afilias.info</a>> wrote:<br>> Hernan Saltiel wrote:<br>><br>
> How can I meassure how much is too much use of my<br>> hardware when Slony is in place?<br>> I can meassure the CPU, memory, disk IO, and network<br>> use, but how much is needed in order to let Slony work<br>
> well?<br>> Is there any way to calculate this on a transaction<br>> number and size basis?<br>> Thanks!<br>><br>><br>> The other thing you should look into is if your having<br>
> performance issues on your database from improper/insufficient<br>> vacuuming. Back in the 8.0 days vacuuming issues where pretty<br>> common (I think 8.0 was before auto-vacuum or at least before<br>
> auto-vacuum got good).<br>><br>> Are your application tables bloated?<br>> Are your slony tables bloated?<br>> Are your vacuum processes taking a long time?<br>> If your've had vacuum issues in the past have you exceeded the<br>
> size you've allocated to the free-space map.<br>><br>> Vacuuming the entire database through a single "VACUUM"<br>> command launched from cron is somtimes not the best approach,<br>
> sometimes you need to issue individual vacuum commands on a<br>> per table basis where some tables get hit frequently (maybe a<br>> few times an hour) while others might only get vacuumed once a<br>
> week. It all depends on the acccess patterns to the tables<br>> and with older versions of postgresql the DBA is often left to<br>> figure this out on their own.<br>><br>> Also slony should be issuing vacuum commands against the slony<br>
> tables so you probably don't want 'other' vacuum commands that<br>> regularly get run to duplicate the work.<br>><br>><br>><br>><br>><br>><br>><br>> > Can someone point me where should i look into<br>
> and how to improve<br>> replication<br>> > performance.<br>><br>> More / faster drives and controllers.<br>><br>> > As of now there is no chance for upgradation of<br>
> version.<br>><br>> That would be the first thing I'd recommend. Since<br>> you can't do it,<br>> you're gonna have to have faster hardware,<br>
> specifically the IO<br>> subsystem.<br>> _______________________________________________<br>> Slony1-general mailing list<br>><br>> <a href="mailto:Slony1-general@lists.slony.info">Slony1-general@lists.slony.info</a><br>
> <mailto:<a href="mailto:Slony1-general@lists.slony.info">Slony1-general@lists.slony.info</a>><br>><br>><br>> <a href="http://lists.slony.info/mailman/listinfo/slony1-general" target="_blank">http://lists.slony.info/mailman/listinfo/slony1-general</a><br>
><br>><br>><br>><br>> --<br>> HeCSa<br>><br>><br>><br>> ------------------------------------------------------------------------<br>><br>><br>
> _______________________________________________<br>> Slony1-general mailing list<br>> <a href="mailto:Slony1-general@lists.slony.info">Slony1-general@lists.slony.info</a><br>
> <a href="http://lists.slony.info/mailman/listinfo/slony1-general" target="_blank">http://lists.slony.info/mailman/listinfo/slony1-general</a><br>><br>><br>><br>> --<br>> Steve Singer<br>
> Afilias Canada<br>> Data Services Developer<br>> 416-673-1142<br>><br>><br>><br>> --<br>> HeCSa<br>> _______________________________________________<br>> Slony1-general mailing list<br>
> <a href="mailto:Slony1-general@lists.slony.info">Slony1-general@lists.slony.info</a><br>> <a href="http://lists.slony.info/mailman/listinfo/slony1-general" target="_blank">http://lists.slony.info/mailman/listinfo/slony1-general</a><br>
--<br></div></div><font color="#888888">Brad Nicholson 416-673-4106<br>Database Administrator, Afilias Canada Corp.<br><br><br></font></blockquote></div><br><br clear="all"><br>-- <br>HeCSa<br>