testing HS/SR - 1 vs 2 performance
in [PgSql]
|
Prev: pg_ctl stop -m immediate on the primary server inflatessequences
Next: [HACKERS] non-reproducible failure of random test on HEAD
From: Simon Riggs on 26 Apr 2010 03:43 On Sun, 2010-04-25 at 23:52 +0200, Erik Rijkers wrote: > I'll try to repeat this pattern on other hardware; although > if my tests were run with faulty hardware I wouldn't know how/why > that would give the above effect (such a 'regular aberration'). > testing is more difficult than I thought... Thanks again for your help. Please can you confirm: * Are the standby tests run while the primary is completely quiet? * What OS is this? Can we use dtrace scripts? Can anyone else confirm these test results: large scale factor and small number of sessions? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Erik Rijkers" on 26 Apr 2010 11:01 On Mon, April 26, 2010 08:52, Fujii Masao wrote: > On Mon, Apr 26, 2010 at 3:25 AM, Erik Rijkers <er(a)xs4all.nl> wrote: >> FWIW, here are some more results from pgbench comparing >> primary and standby (both with Simon's patch). > > Was there a difference in CPU utilization between the primary > and standby? > I haven't monitored it.. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "Erik Rijkers" on 26 Apr 2010 11:04 On Mon, April 26, 2010 09:43, Simon Riggs wrote: > On Sun, 2010-04-25 at 23:52 +0200, Erik Rijkers wrote: > >> I'll try to repeat this pattern on other hardware; although >> if my tests were run with faulty hardware I wouldn't know how/why >> that would give the above effect (such a 'regular aberration'). > >> testing is more difficult than I thought... > > Thanks again for your help. > > Please can you confirm: > * Are the standby tests run while the primary is completely quiet? autovacuum was on. Which is probably not a good idea - I'll try a few runs without it. > * What OS is this? Can we use dtrace scripts? Centos 5.4. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 26 Apr 2010 22:35 On Sun, 2010-04-25 at 13:51 -0400, Tom Lane wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: > > On Sun, 2010-04-25 at 13:33 -0400, Tom Lane wrote: > >> If you like I'll have a go at rewriting the comments for this patch, > >> because I am currently thinking that the problem is not so much with > >> the code as with the poor explanation of what it's doing. Sometimes > >> the author is too close to the code to understand why other people > >> have a hard time understanding it. > > > That would help me, thank you. > > OK. You said you were currently working some more on the patch, so > I'll wait for v3 and then work on it. v3 attached Changes: * Strange locking in KnownAssignedXidsAdd() moved to RecordKnown... * KnownAssignedXidsAdd() reordered, assert-ish code added * Tail movement during snapshots no longer possible * Tail movement during xid removal added to KnownAssignedXidsSearch() * Major comment hacking Little bit rough, definitely needs a re-read of all comments, so good time to send over. -- Simon Riggs www.2ndQuadrant.com
From: Tom Lane on 26 Apr 2010 22:37
Simon Riggs <simon(a)2ndQuadrant.com> writes: > v3 attached Thanks, will work on this tomorrow. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |