Re: 7 hrs for a pg_restore?
От | Guillaume Cottenceau |
---|---|
Тема | Re: 7 hrs for a pg_restore? |
Дата | |
Msg-id | 874pc146l1.fsf@mnc.ch обсуждение исходный текст |
Ответ на | Re: 7 hrs for a pg_restore? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-performance |
Tom Lane <tgl 'at' sss.pgh.pa.us> writes: > Guillaume Cottenceau <gc@mnc.ch> writes: >> I have made a comparison restoring a production dump with default >> and large maintenance_work_mem. The speedup improvement here is >> only of 5% (12'30 => 11'50). > >> Apprently, on the restored database, data is 1337 MB[1] and >> indexes 644 MB[2][2]. Pg is 8.2.3, checkpoint_segments 3, >> maintenance_work_mem default (16MB) then 512MB, shared_buffers >> 384MB. It is rather slow disks (Dell's LSI Logic RAID1), hdparm >> reports 82 MB/sec for reads. > > The main thing that jumps out at me is that boosting checkpoint_segments > would probably help. I tend to set it to 30 or so (note that this > corresponds to about 1GB taken up by pg_xlog). Interestingly, from a bzipped dump, there is no win; however, from an uncompressed dump, increasing checkpoint_segments from 3 to 30 decreases clock time from 9'50 to 8'30 (15% if I'm correct). -- Guillaume Cottenceau
В списке pgsql-performance по дате отправления: