main

zabbix housekeeper

История "рационализации и утилизации" housekeeper'а zabbix'а на pgsql.

Суть проблемы: заббикс хранит историю значений в нескольких больших таблицах, которые могут разрастаться до неприличных размеров. Поэтому эти таблицы нужно периодически чистить от старых данных. Заббикс может делать это и сам, там этот процесс называется "housekeeping".

По мере роста размера истории возникает дилемма: если базу чистить - это занимает всё больше и больше времени. В какой-то момент может оказаться, что база загружена большей частью запросами чистки данных (см рис 1). Если же housekeeping выключить полностью (что, кстати, рекомендуют делать в большинстве постов на эту тему в сети) - проблема лишь откладывается на будущее и при необходимости сделать тот же reindex - вы оказываетесь в заднице. Или даунтайм на сутки, или оно будет идти в фоне пару недель, с падением производительности.

Есть конечно и третий путь - использовать партиции, но тут возникает необходимость их периодического создания/удаления, и от вышеописанного с реиндексом это никак не поможет. Кроме того, в mysql оно работает мягко скажем не слишком оптимально, а в pgsql его вообще штатно нет, и это там реализуется или через наследование таблиц или через триггер на вставку.

Однако, мои тесты показали, что есть ещё один вариант - использовать фиксированное время хранения истории. Это позволяет не отключать housekeeper, держать размер базы под контролем, сохранить её производительность и низкое время обслуживания/бэкапов.

На графики это не влияет, поскольку те строятся на основе данных из trends (кроме самых последних часов).

При этом запросы значительно упрощаются, с таких:

DELETE FROM history WHERE item_id IN
  (SELECT itemid FROM history WHERE itemid = 'XXX' AND timestamp < 'YYY' LIMIT 'ZZZ');
-- пишу по памяти, могут быть неточности

до таких:

DELETE FROM history WHERE item_id = 'XXX' AND timestamp < 'YYY';

Ещё одна засада, о которой я уже мельком упоминал - это одновременная работа чистки данных и autovacuum'а, поскольку первое вызывает срабатывание второго. В результате - производительность базы проседает больше, чем ожидалось.

А теперь - слайды!

На графике ниже можно видеть момент полной чистки истории (с 09.10), реиндекс остального (с 10.10), включения housekeeper'а (12.10) и постепенная деградация производительности базы по мере роста объёма истории (до 02.11). График с 04.10 и до 09.10 показывает типовую нагрузку на базу при отключенной чистке истории. Пики в конце дня - это бэкап.

рис 1

Этот же график, но продлённый ещё на две недели. Здесь можно видеть момент изменения политики хранения истории на фиксированный период (со 02.11 и далее). Обратите внимание на увеличение частоты пиков загрузки относительно начала графика на рис. 1: это к бэкапу добавились периодические запуски housekeeper'а.

рис 2

Отрезок второго графика большего масштаба, длительностью в сутки. Чётко видно время и количество запусков чистки базы.

рис 3

Ссылки

zabbix pgsql