Thanks scott ...

This time we will track why it's been slow ..

Thanks,
Dinesh..

On Sat, Jun 9, 2012 at 4:40 AM, Scott Marlowe <scott.marlowe at gmail.com>wrote:

> On Fri, Jun 8, 2012 at 3:30 PM, dinesh kumar <dineshkumar02 at gmail.com>
> wrote:
> > Hi Steve,
> >
> > Thank you for the e-mail ..
> >
> > On Sat, Jun 9, 2012 at 1:39 AM, Steve Singer <ssinger at ca.afilias.info>
> > wrote:
> >>
> >> On 12-06-08 02:50 PM, dinesh kumar wrote:
> >>>
> >>> Thank you so much Steve ...
> >>>
> >>> We are using Slony 2.1.x ... We are still at the initial stage only...
> >>> Slony is still trying to copy the data from source to destination host
> ..
> >>>
> >>>  >> Has your initial copy_set finished?
> >>>
> >>> Here only, we are facing problem... Slony struggling to copy the data
> ..
> >>> It went well upto 140 GB. From 141GB onwards  the build started slow..
> >>> Now it's very very very slow ...
> >>>
> >>> Let me know if you need any configurations what we have used ...
> >>>
> >>
> >> Are you doing this copy over a WAN?
> >
> >
> > We are doing copy over LAN.. We got very good transfer rate for up to
> some
> > extent.. From after some time (i'm not sure the exact time), the build
> got
> > slow..
>
> We need to know why.
>
> >> Can you tell what the bottleneck is? Are you IO bound on the slave? Are
> >> you CPU bound on the slave?
> >>
> > We don't face any performance issues. IO is really good on
> > production(Primary Cluster where it is 3 TB) and having normal CPU
> average
>
> What does iostat -xd 10 or such have to say about the performance on
> the new slony destination when it's slow?
>
> > We think, it's problem from the db itself.. We have around  400GB tables
> (5
> > to 8), those are having huge bloats also.. We think, slony is taking some
> > time to get those live rows bypassing the dead rows from DB. So we think,
> > the actual live rows might scatter to multiple files. I think this might
> be
> > the root cause ..
>
> I doubt bloat in the source database would make things 1GB/hr slow.
> That's only 16MB/minute.
>
> > We just stopped the existing slony setup and will perform vacuum on DB
> once
> > and will do it again ...
>
> Yeah, this time try and figure out what the bottleneck is via iostat,
> vmstat, iotop, nettop, select * from pg_stat_activity and so on.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20120609/bac13a70/attachment-0001.htm