Слишком много операций ввода-вывода, сгенерированных процессом сбора статистики postgres


10

Я использую 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 МБ.

Ответы:


7

Поскольку обновление 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

Я сделал это для Postgresql 9.1. Один из моих серверов непрерывно записывал 1 МБ / с в течение дня. Это сделало его почти ничего. Это одобрено документами , BTW: «... Указание этого на файловую систему на основе ОЗУ снизит требования к физическому
вводу-выводу

0

Обновите 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.


0

Та же проблема здесь. Я тоже отключен track_*и так далее.

Побочным эффектом является autovacuumиспользование этих собранных данных для запуска.

Итак, я забочусь, чтобы запланировать ночные vacuumdb.

Другое решение - установить autovacuum_naptimeдостаточно высоко, чтобы система отдыхала.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.