Re: testing HS/SR - 1 vs 2 performance

From: Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz>
To: Erik Rijkers <er(at)xs4all(dot)nl>
Cc: Simon Riggs <simon(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: testing HS/SR - 1 vs 2 performance
Date: 2010-04-23 00:44:11
Message-ID: 4BD0ED5B.8040104@catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Erik Rijkers wrote:
>
> This is the same behaviour (i.e. extreme slow standby) that I saw earlier (and which caused the
> original post, btw). In that earlier instance, the extreme slowness disappeared later, after many
> hours maybe even days (without bouncing either primary or standby).
>
> I have no idea what could cause this; is no one else is seeing this ?
>
> (if I have time I'll repeat on other hardware in the weekend)
>
> any comment is welcome...
>
>
>

I wonder if what you are seeing is perhaps due to the tables on the
primary being almost completely cached (from the initial create) and
those on the standby being at best partially so. That would explain why
the standby performance catches up after a while ( when its tables are
equivalently cached).

One way to test this is to 'pre-cache' the standby by selecting every
row from its tables before running the pgbench test.

regards

Mark

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-04-23 00:45:30 why do we have rd_istemp?
Previous Message Fujii Masao 2010-04-23 00:03:43 Re: recovery_connections cannot start (was Re: master in standby mode croaks)