Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group