Re: VACUUMing for 30 minutes
От | |
---|---|
Тема | Re: VACUUMing for 30 minutes |
Дата | |
Msg-id | 20041222163844.93592.qmail@web12707.mail.yahoo.com обсуждение исходный текст |
Ответ на | Re: VACUUMing for 30 minutes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: VACUUMing for 30 minutes
|
Список | pgsql-admin |
Hello, --- Tom Lane <tgl@sss.pgh.pa.us> wrote: > <ogjunk-pgjedan@yahoo.com> writes: > > VACUUMing this DB takes about 30 minutes, and during that time the > DB > > is pretty unresponsive, although the PG process is not using a lot > of > > CPU (load ~ 1) nor memory (~20MB for the VACUUM process). > > How big is the DB physically ("du $PGDATA" results)? 4.2 GB: # du -h ~postgres/data 3.6M /var/lib/pgsql/data/base/1 3.6M /var/lib/pgsql/data/base/16975 4.0K /var/lib/pgsql/data/base/16976/pgsql_tmp 4.1G /var/lib/pgsql/data/base/16976 4.1G /var/lib/pgsql/data/base 152K /var/lib/pgsql/data/global 129M /var/lib/pgsql/data/pg_xlog 1.1M /var/lib/pgsql/data/pg_clog 4.2G /var/lib/pgsql/data > If you've been lax > about vacuuming or not had your FSM parameters set high enough, there > could be a whole lot of dead space for VACUUM to scan through. I've been vacuuming every night, like a good DBwife. > If so, > VACUUM FULL or possibly CLUSTER would be the best way to re-compact > the > tables. (VACUUM VERBOSE on your larger tables would be another way > to > investigate this.) I will try VACUUM VERBOSE on the biggest (and most active) table tonight and report the findings. > The other possibility is that you have a seriously slow disk drive > :-( It looks like I have an ATA-6 drive with only 2MB cache, and the following throughput: # /sbin/hdparm -tT /dev/hda /dev/hda: Timing buffer-cache reads: 128 MB in 0.56 seconds =228.57 MB/sec Timing buffered disk reads: 64 MB in 1.18 seconds = 54.24 MB/sec Not SCSI, not RAID, but not the slowest HDD on the continent. Thanks, Otis
В списке pgsql-admin по дате отправления: