Re: [PERFORM] hardware upgrade, performance degrade?

for the two systems? -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http

Re: [PERFORM] error with invalid page header while vacuuming pgbench data

On Mon, May 23, 2011 at 05:21:04PM -0500, Kevin Grittner wrote: John Rouillard rou...@renesys.com wrote: I seem to be able to provoke this error: vacuum...ERROR: invalid page header in block 2128910 of relation base/16385/21476 What version of PostgreSQL? Hmm, I

Re: [PERFORM] error with invalid page header while vacuuming pgbench data

On Wed, May 25, 2011 at 03:19:59PM -0500, Kevin Grittner wrote: John Rouillard rou...@renesys.com wrote: On Mon, May 23, 2011 at 05:21:04PM -0500, Kevin Grittner wrote: John Rouillard rou...@renesys.com wrote: I seem to be able to provoke this error: vacuum...ERROR: invalid

[PERFORM] error with invalid page header while vacuuming pgbench data

disk wd2003; controller LSI MegaRAID SAS 9260-4i Could it be an ext4 issue? It seems that ext4 may still be at the bleeding edge for postgres use. Thanks for any thoughts even if it's go to the admin list. -- -- rouilj John Rouillard System Administrator

Re: [PERFORM] Using pgiosim realistically

Maybe the completion target percentage is off because of the threads? -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org

Re: [PERFORM] Using pgiosim realistically

On Sat, May 14, 2011 at 12:07:02PM -0500, k...@rice.edu wrote: On Fri, May 13, 2011 at 09:09:41PM +, John Rouillard wrote: I am adding pgiosim to our testing for new database hardware and I am seeing something I don't quite get and I think it's because I am using pgiosim incorrectly

Re: [PERFORM] Using pgiosim realistically

On Mon, May 16, 2011 at 12:23:13PM -0400, Jeff wrote: On May 16, 2011, at 9:17 AM, John Rouillard wrote: However, in my case I have an 8 disk raid 10 with a read only load (in this testing configuration). Shouldn't I expect more iops than a single disk can provide? Maybe pgiosim is hitting

[PERFORM] Using pgiosim realistically

like a lot of data If I stop the pgiosim, the iostat drops to 0 write and reads as expected. So does anybody have any comments on how to test with pgiosim and how to correlate the iostat and pgiosim outputs? Thanks for your feedback. -- -- rouilj John Rouillard

[PERFORM] OT (slightly) testing for data loss on an SSD drive due to power failure

as the data is coming in. (I.E. make it a writeback with a longer delay so it's more likely to drop data.) Does anybody have any comments or testing methodologies that don't involve using an actual postgres instance? Thanks for your help. -- -- rouilj John Rouillard

[PERFORM] Assessing performance of fetches

/cursor change the steps I should take in tuning it compared to somebody just issuing a normal select? Thanks for any ideas. -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 -- Sent via pgsql

Re: [PERFORM] Are we in the ballpark?

with only a 6 hour runtime when it takes you a couple of days MTTR), can your database app survive with that low a commit rate? As you said you ar expecting something almost 4-5x faster with 7200 rpm disks. -- -- rouilj John Rouillard System Administrator

Re: [PERFORM] performance on new linux boxeradmin(11983)i: STATEMENT: update license set expires= '2010-06-15' where lic

is turned on for the raid array u0 or u1 ...? -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your

Re: [PERFORM] Is Diskeeper Automatic Mode safe?

(s) to fix the issue (replace power supply, mobo etc.)). -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make

Re: [PERFORM] Very poor performance loading 100M of sql data using copy

On Tue, Apr 29, 2008 at 05:19:59AM +0930, Shane Ambler wrote: John Rouillard wrote: We can't do this as we are backfilling a couple of months of data into tables with existing data. Is this a one off data loading of historic data or an ongoing thing? Yes it's a one off bulk data load

Re: [PERFORM] Very poor performance loading 100M of sql data using copy

On Mon, Apr 28, 2008 at 02:16:02PM -0400, Greg Smith wrote: On Mon, 28 Apr 2008, John Rouillard wrote: 2008-04-21 11:36:43 UTC @(2761)i: LOG: checkpoints ... (27 seconds apart) so I changed: checkpoint_segments = 30 checkpoint_warning = 150 That's good, but you might go

[PERFORM] Very poor performance loading 100M of sql data using copy

? Does anybody have any things to check/ideas on why loading a 100Mb sql file using psql would take 3 hours? Thanks in advance for any ideas. -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 -- Sent via

Re: [PERFORM] Very poor performance loading 100M of sql data using copy

On Mon, Apr 28, 2008 at 06:53:09PM +0100, Heikki Linnakangas wrote: John Rouillard wrote: We are running postgresql-8.1.3 under Centos 4 You should upgrade, at least to the latest minor release of the 8.1 series (8.1.11), as there has been a bunch of important bug and security fixes