Pull to refresh

Comments 18

При всяких чудесах на сети — подскакивает до полутора — двух тысяч. Перемалывает без проблем.
Ну, если чуть длиннее, чем в статье — видно, что rocksdb время от времени жмёт свои файлики, так что в норме жизни график свободного места представляет собой пилу.
Весь стандартный функционал заббикса — работает, как ни в чем не бывало.
Производительность выросла, но тут я не могу отделить вклад rocksdb от вклада перехода с hdd на ssd.
Сборка всей кухни из исходников доставила хлопот (хотя бы потому, что из всех веток в git mariadb надо было выбрать рабочую).
ну хотя бы бенчмарк привели бы — до и после)))и почему Вы из исходников все собираете?
Из исходников — вынужденная мера — заббикс из коробки линкуется с libmysql, который приходится перекомпилировать, чтобы rocksdb был рабочий. Если не пересобирать net-snmp (про это есть в статье) — zabbix на snmp-ных элементах данных валится. Но не сразу, а через какое-то время.
Бенчмарк — тема, осталось собрать нормальный стендик под это, независимый от продакшена. Нет ли у вас на примете достаточно разлапистой конфигурации для zabbix-а и генератора данных под неё, чтобы сравнить «при прочих равных». С меня — оплатить ноды на amazon-е и прогнать тесты в конфигурации с innodb (c housekeeper-ом и без и с partition-ing-ом) и с rocksdb (соответственно, с housekeeper-ом и с Comment=ttl_...) — мне тоже интересно увидеть, сколько можно выжать того же NVPS.
Ну прописана она в зависимостях у mariadb-ных пакетов. Содержательно тут она не нужна, да.
Да, можно и тут подпилить rules-файл (или где оно там), но зачем?
Чтобы было осмысленно сравнивать, imho, нужно иметь конфигурацию из хотя бы сотни узлов с хотя бы десятком элементов данных в каждом. И «нечто», что по zabbix-овому протоколу будет кормить заббикс данными. Смысл — забить кэши, какие ни есть.
А лучше — нечто, что будет отвечать на запросы к агентам какими-то разумно шумящими циферками.
Проблема в том, что у меня под руками такого стенда нету.
А конфиги машины? Статистка Zabbix, графики нагрузки на железо и его параметры? Можно? :)
Можно, а какие именно вам интересны?
Машина — (24 ядра по cpuinfo) CPU — Intel® Xeon® CPU E5-2640 0 @ 2.50GHz
16 GB RAM, SSD — Kingston_SHPM2280P2_480G
С графиками и статистикой — опять же можно, но завтра и прицельно — что интересно.

Интересно сколько хостов суммарно и потребление памяти/cpu/hdd на сервере до/после. Субъективно — быстрее ли отрабатывают разделы интерфейса с данными из history_*? Если таблица крашнется — как у этого аддона дела с восстановлением?
Количество узлов сети (активированных/деактивированных/шаблонов) 844 615 / 104 / 125
Количество элементов данных (активированных/деактивированных/неподдерживаемых) 91652 71854 / 407 / 19391
Количество триггеров (активированных/деактивированных [проблема/ок]) 69283 68416 / 867 [57 / 68359]
Количество пользователей (в сети) 17 4
Требуемое быстродействие сервера, новые значения в секунду 374.55

Субьективно — быстрее. График с ~35 линиями с данными за сутки (с разрешением ~3 точки в минуту) рисуется ~5 секунд. На старой машине — в разы дольше, но точную цифру не скажу.
Даже если поднять там данные — не будет честного сравнения — на ней диск медленнее, а процессор быстрее.

Таблицы специально не крешил.
Когда по ошибке прервал операцию «alter table… add column» над history_uint с поднятыми данными, отправив sigkill серверному процессу, случился казус — оно оставило временный файл в директории, записала себе в мозг, что создало его, а при следующем пуске сперва потёрло времянку, а потом удивлённо упало с комментарием вида «ой, тут у меня табличко пропало» — пришлось лезть грязными руками в исходники.
Детали тут: github.com/mickvav/mysql-5.6/pull/1
и тут: github.com/facebook/mysql-5.6/issues/669
С памятью и потреблением диска — попробую сделать контрольный замер (при «прочих равных») — но это займёт время, не сегодня уже.
Sign up to leave a comment.

Articles