Занадто багато вводу-виводу, генерованого процесом колекціонування статистики постгресів

Я використовую XenServer з кількома віртуальними машинами, що мають локальні бази даних postgres. Навіть коли всі програми не використовуються, а бази даних простоюють, кожен vm викликає постійний мережевий трафік для зберігання, що погіршує продуктивність пристрою зберігання iscsi.

Після запуску iotopя зазначив, що процес збирання постгресів у процесі збирання даних постійно записується на диск зі швидкістю близько 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 (видавлювання) з 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

Оновлення PostgreSQL. По абсолютному мінімуму переконайтеся, що ви останній 8.4; якщо це не вирішує цю проблему, це практично можливо, ви, мабуть, перейдете до 9.2. Принаймні деякі питання навколо колектора статистики вирішувались з 8.4, і закінчується термін їх життя приблизно через рік . Ви можете отримати більше інформації, переглянувши архіви списку розсилки pgsql .

У вас не повинно виникнути занадто багато проблем з оновленням з 8,4 до 9,2, хоча, як завжди, ви повинні прочитати розділ оновлення приміток до випусків для кожного випуску .0 між ними (9.0, 9.1 та 9.2). Зверніть особливу увагу на standard_conforming_stringsта bytea_output.

Тут же проблема. Я також відключив track_*і так далі.

Побічний ефект полягає в тому, що autovacuumвикористовуючи ці зібрані дані, потрібно знищити.

Отже, я подбаю про те, щоб розкладати нічні а vacuumdb.

Іншим рішенням є встановлення autovacuum_naptimeдостатньо високого рівня для відпочинку в системі.