Я использую XenServer с несколькими виртуальными машинами, имеющими локальные базы данных postgres. Даже когда все приложения не используются и базы данных простаивают, каждый vm вызывает постоянный сетевой трафик хранилища, что снижает производительность устройства хранения 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 на виртуальном диске, чтобы избежать дискового / сетевого трафика?
Система представляет собой современный Debian 6.0.7 (squeeze) с postgres 8.4 и около 20 баз данных с около 50 таблицами, общий размер файла дампа составляет менее 100 МБ.
Обновите 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
.источник
Та же проблема здесь. Я тоже отключен
track_*
и так далее.Побочным эффектом является
autovacuum
использование этих собранных данных для запуска.Итак, я забочусь, чтобы запланировать ночные
vacuumdb
.Другое решение - установить
autovacuum_naptime
достаточно высоко, чтобы система отдыхала.источник