Pull to refresh

Comments 14

А можно было взять https://github.com/kostya/pg_reindex :)
Когда разбирались, предложенная выше утилита была на старте разработки.
Два замечания:
Во первых, создание параллельного индекса может не удаться (из-за дедлока, например) — нужно проверять состояние индексов после выполнения CREATE INDEX CONCURRENTLY, в частности, состояние может быть INVALID. Само-собой, поломанный индекс использоваться не будет и удаление рабочего приведет к тому, что у нас вообще не будет доступного для использования индекса.
Во вторых — при удалении индекса сломаются prepared statements, которые пользуются этим индексом. Ну, как сломаются — работать они продолжат, но без использования индекса, т.е. медленно (возможно, в свежих версиях постгреса уже починили, не проверял).
Я понимаю, что статья больше про индексы, чем про zabbix, но не лучше ли отказаться от партиционирования на SSD и вернуться к встроенному механизму очистки и отбросить все минусы партиционирования. SSD вполне может позволить такую операцию без потери производительности самого zabbix. Если кто-то думает, что при этом быстро износится SSD, то нет. За два года работы Remaining Rated Write Endurance: 96%.
Zabbix: 2400vps, 114000 метрик, БД 260 Gb
Такая БД у Вас лежит на одном SSD или используете RAID? Можете озвучить модель? Не могли бы Вы привести статистику iowait на хосте, где лежит БД (конечно, если только её и обслуживает)?
БД работает на 2х SSD INTEL SSDSC2BA400G3T в RAID-1 только под zabbix.
%util from iostat
image
Каждый час запускается zabbix Housekeeper.
В 3:00 10-19 запустился бэкап на 3.5 часа.
Спасибо, очень полезная для меня информация.
Да, у нас используется RAID-1. База данных и сам Zabbix расположены на одном сервере.
Статистика iowait: image
На графике видны пики, самые крупные — бекапы, те что поменьше, это служебные запросы через api для получения служебной информации и для автоматизации ряда процессов.
Ещё несколько назад в Zabbix-е любые поддерживаемые им СУБД уступали MySQL. Такая у него была особенность.
Действительно ли ситуация сейчас настолько изменилась, что PostgreSQL стал оптимальным выбором для Zabbix?
Zabbix уже достаточно давно рекомендует для больших БД использовать PostgreSQL.
Хотелось бы подробностей, откуда взялась такая мощная экономия места — в заббиксе же данные из середины таблиц практически не апдейтятся и не удаляются, откуда взяться неоптимальным индексам? Попробовали у себя проделать реиндекс одного из партишенов — никакой разницы pg_relation_size в размерах индексов не показал.
Тут сразу однозначно ответить сложно, многое зависит от версий PostgreSQL и Zabbix, от типа данных которые вы собираете, размера БД. Так же, возможно зависит от того, чистая ли у вас установка или обновление со старых версий, структура БД немного разная при чистой установке и при обновлении. У нас, например, для некоторых таблиц индексы весят 5-7GB, после reindex их размер уменьшается до 2-3 GB. Версии ПО, используемые в данной статье: Zabbix 3.0.4 и PostgreSQL 9.5.
Sign up to leave a comment.