А АSunday, 1 November 2020

Zabbix performance tuning #3.

Всем привет.

Оптимизация Zabbix-а опять на повестке дня. Я вам, наверное, с этим уже надоел. Но сегодня мы, наконец-то, добрались до реального случая. Я кратко покажу что мы меняли на своем сервере, за исключением параметров для базы данных. В разделе БД мнения разделились поэтому ниже опишу только то, что нам предлагали, но что так мы не успели оценить практически. Поехали.

Для беглого мониторинга средствами Zabbix был собран вот такой вот полигон.


Как же мы оценивали "здоровье" нашего Zabbix-сервера?

Этап 1.
По штатным графикам:
Zabbix data gathering process busy %
Zabbix internal process busy %

а также по
Zabbix internal queues
Zabbix server performance

оцениваем максимальные значения загруженности Zabbix-a.


Чтобы уменьшить эти величины меняем дефолтные в
#sudo nano /etc/zabbix/zabbix_server.conf
на

StartPollers=50
StartPreproceessors = 60
StartPollersUnreachable=30
StartPingers=100
StartIPMIPollers=10
StartTrappers=20
StartDBSyncers=8

Не забываем передернуть службу zabbix-server:
#sudo service zabbix-server restart
Опять оцениваем результат по тем же графикам.


Этап 2.
По штатным графикам
Value cache effectiveness (vps)
Zabbix cache usage, %free
Zabbix cache usage, %usage

оцениваем максимальные значения использования кеша Zabbix-a.

Чтобы уменьшить эти величины меняем дефолтные в конфиге Zabbix-a на
CacheSize=64M
HistoryCacheSize=32M
HistoryIndexCacheSize=16M
TrendCacheSize=16M
ValueCacheSize=32M

Не забываем передернуть службу zabbix-server:
#sudo service zabbix-server restart
Опять оцениваем результат по тем же графикам.

Также я находил некоторые рекомендации изменить еще эти два параметра:
Timeout=30
LogSlowQueries=1000

Установка Timeout в максимальное значение может как ускорить работу Zabbiх так и замедлить. Тут есть прямая зависимость от количества запросов ответы на которые Zabbiх будет ждать до 30 секунд.

Этап 3.
Обязательно устанавливаем частоту запуска процедуры очистки базы данных (в часах, от 1 до 24);
HousekeepingFrequency = 1

А также количество удаляемых за раз значений (от 1 до 1000000)
MaxHousekeeperDelete = 1000000

Этап 4.
Что касается БД то вашему вниманию могут быть полезны следующие параметры
#sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf

max_connections = 400
tmp_table_size = 256M
max_heap_table_size = 256M
table_open_cache = 64M
join_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
sort_buffer_size = 16M
key_buffer_size = 16M
thread_stack = 192K
thread_cache_size = 8
query_cache_limit = 2M
query_cache_size = 32M
table_open_cache = 64M


innodb_file_per_table = 1
innodb_status_file = 1
innodb_buffer_pool_size = 2G
innodb_flush_log_at_trx_commit = 2
innodb_support_xa = 0
innodb_log_file_size = 256M
innodb_log_buffer_size = 16M


Для диагностики конфигурации MySQL также можно использовать внешнюю утилиту mysqltuner. После ее выполнения будет получен развернутый результат в котором следует обратить внимание на строки с отметкой [!!] и изучить раздел "Recommendations".

appliance@zabbix:~$ sudo mysqltuner
[OK] Logged in using credentials from debian maintenance account.
 >>  MySQLTuner 1.6.0 - Major Hayden <major@mhtx.net>
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.7.31-0ubuntu0.16.04.1
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics
[--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM
[--] Data in InnoDB tables: 4G (Tables: 150)
[!!] Total fragmented tables: 12

-------- Performance Metrics
[--] Up for: 62d 9h 44m 18s (113M q [21.100 qps], 102K conn, TX: 146B, RX: 17B)
[--] Reads / Writes: 52% / 48%
[--] Binary logging is disabled
[--] Total buffers: 192.0M global + 1.1M per thread (151 max threads)
[OK] Maximum reached memory usage: 353.5M (18.19% of installed RAM)
[OK] Maximum possible memory usage: 352.4M (18.13% of installed RAM)
[OK] Slow queries: 0% (0/113M)
[!!] Highest connection usage: 100%  (152/151)
[OK] Aborted connections: 0.02%  (16/102191)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 1% (89K temp sorts / 5M sorts)
[!!] Joins performed without indexes: 201533
[!!] Temporary tables created on disk: 28% (201K on disk / 717K total)
[OK] Thread cache hit rate: 99% (575 created / 102K connections)
[!!] Table cache hit rate: 0% (416 open / 3M opened)
[OK] Open file limit used: 0% (0/1K)
[OK] Table locks acquired immediately: 100% (102 immediate / 102 locks)

-------- MyISAM Metrics
[!!] Key buffer used: 18.2% (3M used / 16M cache)
[OK] Key buffer size / total MyISAM indexes: 16.0M/43.0K
[!!] Read Key buffer hit rate: 50.0% (6 cached / 3 reads)

-------- InnoDB Metrics
[--] InnoDB is enabled.
[!!] InnoDB buffer pool / data size: 128.0M/4.2G
[OK] InnoDB buffer pool instances: 1
[OK] InnoDB Used buffer: 86.61% (7094 used/ 8191 total)
[OK] InnoDB Read buffer efficiency: 99.93% (20633337417 hits/ 20648353940 total)
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total)
[OK] InnoDB log waits: 0.00% (0 waits / 18022578 writes)

Recommendations
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce or eliminate persistent connections to reduce connection usage
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries which have no LIMIT clause
    Increase table_open_cache gradually to avoid file descriptor limits
    Read this before increasing table_open_cache over 64: http://bit.ly/1mi7c4C
    Beware that open_files_limit (1024) variable
    should be greater than table_open_cache ( 431)

Variables to adjust:
    max_connections (> 151)
    wait_timeout (< 28800)
    interactive_timeout (< 28800)
    query_cache_type (=1)
    join_buffer_size (> 256.0K, or always use indexes with joins)
    tmp_table_size (> 16M)
    max_heap_table_size (> 16M)
    table_open_cache (> 431)
    innodb_buffer_pool_size (>= 4G) if possible.

На этом все.

No comments:

Post a Comment

А что вы думаете по этому поводу?

Версия на печать

Популярное