On 06/06/13 21:22, Jeff Janes wrote:
On Tue, Jun 4, 2013 at 8:36 AM, Federico Campoli
<feder...@brandwatch.com <mailto:feder...@brandwatch.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
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
