Re: Importing from pg_dump slow, low Disk IO - Mailing list pgsql-performance

From Martin Fandel
Subject Re: Importing from pg_dump slow, low Disk IO
Date
Msg-id 1118398476.31750.3.camel@fandelm.ecommit.de
Whole thread Raw
In response to Importing from pg_dump slow, low Disk IO  ("Steve Pollard" <stevep@hostworks.com.au>)
List pgsql-performance
Hmmm. In my configuration there are not much more performance:

The Dump-size is 6-7GB on a PIV-3Ghz, 2GB-RAM, 4x10k disks on raid 10
for the db and 2x10k disks raid 1 for the system and the wal-logs.

open_sync:
real    79m1.980s
user    25m25.285s
sys     1m20.112s

fsync:
real    75m23.792s
user    27m3.693s
sys     1m26.538s

best regards,
martin

Am Freitag, den 10.06.2005, 15:33 +0930 schrieb Steve Pollard:
> Hi All,
>
> Not sure if this is correct fix or not, but a bit of research :
> http://archives.postgresql.org/pgsql-hackers/2001-04/msg01129.php
> And offical doco's from postgres :
> http://www.postgresql.org/docs/7.4/static/wal-configuration.html
> Lead me to try :
> wal_sync_method = open_sync
> And this has increased the speed on my Redhat 8 servers my 20X !
>
> Steve
> -----Original Message-----
> From: Steve Pollard
> Sent: Thursday, 9 June 2005 1:27 PM
> To: Steve Pollard; pgsql-performance@postgresql.org
> Subject: RE: [PERFORM] Importing from pg_dump slow, low Disk IO
>
> As a follow up to this ive installed on another test Rehat 8 machine
> with
> 7.3.4 and slow inserts are present, however on another machine with ES3
> the same 15,000 inserts is about 20 times faster, anyone know of a
> change that would effect this, kernel or rehat release ?
>
> Steve
>
> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Steve
> Pollard
> Sent: Wednesday, 8 June 2005 6:39 PM
> To: pgsql-performance@postgresql.org
> Subject: [PERFORM] Importing from pg_dump slow, low Disk IO
>
>
> Hi Everyone,
>
> Im having a performance issue with version 7.3.4 which i first thought
> was Disk IO related, however now it seems like the problem is caused by
> really slow commits, this is running on Redhat 8.
>
> Basically im taking a .sql file with insert of about 15,000 lines and
> <'ing straight into psql DATABASENAME, the Disk writes never gets over
> about 2000 on this machine with a RAID5 SCSI setup, this happens in my
> PROD and DEV environment.
>
> Ive installed the latest version on RedHat ES3 and copied the configs
> across however the inserts are really really fast..
>
> Was there a performce change from 7.3.4 to current to turn of
> autocommits by default or is buffering handled differently ?
>
> I have ruled out Disk IO issues as a siple 'cp' exceeds Disk writes to
> 60000 (using vmstat)
>
> If i do this with a BEGIN; and COMMIT; its really fast, however not
> practical as im setting up a cold-standby server for automation.
>
> Have been trying to debug for a few days now and see nothing.. here is
> some info :
>
> ::::::::::::::
> /proc/sys/kernel/shmall
> ::::::::::::::
> 2097152
> ::::::::::::::
> /proc/sys/kernel/shmmax
> ::::::::::::::
> 134217728
> ::::::::::::::
> /proc/sys/kernel/shmmni
> ::::::::::::::
> 4096
>
>
> shared_buffers = 51200
> max_fsm_relations = 1000
> max_fsm_pages = 10000
> max_locks_per_transaction = 64
> wal_buffers = 64
> effective_cache_size = 65536
>
> MemTotal:      1547608 kB
> MemFree:         47076 kB
> MemShared:           0 kB
> Buffers:        134084 kB
> Cached:        1186596 kB
> SwapCached:        544 kB
> Active:         357048 kB
> ActiveAnon:     105832 kB
> ActiveCache:    251216 kB
> Inact_dirty:    321020 kB
> Inact_laundry:  719492 kB
> Inact_clean:     28956 kB
> Inact_target:   285300 kB
> HighTotal:      655336 kB
> HighFree:         1024 kB
> LowTotal:       892272 kB
> LowFree:         46052 kB
> SwapTotal:     1534056 kB
> SwapFree:      1526460 kB
>
> This is a real doosey for me, please provide any advise possible.
>
> Steve
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
>                http://www.postgresql.org/docs/faq


pgsql-performance by date:

Previous
From: Richard Huxton
Date:
Subject: Re: Cleaning bloated pg_attribute
Next
From: Bruno Wolff III
Date:
Subject: Re: Help with rewriting query