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
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) |