Я использую XenServer с несколькими виртуальными машинами, имеющими локальные базы данных postgres. Даже когда все приложения не используются, а базы данных простаивают, каждая виртуальная машина вызывает постоянный сетевой трафик хранения, который снижает производительность устройства хранения iscsi.
После запуска iotop Я заметил, что процесс сборщика статистики postgres постоянно записывает на диск со скоростью около 2 МБ / с.
Затем я отключил сбор статистики, отредактировав /etc/postgresql/8.4/main/postgresql.conf:
#------------------------------------------------------------------------------
# RUNTIME STATISTICS
#------------------------------------------------------------------------------
# - Query/Index Statistics Collector -
track_activities = off
track_counts = off
...
как предложено в http://www.postgresql.org/docs/8.4/static/runtime-config-statistics.htm.
Это устранило непрерывную запись, но есть ли недостатки при отключении отслеживания статистики?
Или мне лучше разместить каталог pg_stat_tmp на ramdisk, чтобы избежать дискового / сетевого трафика?
Система представляет собой последнюю версию Debian 6.0.7 (squeeze) с postgres 8.4 и около 20 баз данных с примерно 50 таблицами, общий размер файла дампа составляет менее 100 МБ.
Поскольку обновление PostgreSQL невозможно, я попытался разместить каталог pg_stat_tmp в файловой системе tmpfs, что привело к значительному повышению производительности. Сейчас я запускаю это на нескольких десятках систем в течение пары месяцев без каких-либо заметных недостатков.
Для этого просто смонтируйте pg_stat_tmp с tmpfs в вашем файле / etc / fstab:
# <file system> <mount point> <type> <options> <dump> <pass>
tmpfs /var/lib/postgresql/8.4/main/pg_stat_tmp tmpfs defaults,noatime,mode=1777,uid=postgres,gid=postgres,nosuid,nodev 0 0
Здесь та же проблема. Я также отключил track_* и так далее.
Побочный эффект в том, что autovacuum использует эти собранные данные для запуска.
Итак, я стараюсь назначать каждую ночь vacuumdb.
Другое решение - установить autovacuum_naptime достаточно выше, чтобы система отдыхала.
Обновите PostgreSQL. Как минимум убедитесь, что вы используете последнюю версию 8.4; если это не решает проблему, и это практично, вам, вероятно, следует перейти на 9.2. По крайней мере, некоторые проблемы, связанные со сборщиком статистики, были устранены с версии 8.4, и доживет до конца примерно через год. Вы можете найти дополнительную информацию по поиск в архивах списков рассылки pgsql-general.
У вас не должно возникнуть особых проблем с обновлением с 8.4 до 9.2, хотя, как обычно, вы должен прочтите раздел об обновлении в примечаниях к выпуску для каждого выпуска .0 между ними (9.0, 9.1 и 9.2). Обратите особое внимание на standard_conforming_strings и bytea_output.