Re: BUG #8192: On very large tables the concurrent update with vacuum lag the hot_standby replica

On 06/06/13 21:22, Jeff Janes wrote:
> On Tue, Jun 4, 2013 at 8:36 AM, Federico Campoli
> <federico(at)brandwatch(dot)com <mailto:federico(at)brandwatch(dot)com>> wrote:
>
>
> This is the gprof output for the profile.
>
>
> This looks to me like the gprof of a process that is either idle, or
> completely IO bound.
>
> I'd probably approach this with a combination of "strace -T -ttt -p
> <PID>" and "lsof -p <PID>" on the PID of the start-up process, to see
> which file descriptors it is waiting for read or writes on, and what the
> underlying names of the files for those file descriptors are.
>
> Cheers,
>
> Jeff

I've generated a strace from the startup process a new profile report
and a new log file.

It's quite big so you can download here

http://d01.megashares.com/dl/BqZLh5H/HS_data_lag.tar

I've monitored the startup process lsof and the only files accessed are
the recovering wal and the relation affected by the master's activity.

Regarding the warm standby, I've repeated the test on my sandbox with
the slave in warm standby and I've noticed a replication lag spike.

This does not affect the production,same database version and
architecture from debian package.

If I turn on the hot standby on the failover in 30 minutes accumulates a
several Gigabytes lag. When I switch off the lag disappear.

I can just guess in WS the lag have less impact as the random read
resumes quicker than the HS.

Many thanks
Federico

--
Federico Campoli
Database Administrator brandwatch.com