Нагрузка на сервер

[Sunrise_94]

Здравствуйте

Подскажите пожалуйста что надо сделать, чтоб снизить нагрузку на zabbix: имеется сервер с двумя(в зеркале) SSD дисками, и оперативной памятью 100ГБ. На данный момент оперативная память занята на 90%, размер БД 200ГБ.
Также начал замечать, что некоторые оповещения в телеграмм приходят с опозданием на пол дня. Ранее пытался настроить некоторые параметры такие как: internal processes, syncer internal processes, escalator и др. В окончательном итоге не смог найти необходимые значения для корректной работы. Прошу помочь разобраться с параметрами и снизить нагрузку нагрузку на сервер. Не думаю что при небольшом количестве (32 000) активных элементов данных, расходуется столько памяти ОЗУ.
Ниже параметры zabbix сервера и БД Mysql которые менялись, для более понятной ситуации.
Менял методом гугления, и получилось примерно так:

zabbix_server.conf
LogFileSize=0
StartPollers=700
StartSNMPPollers=300
StartPreprocessors=400
StartPollersUnreachable=100
StartHistoryPollers=100
StartTrappers=100
StartPingers=50
StartDiscoverers=50
StartTimers=10
StartEscalators=90
StartAlerters=100
HousekeepingFrequency=4
MaxHousekeeperDelete=1000000
CacheSize=10G
StartDBSyncers=60
HistoryCacheSize=2048M
HistoryIndexCacheSize=256M
ValueCacheSize=256M
Timeout=30
LogSlowQueries=3000
StartLLDProcessors=30

my.cnf

[mysqld]
# ======
max_allowed_packet = 128M
thread_stack = 256K
max_connections = 500

# === InnoDB BUFFER POOL ===
innodb_buffer_pool_size = 70G
innodb_buffer_pool_instances = 16
innodb_buffer_pool_chunk_size = 1G

# === InnoDB LOG ===
innodb_log_buffer_size = 256M
innodb_redo_log_capacity = 10G
innodb_log_files_in_group = 2

# === InnoDB ===
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_file_per_table = ON
innodb_flush_neighbors = 0
innodb_read_io_threads = 64
innodb_write_io_threads = 64
innodb_io_capacity = 4000
innodb_io_capacity_max = 8000
innodb_purge_threads = 4
innodb_thread_concurrency = 0
innodb_adaptive_hash_index = OFF

# ======
join_buffer_size = 16M
tmp_table_size = 256M
max_heap_table_size = 256M
sort_buffer_size = 8M
read_buffer_size = 4M
read_rnd_buffer_size = 8M
table_open_cache = 10000
table_definition_cache = 4000
table_open_cache_instances = 16

# === ZABBIX ===
open_files_limit = 65535
max_prepared_stmt_count = 128000
transaction_isolation = READ-COMMITTED
binlog_format = ROW
sync_binlog = 0

# ======
skip_name_resolve = 1
back_log = 3000
thread_cache_size = 100
wait_timeout = 600
interactive_timeout = 600

[Kos]

Ну вот смотрите - у вас сервер, по вашим же словам, имеет 100 гигабайт RAM, при этом из них только под один кэш MySQL выделено 70, и только под один кэш конфигурации Zabbix выделено ещё 10. Т.е. только под эти два кэша у вас уже жёстко зарезервировано 80% RAM, под всё остальное (сама операционка, все процессы Zabbix, все остальные кэши) остаётся 20 GB. Подозреваю, что из-за перерасхода ресурсов, выделенных серверу Zabbix (в первую очередь - память и количество серверных процессов различных видов) получается обратный эффект: этих ресурсов недостаёт на самое нужное.
Я не специалист по СУБД, в этом отношении ничего не посоветую (в принципе, иметь большой кэш для СУБД - это нормально).
Но вот в отношении конфигурации сервера Zabbix...

У нас с вами более-менее подобные по нагрузке и по версии Zabbix серверы (см. скриншоты). Правда, у меня используется другая СУБД (PostgreSQL), но не думаю, что это здесь принципиально.
Но у нас проблем с производительностью нет.
Просто привожу свои данные для сравнения.

Аппаратная конфигурация нашего сервера - это HPE ProLiant DL360 Gen10:

• CPU: 1x Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz (10 cores with Hyperthreading)
• RAM: 64 GB, 2400 MHz, 1.2 V
• RAID Controller: HPE Smart Array P408i-a SR Gen10
• HDD: 2x 447 GiB SSD в зеркале (hardware RAID1)

Вот цитата из нашего zabbix_server.conf:

StartSNMPPollers=5
StartPollersUnreachable=5
StartTrappers=5
StartPingers=8
StartDiscoverers=1
StartHTTPPollers=3
StartEscalators=3
JavaGateway=localhost
StartVMwareCollectors=2
VMwareCacheSize=128M
StartSNMPTrapper=1
ListenIP=*****
CacheSize=256M
HistoryCacheSize=256M
HistoryIndexCacheSize=64M
TrendCacheSize=64M
TrendFunctionCacheSize=16M
ValueCacheSize=512M
Timeout=4
LogSlowQueries=3000
StatsAllowedIP=127.0.0.1
StartODBCPollers=2
EnableGlobalScripts=1

(остальные серверные процессы - по умолчанию)

Реальная статистика сервера - на скриншотах.

[PavelZ]

Делайте partitioning через скрипт для mysql. Все инсталляции на mysql вынуждены этим заниматься. Работа всех компонент zabbix автоматически улучшается.

CacheSize=10G

А это действительно нужно?

Так же нужно разобраться как именно память распределена между компонентами.
mysql, php, zabbix - это отдельные компоненты и действовать нужно по-разному.

[Sunrise_94]

>> А это действительно нужно?
Думаю, что нет, но где-то нашел рекомендации что необходимо повысить этот параметр

[Jimson]

смигрировать вручную данные в pgsql+tsdb не проще и главное надежнее чем со скриптами партиционированя на mysql? у меня у самого старые забиксы под mysql, сказать что плохо это ничего не сказать, еще и дважды уже ловил сбой innodb, пересоздавать террабайтный mysql вообще поминки, хз как будет житься под pgsql, надеюсь сильно лучше
а миграцию можно вообще устроить через мипорт/экспорт на другой сервак - создать вначале всю структуру, а потом выгрести идентификаторы метрик sql запросами, составить табличку старый>новый, сдернуть с mysql данные, sed, подсунуть psql
не очень просто, но это можно уже делать при работающем новом сервере, ну или забить на старый метрики, подержать включенным оба сервера пару недель, а потом переключиться на новый как так и было

[Sunrise_94]

Спасибо за идею, я подумаю как поступить в будущем, но это мне нравится явно больше

[Kos]

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

• слишком большое количество процессов (вам реально нужно 400 препроцессоров и 300 SNMP поллеров?). Стандартный шаблон для сервера Zabbix имеет графики загруженности серверных процессов - по ним и нужно ориентироваться, не надо плодить лишнего. А DBSyncer'ов вообще не рекомендуют делать больше четырёх (это значение по умолчанию, ссылка) без явных рекомендаций от техподдержки;
• 10 гигабайт под кэш конфигурации (CacheSize=10G) при крошечном размере под кэш истории (ValueCacheSize=256M) - как-то странно. Обычно бывает обратное соотношение. Смотреть, опять же, ориентируясь на графики в стандартном шаблоне для сервера Zabbix.

[PavelZ]

смигрировать вручную данные в pgsql+tsdb не проще и главное надежнее чем со скриптами партиционированя на mysql?

Кажется, про TSDB больше пишут и говорят, однако c точки зрения перекладывания ответственности, фичи типа partition и compression в Mysql обеспечивают непосредственно Oracle.
И исторически это довольно традиционные обкатанные фичи. Все должно быть очень надежно.
Стоит упомянуть, что компрессия по сравнению с TSDB все-таки похуже будет. Нет никаких специальных штук типа delta-кодирования.

дважды уже ловил сбой innodb

Нет issue, нет bug id , нет резолюции от Oracle - не считается.

[guntis_liepins]

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

• слишком большое количество процессов (вам реально нужно 400 препроцессоров и 300 SNMP поллеров?). Стандартный шаблон для сервера Zabbix имеет графики загруженности серверных процессов - по ним и нужно ориентироваться, не надо плодить лишнего. А DBSyncer'ов вообще не рекомендуют делать больше четырёх (это значение по умолчанию, ссылка) без явных рекомендаций от техподдержки;
• 10 гигабайт под кэш конфигурации (CacheSize=10G) при крошечном размере под кэш истории (ValueCacheSize=256M) - как-то странно. Обычно бывает обратное соотношение. Смотреть, опять же, ориентируясь на графики в стандартном шаблоне для сервера Zabbix.

Название темплейта "Zabbix Server Health" , host Dashboard "Zabbix server health" -> "Processes".
По моему опыту многие не знают или не смотрят туда.
Там же можно изпользование кеша смотреть , под Performance.

[Sunrise_94]

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

• слишком большое количество процессов (вам реально нужно 400 препроцессоров и 300 SNMP поллеров?). Стандартный шаблон для сервера Zabbix имеет графики загруженности серверных процессов - по ним и нужно ориентироваться, не надо плодить лишнего. А DBSyncer'ов вообще не рекомендуют делать больше четырёх (это значение по умолчанию, ссылка) без явных рекомендаций от техподдержки;
• 10 гигабайт под кэш конфигурации (CacheSize=10G) при крошечном размере под кэш истории (ValueCacheSize=256M) - как-то странно. Обычно бывает обратное соотношение. Смотреть, опять же, ориентируясь на графики в стандартном шаблоне для сервера Zabbix.

Версия Zabbix 7.0.12
>>слишком большое количество процессов (вам реально нужно 400 препроцессоров и 300 SNMP поллеров?).
Думаю что нет

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

[PavelZ]

Если вы "накручиваете" всевозможные кеши, буферы и воркеры, очевидно что memory utilization растет и растет вплоть до прекращения нормальной работы. Конечно, разумно там все уменьшить чтобы стабилизировать.

Но partitioning или TSDB все равно придется делать. Так уж повелось.

[Kos]

Ну вот смотрите - у вас сервер, по вашим же словам, имеет 100 гигабайт RAM, при этом из них только под один кэш MySQL выделено 70, и только под один кэш конфигурации Zabbix выделено ещё 10. Т.е. только под эти два кэша у вас уже жёстко зарезервировано 80% RAM, под всё остальное (сама операционка, все процессы Zabbix, все остальные кэши) остаётся 20 GB. Подозреваю, что из-за перерасхода ресурсов, выделенных серверу Zabbix (в первую очередь - память и количество серверных процессов различных видов) получается обратный эффект: этих ресурсов недостаёт на самое нужное.
Я не специалист по СУБД, в этом отношении ничего не посоветую (в принципе, иметь большой кэш для СУБД - это нормально).
Но вот в отношении конфигурации сервера Zabbix...

У нас с вами более-менее подобные по нагрузке и по версии Zabbix серверы (см. скриншоты). Правда, у меня используется другая СУБД (PostgreSQL), но не думаю, что это здесь принципиально.
Но у нас проблем с производительностью нет.
Просто привожу свои данные для сравнения.

Аппаратная конфигурация нашего сервера - это HPE ProLiant DL360 Gen10:

• CPU: 1x Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz (10 cores with Hyperthreading)
• RAM: 64 GB, 2400 MHz, 1.2 V
• RAID Controller: HPE Smart Array P408i-a SR Gen10
• HDD: 2x 447 GiB SSD в зеркале (hardware RAID1)

Вот цитата из нашего zabbix_server.conf:

StartSNMPPollers=5
StartPollersUnreachable=5
StartTrappers=5
StartPingers=8
StartDiscoverers=1
StartHTTPPollers=3
StartEscalators=3
JavaGateway=localhost
StartVMwareCollectors=2
VMwareCacheSize=128M
StartSNMPTrapper=1
ListenIP=*****
CacheSize=256M
HistoryCacheSize=256M
HistoryIndexCacheSize=64M
TrendCacheSize=64M
TrendFunctionCacheSize=16M
ValueCacheSize=512M
Timeout=4
LogSlowQueries=3000
StatsAllowedIP=127.0.0.1
StartODBCPollers=2
EnableGlobalScripts=1

(остальные серверные процессы - по умолчанию)

Реальная статистика сервера - на скриншотах.

[Kos]

Да, ещё картинку о использованию кэша забыл (данные за последние 2 суток):

[Kos]

Ну и ещё пара замечаний:

• В Zabbix 7.0.x появились асинхронные поллеры (ссылка). Один такой поллер спокойно выполняет до 1000 проверок одновременно (по умолчанию, можно изменить парметром MaxConcurrentChecksPerPoller). Другими словами - там, где раньше требовалась тысяча поллеров для SNMP-опросов, сейчас достаточно одного (правда, сами проверки должны поддерживать асинхронные поллеры - т.е. в поле "OID" содержать не просто OID, а ещё явное указание "walk" или "get", ссылка).
• Текущий релиз Zabbix 7.0.x - это 7.0.23. У вас установлен 7.0.12 - он вышел почти год назад (ссылка), в каждом релизе есть какие-то исправления; в том числе было и несколько исправлений утечек памяти при различных условиях. Я бы крайне рекомендовал обновиться, тем более, что в рамках одной версии (7.0.х в данном случае) это выполняется достаточно безболезненно.

[Sunrise_94]

Ну вот смотрите - у вас сервер, по вашим же словам, имеет 100 гигабайт RAM, при этом из них только под один кэш MySQL выделено 70, и только под один кэш конфигурации Zabbix выделено ещё 10. Т.е. только под эти два кэша у вас уже жёстко зарезервировано 80% RAM, под всё остальное (сама операционка, все процессы Zabbix, все остальные кэши) остаётся 20 GB. Подозреваю, что из-за перерасхода ресурсов, выделенных серверу Zabbix (в первую очередь - память и количество серверных процессов различных видов) получается обратный эффект: этих ресурсов недостаёт на самое нужное.
Я не специалист по СУБД, в этом отношении ничего не посоветую (в принципе, иметь большой кэш для СУБД - это нормально).
Но вот в отношении конфигурации сервера Zabbix...

У нас с вами более-менее подобные по нагрузке и по версии Zabbix серверы (см. скриншоты). Правда, у меня используется другая СУБД (PostgreSQL), но не думаю, что это здесь принципиально.
Но у нас проблем с производительностью нет.
Просто привожу свои данные для сравнения.

Аппаратная конфигурация нашего сервера - это HPE ProLiant DL360 Gen10:

• CPU: 1x Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz (10 cores with Hyperthreading)
• RAM: 64 GB, 2400 MHz, 1.2 V
• RAID Controller: HPE Smart Array P408i-a SR Gen10
• HDD: 2x 447 GiB SSD в зеркале (hardware RAID1)

Вот цитата из нашего zabbix_server.conf:

StartSNMPPollers=5
StartPollersUnreachable=5
StartTrappers=5
StartPingers=8
StartDiscoverers=1
StartHTTPPollers=3
StartEscalators=3
JavaGateway=localhost
StartVMwareCollectors=2
VMwareCacheSize=128M
StartSNMPTrapper=1
ListenIP=*****
CacheSize=256M
HistoryCacheSize=256M
HistoryIndexCacheSize=64M
TrendCacheSize=64M
TrendFunctionCacheSize=16M
ValueCacheSize=512M
Timeout=4
LogSlowQueries=3000
StatsAllowedIP=127.0.0.1
StartODBCPollers=2
EnableGlobalScripts=1

(остальные серверные процессы - по умолчанию)

Реальная статистика сервера - на скриншотах.

Да, вижу что неправильно выставленные параметры привели к обратному эффекту. Посмотрел все скриншоты вашего Zabbix сервера, и действительно, нагрузки более менее одинаковые(прикрепил дополнительно скрин статистики), даже сервер похож, у меня HPE ProLiant DL360 Gen9.
Что касается параметров zabbix_server.conf, попробую выставить похоже параметры как у вас, да и в принципе, понял что необходимо поправить. С СУБД да, необходимо будет продумать дальнейшие действия. но это уже после того, как стабилизирую используемые ресурсы и обновлю Zabbix сервер.
Kos, еще раз, спасибо вам большое за помощь, в очередной раз помогли и сориентировали.

Также благодарю всех, кто помог советами на что стоит обратить внимание