Re: pg_dump issue

Поиск
Список
Период
Сортировка
От mcelroy, tim
Тема Re: pg_dump issue
Дата
Msg-id 9765373733A7DF4681B12225D2FC44050D6D16@bosexprod001.bostonstock.local
обсуждение исходный текст
Ответ на pg_dump issue  ("mcelroy, tim" <tim.mcelroy@bostonstock.com>)
Список pgsql-performance

I did carry it down to the subdirectory level but only included the total for brevity.  I'll paste the complete readout at the end of the email.  I'll try the "vmstat 1" as you suggest next time the backups run.  If the Eng staff finds anything I'll post the results and maybe save someone else some grief if they have the same issue.  Thanks again for your input Tom.

Tim

PROD001 PROD002
220K    ./global[PARA]4.0K    ./pg_xlog/archive_status[PARA]529M    ./pg_xlog[PARA]36K     ./pg_clog[PARA]256K    ./pg_subtrans[PARA]4.0K    ./base/1/pgsql_tmp[PARA]4.8M    ./base/1[PARA]4.8M    ./base/17229[PARA]4.0K    ./base/62878500/pgsql_tmp[PARA]4.8M    ./base/62878500[PARA]5.5M    ./base/1152695[PARA]4.0K    ./base/67708567/pgsql_tmp[PARA]1.6G    ./base/67708567[PARA]12K     ./base/1157024/pgsql_tmp[PARA]6.3G    ./base/1157024[PARA]4.0K    ./base/1159370/pgsql_tmp[PARA]543M    ./base/1159370[PARA]4.0K    ./base/1157190/pgsql_tmp[PARA]164M    ./base/1157190[PARA]4.0K    ./base/1621391/pgsql_tmp[PARA]81M     ./base/1621391[PARA]8.6G    ./base[PARA]4.0K    ./pg_tblspc[PARA]604K    ./pg_log[PARA]9.1G    .   220K    ./global[PARA]4.0K    ./pg_xlog/archive_status[PARA]529M    ./pg_xlog[PARA]136K    ./pg_clog[PARA]208K    ./pg_subtrans[PARA]4.0K    ./base/1/pgsql_tmp[PARA]4.9M    ./base/1[PARA]4.8M    ./base/17229[PARA]5.3M    ./base/1274937[PARA]4.0K    ./base/64257611/pgsql_tmp[PARA]1.6G    ./base/64257611[PARA]4.0K    ./base/71683200/pgsql_tmp[PARA]6.1G    ./base/71683200[PARA]4.0K    ./base/1281929/pgsql_tmp[PARA]478M    ./base/1281929[PARA]4.0K    ./base/58579022/pgsql_tmp[PARA]154M    ./base/58579022[PARA]81M     ./base/1773916[PARA]4.0K    ./base/55667447/pgsql_tmp[PARA]4.8M    ./base/55667447[PARA]8.3G    ./base[PARA]4.0K    ./pg_tblspc[PARA]588K    ./pg_log[PARA]8.8G    .

 -----Original Message-----
From:   Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent:   Tuesday, May 30, 2006 12:20 PM
To:     mcelroy, tim
Cc:     pgsql-performance@postgresql.org
Subject:        Re: [PERFORM] pg_dump issue

"mcelroy, tim" <tim.mcelroy@bostonstock.com> writes:
> The du . -h  in $PGDATA showed PROD001 at 9.1G and Prod0002 at 8.8G so
> they're pretty much the same, one would think the smaller one should be
> faster.  Yes, the backup files are identical in size.

Hmph.  You should carry the "du" analysis down to the subdirectory
level, eg make sure that it's not a case of lots of pg_xlog bloat
balancing out bloat in a different area on the other system.  But I
suspect you won't find anything.

> I'm hoping the Engineering staff can find something system related as I
> doubted and still doubt that it's a postgres issue.

I tend to agree.  You might try watching "vmstat 1" output while taking
the dumps, so you could at least get a clue whether the problem is CPU
or I/O related ...

                        regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump issue
Следующее
От: Francisco Reyes
Дата:
Сообщение: Re: Adding and filling new column on big table