> === Аноним, 11:59 , 26-Апр-13 (1) +4
> #>>> Интересно, если Заббикс на этот движок перенести - ему поможет?
> === alp, 12:22 , 26-Апр-13 (4) +2
> #>> Postgres ему точно поможет
> https://www.opennet.ru/cgi-bin/openforum/vsluhboard.cgi?az=sh...
>>> Postgres ему точно поможет
>> Не-а. Моему Zabbix-у на Pg, "сурово" загруженному до того по диску/SQL (не
>> считая не-масштабируемости самого Z.), помогло разделение напополам на два сервера -
>> половина~ хостов туда, половина сюда.

----

= Моё "Не-а"

...относилось к флейм-вбросу пользователя alp Mysql vs PgSQL и моим _впечатлениям про немасштабируемость Zabbix-а. Мой подопечный Zabbix рос-рос, и "выросла такая большая...".

= Re: "помогло разделение напополам"

* Не только. Было ещё заметно помогшее изменение: добавление ОЗУ: 32Гб -> 96Гб, при размере базы на диске в районе 48-49Гб. То есть грубо - база поместилась в кеше. Вероятно, паттерн работы с диском поменялся на "преимущественно запись", каковым он сейчас является. Но во время того изменения я не снимал параметры дискового в/в.

* Параметры разделения:

zabbix "performance" (~значения-айтемы в секунду) до разделения ~770, после разделения два сервера, ~320 и ~450. (айтемов ~70-72K - всего (unsupported - 7.9-8.5К, not-monitored -- оно и само не умеет отдавать, в виде performance, разве что), после разделения ещё не числил базы от "второй половины", только Not-monitored поставил на хосты из "не той" половины.

=== В&О #1

= sauron, 13:57 , 26-Апр-13 (9) +3
> PostgeSQL хоть потюненый был?

Был... Наверное. shmem в ядре и конфиге pg добавлял, немного покрутил bg-writer-ы, когда занялся переписыванием housekeeper-а. Но особо боевой сервер не менял, а сделать подобную нагрузку на стенде -- даже и не пытался.

= anonymous, 16:08 , 26-Апр-13, (36)

>> Ну, housekeeper по-переписывал -- чтоб он не забивал своим io более приоритетные
>> (для меня) основные процессы Z.
> Заббикс версии 1.8 или 2.+?

Сейчас 2.0. (~~ 1.8.10?.12 -> 1.8.16 -> 2.0.2 ..., сейчас 2.0.5 + "патчики")
HK "начал беспокоить" ещё на 1.8, на 2.0 я дошёл до "влезания вовнутрь"...

= AlexAT, 21:48 , 26-Апр-13, (66)
> А для статистики - не скажете число итемов/триггеров?

Сейчас "два сервера" выглядят примерно так:

Number of hosts (monitored/not monitored/templates)
   >>#1>>      1142     478 / 507 / 157
   >>#2>>      1147     382 / 610 / 155
Number of items (monitored/disabled/not supported)
   >>#1>>     30746   22938 / 498 / 7310
   >>#2>>     30714   29942 / 29 / 743
Number of triggers (enabled/disabled)[problem/unknown/ok]
   >>#1>>     14518   13880 / 638  [176 / 0 / 13704]
   >>#2>>      3377    3213 / 164  [44 / 0 / 3169]

> Просто интересно, насколько наша инсталляция крупная/мелкая.

Эммм. Зависит... , кого %) "принять за образцы". Сам ;) в непонятках. В т.ч., видимо, либо потому, что не публикуют[*PS], либо я ленив и zabbix.com не читаю.

PS: Пойду в бухгалтерию получать премию за разглашение чувствительной.

> Поясню/дополню:
> .
>> Партишионинг я не осилил.
> --- 8< ---

= XoRe, 17:12 , 26-Апр-13, (46)

> Могу порекомендовать:
> autopartitioning для zabbix 2.x, самый простой и эффективный способ:

Спасибо.

Я (пока?) не лезу глубоко в Pg, ограничиваюсь тем, что влез в Zb (housekeeper расковырял).

А как себя чувствуют Monitoring/Events / Monitoring/Triggers?

>>> zabbix.com не читаю.

Удивительно - но там на форумах в основном мелочевка. До 10000 итемов... Выше похоже как-то у всех грабли начинаются.

Кое-что в заббиксе патчил, но сейчас примерно вот так:

---

Number of hosts (monitored/not monitored/templates)    1149    1104 / 0 / 45
Number of items (monitored/disabled/not supported)    102735    97111 / 4252 / 1372
Number of triggers (enabled/disabled)[problem/unknown/ok]    37998    28120 / 9878  [86 / 0 / 28034]
Required server performance, new values per second    330.89     -

---

Один хост, 2.0.5, немножко допиленный. Очередь почти всегда пустая. После рестарта прочесывается (опустошает очередь) за ~10 минут. Активно используются скриптовые (external) опросы, и discovery - как по хостам, так и по элементам.

Сам Zabbix: ESXi 5.1, 2 x Xeon E5620 @ 2.40GHz, 3 vCores, 3 Gb RAM.
DB-сервер: ESXi 5.1, 2 x Xeon E5620 @ 2.40GHz, 8 vCores, 8 Gb RAM, MariaDB 5.5.30/TokuDB 7.0.1. Диски SATA.

База в TokuDB, объем сырой базы вместе с историей на сейчас - 15 Гб (это около 45 Гб несжатых). Параллельно заббиксу на этом DB-сервере крутятся (только базы, естественно) еще Cacti (Boost) на 37000 графиков, архив RADIUS с начала времен, и всякая мелочевка.

---

Если интересно - неспецифичные патчи для заббиха выложу, там в основном мелочевка - обход косяков оптимизатора. Вполне возможно, что в MariaDB часть косяков испарилась - но проверять депатчингом на боевой инсталляции не хочу :)

Несколько целиком переписанных запросов завязаны на нашу специфику - но и пресловутых патчей на обход съезжающего под его запросами оптимизатора нам уже хватило для того, чтобы заббих прочесался из небытия до рабочего состояния.