UMGUM.COM 

Zabbix + Housekeeper + PostgreSQL + Vacuum ( Оптимизация использования дискового пространства Zabbix в связке с PostgreSQL. )

7 января 2012  (обновлено 2 ноября 2014)

OS: Linux Debian Lenny/Squeeze.
Application: Zabbix Server 1.8/2.0.

Задача: явно настроить контроль за объёмом используемого Zabbix-сервером и СУБД PostgreSQL дискового пространства при обеспечении работы сервиса мониторинга.

По умолчанию, "действия" и "события" системы мониторинга Zabbix не хранятся более 365 дней. Этот параметр можно произвольно изменять в процессе конфигурирования каждого элемента мониторинга индивидуально или задавать обобщение с помощью шаблона; ничто не мешает нам задать для какого-нибудь параметра срок хранения данный в течении одного дня, например.

Для удаления данных с истёкшим сроком хранения в Zabbix-сервере есть специальная подсистема, называемая "Housekeeper". Регулярно, в соответствии с заданными параметрами, подсистема отрабатывает удаление старых данных. Всё просто, настраиваемо в общем конфигурационном файле Zabbix:


# cat /etc/zabbix/zabbix_server.conf

....

# Зададим периодичность запуска процедуры очистки базы Zabbix от устаревшей информации (в часах). Учитывая то, что мы используем в качестве СУБД PostgreSQL, период задаём побольше, чтобы дать время утилите "vacuum", которая должна оптимизировать таблицы базы после удаления части содержимого, отработать в полном объёме
#
HousekeepingFrequency=24

# Зададим ограничение на количество удаляемых за один проход записей. Полагаю, что это значение нужно подбирать исходя их общего количества отрабатываемых узлов и производительности дисковой подсистемы. По умолчанию значение равно 500 (пятистам), что мне представляется слишком малым
#
MaxHousekeeperDelete=2500

# Отключаем отключение процедуры очистки (такой вот забавный подход, значение "true", она же "1" - отключает подсистему)
#
DisableHousekeeping=0

....

Ничто не совершенно; это касается и способа запуска утилиты очистки баз Zabbix от устаревшей информации. К сожалению, нельзя явно задать время старта "Housekeeper"; можно лишь задавать время относительно предыдущего запуска. А как было бы хорошо задать старт очистки в середине ночи, чтобы к утру уже завершилась как очистка, так и последующая оптимизация с помощью "vacuum".

После удаления части данных таблицы "фрагментируются". Не будем здесь говорить о том, как это сказывается на характеристиках скорости доступа к таблице, заметка больше о проблеме разрастания таблиц баз в размере. PostgreSQL последних версий, с интегрированным и настроенным "autovacuum" (что уже сделано по умолчанию, в Debian Lenny для PostgreSQL 8.3/8.4, например), самостоятельно пытается оптимизировать таблицы, перераспределяя данные и размечая как доступное высвобожденное пространство, занятое ранее удалёнными данными, отслеживая изменения на уровне таблиц. Оно вроде-бы и хорошо, в принципе, но на деле настройки по умолчанию побуждают запускаться "vacuum" каждую минуту, дёргая базу ради обработки двадцати-тридцати строк, больше тормозя систему целом, нежели давая какой-то выигрыш в производительности. Понятно, что в большом, сложном "enterprise" проекте, со множеством сервисов, изменяющемся функционале, часто подвергающемся масштабированию, стоит настроить "autovacuum", отвечающий общим потребностям и целям; проще потерять чуть-чуть на автоматизации, чем вручную выискивать слабые места - но не в нашем случае, со "standalone" сервером мониторинга. Не уверен, но не думаю, чтобы кто-то эксплуатировал нагруженный Zabbix-сервер, разделяя ресурсы СУБД PostreSQL с другими сервисами. По сути, "база данных" - самое узкое место в разветвлённой системе мониторинга, от неё добиваются максимальной производительности при том, что задачи СУБД ограничены и ручная настройка ряда параметров вполне приемлема.

В общем, я предлагаю отключать "autovacuum" в PostgreSQL, в том случае, если кроме Zabbix её более никто не использует, планируя процедуру оптимизации на то время, когда система мониторинга предположительно наименее загружена обработкой поступающих и запрашиваемых данных.

Оптимизируем параметры запуска PostgreSQL, позволяющие более эффективно отрабатывать утилите "vacuum" и отключаем функционал "autovacuum":

# cat /etc/postgresql/8.4/main/postgresql.conf

....

# Задаём размер области памяти, выделяемой для операций VACUUM, CREATE INDEX, ALTER TABLE и FOREGIN KEY (при общем объёме ОЗУ в 4Gb рекомендуется выделить около 512MB)
#
maintenance_work_mem = 512MB

....

# Выключаем "autovacuum"
#
autovacuum = off

....

Останавливаем Zabbix-сервер, перезапускаем PostgreSQL и снова запускаем Zabbix-сервер:

# /etc/init.d/zabbix-server stop
# /etc/init.d/postgresql restart
# /etc/init.d/zabbix-server start

Теперь, когда PostgreSQL не осуществляет более автоматическую разметку высвобожденного пространства и оптимизацию таблиц, настроим запуск таковой вручную, например поздним вечером, когда уже никого нет на рабочем месте и некому рассматривать графики и таблицы:

# cat /etc/crontab

....

# Запуск "vacuumdb" каждый день в 22:01
1 22 * * *  root vacuumdb -U postgres --quiet --analyze --dbname=zabbix &

В примере выше мы запустили утилиту "vacuumdb" в режиме параллельного с клиентскими обращениями исполнения, без перераспределения данных, лишь с разметкой высвобожденного пространства как готового к использованию и анализом структуры для оптимизации запросов к таблицам. Ежедневный проход утилиты позволит стабилизировать размер базы на определённом уровне, но не даст выигрыша в доступном дисковом пространстве после массированного удаления данных, как этого хотелось бы иногда ожидать. Для высвобождения дискового пространства следует провести более глубокое "вакуумирование", которое буквально высвободит занятое пустыми блоками дисковое пространство; но для этого потребуется блокировка базы от клиентских обращений - такое можно себе позволить лишь изредка, во время профилактики или реструктуризации:

# vacuumdb -U postgres --verbose --analyze --full --dbname=zabbix

В качестве дополнительной пищи для размышлений, применяющим PostgreSQL (или даже MySQL) в качестве СУБД для Zabbix в качестве сервера мониторинга с тысячами субъектов мониторинга, рекомендую присмотреться к секционированию (partition) таблиц, например по дням или месяцам, что позволит повысить производительность самой СУБД в работе и упростит управление архивами данных, позволяя при необходимости просто удалять старые куски таблицы.


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )