zabbix discoverer processes more than 75 busy как исправить

Содержание

Optimizatsiya nastroek Zabbix

Стандартные настройки в zabbix, не всегда хорошо работают и их необходимо тюнить под свои нужды. Я собрал в данной статье, основные параметры для оптимизации. Возможно, — это не все и вы знаете больше, но я постараюсь максимизировать.

Настройка кеша

Для оптимизации заббикс сервера, стоит увеличить размер кеша, для этого — открываем:

Находим строку «CacheSize» и увеличиваем его.

Я увеличил до 256M. При надобности, можно добавить.

Zabbix discoverer processes more than 75% busy

Недавно получил алерт в заббиксе:

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Ищем строку с опцией «StartDiscoverers» и увеличиваем данный параметр:

Я, опцию StartDiscoverers увеличил до 5. На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:

Можно увидеть мой наглядный пример:

Если после добавления хостов ( с разными подсетями) вы увидите что снова сработал этот триггер, то нужно увеличить StartDiscoverers.

Zabbix icmp pinger processes more than 75% busy

Недавно получил алерт в заббиксе:

Данное сообщение, говорит — что процесс(ы) выполняющие ping по хостам, перегружены.

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Ищем строку с опцией «StartPingers» и увеличиваем данный параметр:

Я, опцию StartPingers увеличил до 5, тем самым — я увеличил количество процессов выполняющих ICMP Ping.

На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:

Zabbix poller processes more than 75% busy

poller — это процесс который опрашивает агентов.

Данный параметр стоит увеличивать в 2- случаях:

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Ищем строку с опцией «StartPollers» и увеличиваем данный параметр:

Я установил данный параметр в 5. Если очень будет худо, то увеличиваем его до 20. Ничто не приходит бесследно, увеличение процессов ведет к увеличение потребления ресурсов.

После этого, вы можете получить:

Если видите у себя данное сообщение ( алерт, сработанный триггер), открываем конфиг:

Ищем строку с опцией «StartPollersUnreachable» и увеличиваем данный параметр:

PS: У меня данный параметр используется по умолчанию и я его не трогал ( не было ошибок).

Имеется вероятность того, что перестанет хватать коннекщенов для БД, то надо увеличивать лимит подключений.

Zabbix housekeeper processes more than 75% busy

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy timer processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy escalator processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy alerter processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy configuration syncer processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и изменяем:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy db watchdog processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy history syncer processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и изменяем:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy self-monitoring processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy http poller processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и меняем параметр:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy java poller processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и меняем параметр:

Сохраняем файл и перезагружаем zabbix:

А на этом, у меня все и статья «Оптимизация настроек Zabbix» завершена.

6 thoughts on “ Оптимизация настроек Zabbix ”

первый раз пишу комент на сайте за лет 5 ))) аж не по себе ))
в общем респект и уважуха!

housekeeper processesMaxHousekeeperDelete=5000 поменял на 100
но не помогло, все ровно так же высвечивает Zabbix housekeeper processes more than 75% busy. Перезагружал железо не помогло. Что делать?

Нужно не уменьшать, а увеличивать!
Но нужно чтобы хватило ресурсов на сервере.

Может RAM, CPU мало для Докер контейнера выделил. Так же, может стоит увеличить значения в 2-3 раза:
ZBX_VALUECACHESIZE=512M
ZBX_CACHESIZE=512M
ZBX_STARTDISCOVERERS=10

Благодарность за хороший Материал и Работу!

Столкнулся с сообщением вида:

Zabbix server is not running: the information displayed may not be current

Правка /etc/zabbix/zabbix_server.conf
Изменил значение параметра CacheSize=512M (было 8)
и перезапустил zabbix

service zabbix-server restart

Добавить комментарий Отменить ответ

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

Почему процессы Zabbix под нагрузкой

$ sudo nano /etc/zabbix/zabbix_server.conf

а вот шаблон Template ICMP Ping у меня применим к более чем одному хосту, когда хостов стало 8 штук, панель управления мониторингом zabbix вывело сообщение:

Zabbix discoverer processes more than 75% busy

На заметку: Данное сообщение означает, что процесс или процессы задействующие работу по нацеленному шаблону перегружены.

Для равномерного создания процессов, нужно параметр StartPingers увеличить к примеру до:

Значение подбирается опытным путем и предсказать его заранее не представляется возможным. Изменяя данный параметр мы распределяем количество задействованных процессов входимых в шаблон Template ICMP Ping

По окончании изменений необходимо сделать перезапуск серверной части Zabbix:

$ sudo service zabbix-server restart

Также не лишним будет увеличить «Интервал обновления» данных задейстованных в определении доступности/не доступности узла поставленного на мониторинг. Делается это следующим образом:

http://IP&DNS/zabbix — Configuration — Templates — находим шаблон Template ICMP Ping — после в нем переходим к Items (Элемент Данных) и для каждого элемента:

корректируем значение в параметре: Update interval (in sec) c 60 секунд к примеру до 180 секунд, т. е. Вместо одной минуты следующих запрос проводить через три минуты на предмет проверки.

Этими действиями мы тюнингуем Zabbix сервер с целью оптимизированного съема/анализа узлов и при этом не нарушая работы Zabbix сервера вызванного повышенной нагрузкой дефолтных параметров.

Пока вышеприведенные значения в моем случае успешно справляются, также добавил на мониторинг еще 14 узлов базовых станции, таких как Grandstream GP715, D-Link DVG-5008SG, D-Link DVG-2024S и результат Zabbix сервер не испытывает проблем. Как что-то у меня будет не так с Zabbix сервер все это и многое другое будет оформлено в виде пошаговой заметки и опубликовано на моем блоге, а пока все. С уважением, автор блога — ekzorchik.

Оптимизация настроек Zabbix

Стандартные настройки в zabbix, не всегда хорошо работают и их необходимо изменить под свои нужды. Я собрал в данной статье, основные параметры для оптимизации. Возможно, — это не все и вы знаете больше, но я постараюсь максимизировать.

Настройка кеша

Для оптимизации zabbix сервера, стоит увеличить размер кеша, для этого — открываем:

Находим строку «CacheSize» и увеличиваем его.

Я увеличил до 256M. При надобности, можно добавить.

Zabbix discoverer processes more than 75% busy

Недавно получил алерт в заббиксе:

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Ищем строку с опцией «StartDiscoverers» и увеличиваем данный параметр:

Я, опцию StartDiscoverers увеличил до 5. На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:

Если после добавления хостов ( с разными подсетями) вы увидите что снова сработал этот триггер, то нужно увеличить StartDiscoverers.

Zabbix icmp pinger processes more than 75% busy

Недавно получил алерт в заббиксе:

Данное сообщение, говорит — что процесс(ы) выполняющие ping по хостам, перегружены.

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Ищем строку с опцией «StartPingers» и увеличиваем данный параметр:

Я, опцию StartPingers увеличил до 5, тем самым — я увеличил количество процессов выполняющих ICMP Ping.

На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:

Zabbix poller processes more than 75% busy

poller — это процесс который опрашивает агентов.

Данный параметр стоит увеличивать в 2- случаях:

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Ищем строку с опцией «StartPollers» и увеличиваем данный параметр:

Я установил данный параметр в 5. Если очень будет худо, то увеличиваем его до 20. Ничто не приходит бесследно, увеличение процессов ведет к увеличение потребления ресурсов.

После этого, вы можете получить:

Если видите у себя данное сообщение ( алерт, сработанный триггер), открываем конфиг:

Ищем строку с опцией «StartPollersUnreachable» и увеличиваем данный параметр:

PS: У меня данный параметр используется по умолчанию и я его не трогал ( не было ошибок).

Имеется вероятность того, что перестанет хватать коннекщенов для БД, то надо увеличивать лимит подключений.

Zabbix housekeeper processes more than 75% busy

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy timer processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy escalator processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy alerter processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy configuration syncer processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и изменяем:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy db watchdog processes, in %

Начиная с Zabbix 3.4 alpha, нет необходимости в мониторинге процесса db watchdog, так как он был удален. Шаблон приложения Zabbix сервер не должен иметь этот элемент.

Zabbix busy history syncer processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и изменяем:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy self-monitoring processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Переменную укажу позже (не знаю какая)!

Сохраняем файл и перезагружаем zabbix:

Zabbix busy http poller processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и меняем параметр:

Сохраняем файл и перезагружаем zabbix:

Zabbix busy java poller processes, in %

Это можно исправить, откроем zabbix_server.conf конфиг-файл:

Находим и меняем параметр:

Сохраняем файл и перезагружаем zabbix

А на этом, у меня все и статья «Оптимизация настроек Zabbix» завершена.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Люди. Фото. Жизнь.

12345678910111213141516 1718

Что такое Poller или Zabbix poller processes more than 75% busy

Многие, кто ставит zabbix сервер с настройками по умолчанию, часто встречаются с такой проблемой, как сообщение в админ панели:
Zabbix poller processes more than 75% busy

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

Нам важно следующее:
Если у вас хорошее железо, то можно немного расщедриться и выделить ему комнату вместо подстилки у двери)

Как починить

Открыть конфигурационный файл zabbix_server.conf:

Найти параметр StartPollers и установить ему значение больше дефолтного, например 15 или 20, и не забудьте удалить комментарий # перед параметром.

Из-за увеличения процессов идет большая нагрузка на сервер, будьте аккуратны, чтобы все это хозяйство не оставило Вас без драгоценных камней ресурсов.

Это также относится и к ошибке «Zabbix unreachable poller processes more than 75% busy», для этого необходимо увеличить параметр StartPollersUnreachable – значения нужно подбирать под сервер и ваши нужды.

Совет от Кэпа

После увеличения предыдущих параметров, было бы здорово увеличить размер CacheSize – размер памяти для хранения узлов и различного рода элементов данных. Увеличиваем CacheSize, ставим например 256M или даже 512М, если не жалко, то можно и 1024M.

Заключение

Если вдруг видите в Dashboard в каких-либо блоках сообщение о проблеме с подключением к базе данных (БД), то необходимо увеличить лимит подключений, так как может быть перестанет хватать коннектов к БД.

Высокая производительность и нативное партиционирование: Zabbix с поддержкой TimescaleDB

Zabbix — это система мониторинга. Как и любая другая система, она сталкивается с тремя основными проблемами всех систем мониторинга: сбор и обработка данных, хранение истории, ее очистка.

Этапы получения, обработки и записи данных занимают время. Немного, но для крупной системы это может выливаться в большие задержки. Проблема хранения — это вопрос доступа к данным. Они используются для отчетов, проверок и триггеров. Задержки при доступе к данным также влияют на производительность. Когда БД разрастаются, неактуальные данные приходится удалять. Удаление — это тяжелая операция, которая также съедает часть ресурсов.

jbyyzopzw6gtfio8uhqbgushzo8

Проблемы задержек при сборе и хранении в Zabbix решаются кэшированием: несколько видов кэшей, кэширование в БД. Для решения третьей проблемы кэширование не подходит, поэтому в Zabbix применили TimescaleDB. Об этом расскажет Андрей Гущин — инженер технической поддержки Zabbix SIA. В поддержке Zabbix Андрей больше 6 лет и напрямую сталкивается с производительностью.

Как работает TimescaleDB, какую производительность может дать по сравнению с обычным PostgreSQL? Какую роль играет Zabbix для БД TimescaleDB? Как запустить с нуля и как мигрировать с PostgreSQL и производительность какой конфигурации лучше? Обо всем этом под катом.

Вызовы производительности

Каждая система мониторинга встречается с определенными вызовами производительности. Я расскажу о трех из них: сбор и обработка данных, хранение, очистка истории.

Быстрый сбор и обработка данных. Хорошая система мониторинга должна оперативно получать все данные и обрабатывать их согласно триггерным выражениям — по своим критериям. После обработки система должна также быстро сохранить эти данные в БД, чтобы позже их использовать.

Хранение истории. Хорошая система мониторинга должна хранить историю в БД и предоставлять удобный доступ к метрикам. История нужна, чтобы использовать ее в отчетах, графиках, триггерах, пороговых значениях и вычисляемых элементах данных для оповещения.

Очистка истории. Иногда наступает день, когда вам не нужно хранить метрики. Зачем вам данные, которые собраны за 5 лет назад, месяц или два: какие-то узлы удалены, какие-то хосты или метрики уже не нужны, потому что устарели и перестали собираться. Хорошая система мониторинга должна хранить исторические данные и время от времени их удалять, чтобы БД не разрослась.

Очистка устаревших данных — острый вопрос, который сильно отражается на производительности базы данных.

Кэширование в Zabbix

В Zabbix первый и второй вызовы решены с помощью кэширования. Для сбора и обработки данных используется оперативная память. Для хранения — истории в триггерах, графиках и вычисляемых элементах данных. На стороне БД есть определенное кэширование для основных выборок, например, графиков.

Кэширование на стороне самого Zabbix-сервера это:

ConfigurationCache

Это основной кэш, в котором мы храним метрики, хосты, элементы данных, триггеры — все, что нужно для PreProcessing и для сбора данных.

Все это хранится в ConfigurationCache, чтобы не создавать лишних запросов в БД. После старта сервера мы обновляем этот кэш, создаем и периодически обновляем конфигурации.

Сбор данных

Схема достаточно большая, но основное в ней — это сборщики. Это различные «pollers» — процессы сборки. Они отвечают за разные виды сборки: собирают данные по SNMP, IPMI, и передают это все на PreProcessing.

z22rjqgzyoam 61aadugsmowsbeСборщики обведены оранжевой линией.

В Zabbix есть вычисляемые агрегационные элементы данных, которые нужны, чтобы агрегировать проверки. Если у нас они есть, мы забираем данные для них напрямую из ValueCache.

PreProcessing HistoryCache

Все сборщики используют ConfigurationCache, чтобы получать задания. Дальше они передают их на PreProcessing.

PreProcessing использует ConfigurationCache, чтобы получать шаги PreProcessing. Он обрабатывает эти данные различными способами.

После обработки данных с помощью PreProcessing, сохраняем их в HistoryCache, чтобы обработать. На этом заканчивается сбор данных и мы переходим к главному процессу в Zabbix — history syncer, так как это монолитная архитектура.

Примечание: PreProcessing достаточно тяжелая операция. С v 4.2 он вынесен на proxy. Если у вас очень большой Zabbix с большим количеством элементов данных и частотой сбора, то это сильно облегчает работу.

ValueCache, history & trends cache

History syncer — это главный процесс, который атомарно обрабатывает каждый элемент данных, то есть каждое значение.

History syncer берет значения из HistoryCache и проверяет в Configuration наличие триггеров для вычислений. Если они есть — вычисляет.

History syncer создает событие, эскалацию, чтобы создать оповещения, если требуется по конфигурации, и записывает. Если есть триггеры для последующей обработки, то это значение он запоминает в ValueCache, чтобы не обращаться в таблицу истории. Так ValueCache наполняется данными, которые необходимы для вычисления триггеров, вычисляемых элементов.

History syncer записывает все данные в БД, а она — в диск. Процесс обработки на этом заканчивается.

u7v0080wzx7v fh8ej fas7b1wg

Кэширование в БД

На стороне БД есть различные кэши, когда вы хотите смотреть графики или отчеты по событиям:

Производительность БД критически важна

Zabbix-сервер постоянно собирает данные и записывает их. При перезапуске он тоже читает из истории для наполнения ValueCache. Скрипты и отчеты использует Zabbix API, который построен на базе Web-интерфейса. Zabbix API обращается в базу данных и получает необходимые данные для графиков, отчетов, списков событий и последних проблем.

Для визуализации — Grafana. Среди наших пользователей это популярное решение. Она умеет напрямую отправлять запросы через Zabbix API и в БД, и создает определенную конкурентность для получения данных. Поэтому нужна более тонкая и хорошая настройка БД, чтобы соответствовать быстрой выдаче результатов и тестирования.

Housekeeper

Третий вызов производительности в Zabbix — это очистка истории с помощью Housekeeper. Он соблюдает все настройки — в элементах данных указано, сколько хранить динамику изменений (трендов) в днях.

TrendsCache мы вычисляем на лету. Когда поступают данные, мы их агрегируем за один час и записываем в таблицы для динамики изменений трендов.

Housekeeper запускается и удаляет информацию из БД обычными «selects». Это не всегда эффективно, что можно понять по графикам производительности внутренних процессов.

Красный график показывает, что History syncer постоянно занят. Оранжевый график сверху — это Housekeeper, который постоянно запускается. Он ждет от БД, когда она удалит все строки, которые он задал.

Когда стоит отключить Housekeeper? Например, есть «Item ID» и нужно удалить последние 5 тысяч строк за определенное время. Конечно, это происходит по индексам. Но обычно dataset очень большой, и БД все равно считывает с диска и поднимает в кэш. Это всегда очень дорогая операция для БД и, в зависимости от размеров базы, может приводить к проблемам производительности.

Housekeeper просто отключить. В Web-интерфейсе есть настройка в «Administration general» для Housekeeper. Отключаем внутренний Housekeeping для внутренней истории трендов и он больше не управляет этим.

Housekeeper отключили, графики выровнялись — какие в этом случае могут быть проблемы и что может помочь в решении третьего вызова производительности?

Partitioning — секционирование или партиционирование

Обычно партиционирование настраивается различным способом на каждой реляционной БД, которые я перечислил. У каждой своя технология, но они похожи, в целом. Создание новой партиции часто приводит к определенным проблемам.

Обычно партиции настраивают в зависимости от «setup» — количества данных, которые создаются за один день. Как правило, Partitioning выставляют за один день, это минимум. Для трендов новой партиции — за 1 месяц.

Значения могут изменяться в случае очень большого «setup». Если малый «setup» — это до 5 000 nvps (новых значений в секунду), средний — от 5 000 до 25 000, то большой — выше 25 000 nvps. Это большие и очень большие инсталляции, которые требуют тщательной настройки именно базы данных.

На очень больших инсталляциях отрезок в один день может быть не оптимальным. Я видел на MySQL партиции по 40 ГБ и больше за день. Это очень большой объем данных, который может приводить к проблемам, и его нужно уменьшать.

Что дает Partitioning?

Секционирование таблиц. Часто это отдельные файлы на диске. План запросов более оптимально выбирает одну партицию. Обычно партиционирование используется по диапазону — для Zabbix это тоже верно. Мы используем там «timestamp» — время с начала эпохи. У нас это обычные числа. Вы задаете начало и конец дня — это партиция.

Заметно ускоряет выборку данных SELECT — использует одну или более партиций, а не всю таблицу. Если вы обращаетесь за данными двухдневной давности, они выбираются из БД быстрее, потому что нужно загрузить в кэш и выдать только один файл, а не большую таблицу.

Зачастую многие БД также ускоряет INSERT — вставки в child-таблицу.

TimescaleDB

Для v 4.2 мы обратили внимание на TimescaleDB. Это расширение для PostgreSQL с нативным интерфейсом. Расширение эффективно работает с time series данными, при этом не теряя преимуществ реляционных БД. TimescaleDB также автоматически партицирует.

В TimescaleDB есть понятие гипертаблица (hypertable), которую вы создаете. В ней находятся чанки — партиции. Чанки — это автоматически управляемые фрагменты гипертаблицы, который не влияет на другие фрагменты. Для каждого чанка свой временной диапазон.

TimescaleDB vs PostgreSQL

После 200 млн строк PostgreSQL обычно начинает сильно проседать и теряет производительность до 0. TimescaleDB позволяетэффективно вставлять «inserts» при любом объеме данных.

Установка

Установить TimescaleDB достаточно просто для любых пакетов. В документации все подробно описано — он зависит от официальных пакетов PostgreSQL. TimescaleDB также можно собрать и скомпилировать вручную.

Для БД Zabbix мы просто активируем расширение:

Вы активируете extension и создаете его для БД Zabbix. Последний шаг — создание гипертаблицы.

Миграция таблиц истории на TimescaleDB

Для этого есть специальная функция create_hypertable :

У функции три параметра. Первый — таблица в БД, для которой нужно создать гипертаблицу. Второй — поле, по которому надо создать chunk_time_interval — интервал чанков партиций, которые нужно использовать. В моем случае интервал это один день — 86 400.

Конфигурация железа

Я использовал два сервера. Первый — VMware-машина. Она достаточно маленькая: 20 процессоров Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 ГБ оперативной памяти и SSD-диск на 200 ГБ.

Я установил на ней PostgreSQL 10.8 с ОС Debian 10.8-1.pgdg90+1 и файловой системой xfs. Все минимально настроил, чтобы использовать именно эту базу данных, за вычетом того, что будет использовать сам Zabbix.

Изначально конфигурация содержала 5 000 элементов данных на каждый хост. Почти каждый элемент содержал триггер, чтобы это было схоже с реальными инсталляциями. В некоторых случаях было больше одного триггера. На один узел сети приходилось 3 000-7 000 триггеров.

Интервал обновления элементов данных — 4-7 секунд. Саму нагрузку я регулировал тем, что использовал не только 50 агентов, но добавлял еще. Также, с помощью элементов данных я динамических регулировал нагрузку и снижал интервал обновления до 4 с.

PostgreSQL. 35 000 nvps

Первый запуск на этом железе у меня был на чистом PostgreSQL — 35 тыс значений в секунду. Как видно, вставка данных занимает фракции секунды — все хорошо и быстро. Единственное, что SSD диск на 200 ГБ быстро заполняется.

wppkvqe33kjs udv8qc75jynloq

Это стандартный dashboard производительности Zabbix — сервера.

Первый голубой график — количество значений в секунду. Второй график справа — загрузка процессов сборки. Третий — загрузка внутренних процессов сборки: history syncers и Housekeeper, который здесь выполнялся достаточное время.

Четвертый график показывает использование HistoryCache. Это некий буфер перед вставкой в БД. Зеленый пятый график показывает использование ValueCache, то есть сколько хитов ValueCache для триггеров — это несколько тысяч значений в секунду.

PostgreSQL. 50 000 nvps

Дальше я увеличил нагрузку до 50 тыс значений в секунду на этом же железе.

wj47u6j2fycdpnx55 mrrqrwcp4

При загрузке с Housekeeper вставка 10 тыс значений записывалась 2-3 с.

Housekeeper уже начинает мешать работе.

По третьему графику видно, что, в целом, загрузка трапперов и history syncers пока еще на уровне 60%. На четвертом графике HistoryCache во время работы Housekeeper уже начинает достаточно активно заполняться. Он заполнился на 20% — это около 0,5 ГБ.

PostgreSQL. 80 000 nvps

Дальше я увеличил нагрузку до 80 тыс значений в секунду. Это примерно 400 тыс элементов данных и 280 тыс триггеров.

8qzh5zsbwvouradg7j
Вставка по загрузке тридцати history syncers уже достаточно высокая.

Также я увеличивал различные параметры: history syncers, кэши.

На моем железе загрузка history syncers увеличивалась до максимума. HistoryCache быстро заполнился данными — в буфере накопились данные для обработки.

Все это время я наблюдал, как используется процессор, оперативная память и другие параметры системы, и обнаружил, что утилизация дисков была максимальна.

Я добился использования максимальных возможностей диска на этом железе и на этой виртуальной машине. При такой интенсивности PostgreSQL начал сбрасывать данные достаточно активно, и диск уже не успевал работать на запись и чтение.

Второй сервер

Я взял другой сервер, который имел уже 48 процессоров и 128 ГБ оперативной памяти. Затюнинговал его — поставил 60 history syncer, и добился приемлемого быстродействия.

Фактически, это уже предел производительности, где необходимо что-то предпринимать.

TimescaleDB. 80 000 nvps

Моя главная задача — проверить возможности TimescaleDB от нагрузки Zabbix. 80 тыс значений в секунду — это много, частота сбора метрик (кроме Яндекса, конечно) и достаточно большой «setup».

На каждом графике есть провал — это как раз миграция данных. После провалов в Zabbix-сервере профиль загрузки history syncer очень сильно изменился — упал в три раза.

TimescaleDB позволяет вставлять данные практически в 3 раза быстрее и использовать меньше HistoryCache.

Соответственно, у вас своевременно будут поставляться данные.

TimescaleDB. 120 000 nvps

Дальше я увеличил количество элементов данных до 500 тыс. Главная задача была проверить возможности TimescaleDB — я получил расчетное значение 125 тыс значений в секунду.

Это рабочий «setup», который может долго работать. Но так как мой диск был всего на 1,5 ТБ, то я его заполнил за пару дней.

Самое важное, что в это же время создавались новые партиции TimescaleDB.

Для производительности это совершенно незаметно. Когда создаются партиции в MySQL, например, все иначе. Обычно это происходит ночью, потому что блокирует общую вставку, работу с таблицами и может создавать деградацию сервиса. В случае с TimescaleDB этого нет.

Для примера покажу один график из множества в community. На картинке включен TimescaleDB, благодаря этому загрузка по использованию io.weight на процессоре упала. Использование элементов внутренних процессов тоже снизилось. Причем это обычная виртуалка на обычных блинных дисках, а не SSD.

e6bma otl8o5mcrt9z8wkrsq5du

Выводы

TimescaleDB хорошее решение для маленьких «setup», которые упираются в производительность диска. Оно позволит неплохо продолжать работать до миграции БД на железо побыстрее.

TimescaleDB прост в настройке, дает прирост производительности, хорошо работает с Zabbix и имеет преимущества по сравнению с PostgreSQL.

Если вы применяете PostgreSQL и не планируете его менять, то рекомендую использовать PostgreSQL с расширением TimescaleDB в связке с Zabbix. Это решение эффективно работает до средних «setup».

Говорим «высокая производительность» — подразумеваем HighLoad++. Ждать, чтобы познакомиться с технологиями и практиками, позволяющими сервисам обслуживать миллионы пользователей, совсем недолго. Список докладов на 7 и 8 ноября мы уже составили, а вот митапы еще можно предложить.

Подписывайтесь на нашу рассылку и telegram, в которых мы раскрываем фишки предстоящей конференции, и узнайте, как извлечь максимум пользы.


Источник: biznessrussia.ru