[fractal]

Приветствую, нужна помощь по оптимизации сервера Zabbix, вообщем недели 2 назад стал стопариться сервак Zabbix, посоветовали увеличить память, и кое какие строки в конфе, сделал так:

 

CacheSize=512M

StartPingers=15

StartPollers=30

HistoryCacheSize=512M

StartPollersUnreachable=15

HousekeepingFrequency=24

Timeout = 20

 

Процессы пингов и полеров увеличил исходя их графиков самого zabbix агента на сервере, базе примерно 3-5 месяцев на текущий момент, походу хаускипер не справляется, база 155 гигов, планируется хранить около полугода инфы,

 

система:

 

I5 4690, 6ГБ памяти, хард 4 штуки в Raid 10

 

на сервер в скором времени доставим до 32 гб памяти, слышал еще желательно базу данных разбивать по секциям и отключать хаускипер, нашел статью http://unixadm.info/content/разбиение-секционирование-в-бд-zabbix-mysql

она мне подойдет? сильно в mysql не силен

[saaremaa]

Сколько у Вас узлов мониторится? Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

[fractal]

Сколько у Вас узлов мониторится? Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

 

пока всего

 

Количество узлов сети (активированных/деактивированных/шаблонов) 163 117 / 0 / 46

Количество элементов данных (активированных/деактивированных/неподдерживаемых) 13134 12745 / 0 / 389

[fractal]

Сколько у Вас узлов мониторится? Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

 

пока всего

 

Количество узлов сети (активированных/деактивированных/шаблонов) 163 117 / 0 / 46

Количество элементов данных (активированных/деактивированных/неподдерживаемых) 13134 12745 / 0 / 389

 

причем память 6 гигов практически забиты

[fractal]

Сколько у Вас узлов мониторится? Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

 

пока всего

 

Количество узлов сети (активированных/деактивированных/шаблонов) 163 117 / 0 / 46

Количество элементов данных (активированных/деактивированных/неподдерживаемых) 13134 12745 / 0 / 389

 

причем память 6 гигов практически забиты

 

хотя нет, занято всего 900

 

 free -m
            total       used       free     shared    buffers     cached
Память:       5968       5834        134         33        132       4760
-/+ буферы/кэш:        940       5027
Swap:         1023         41        982

[sol]

Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

А настройками постгреса и масштабом сервера не поделитесь?

[saaremaa]

А настройками постгреса и масштабом сервера не поделитесь?

CPU i3 4130 3.4/3Mb LGA 1150; Платформа R1304RPOSHBN; DDR-3 16 GB PC3-12800 ECC; HDDx4 4TB RAID1

Настройки постгресса к сожалению сами - там оптимизация нужна и она разная у всех.

[FATHER_FBI]

Покажи лог, забикс пишет почему он остановился.

 

Сколько у Вас узлов мониторится? Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

Значит не правильно настраивали, у меня больше 1000 узлов и 100к элементов данных, крутиться все на mariadb в виртуальной машине (4 vCPU, 4 vRAM)

Edited June 29, 2016 by FATHER_FBI

[fractal]

в предыдущий раз из за CacheSize, его выставил 512 и вроде перестал стопариться, а сегодня выдал ошибку доступа к sock mysql, вручную стартовал

[sol]

HDDx4 4TB RAID1

А вот тут поподробнее мона?

Настройки постгресса к сожалению сами - там оптимизация нужна и она разная у всех.

Заббикс одинаковый а оптимизация разная ?!?

[saaremaa]

Заббикс одинаковый а оптимизация разная ?!?

У нас есть особенности данных которые опрашиваются часто и хранятся промежуточно в Redis в zabbix-postgresql они пападают самописными скриптами. Почему так - объяснять долго да и не надо. Я не уверен что это вам подойдет - готового решения по оптимизации я вам не дам.

А вот тут поподробнее мона?

Опечатался "HDDx2 4TB RAID1" 2 винта в зеркале.

[fractal]

Опечатался "HDDx2 4TB RAID1" 2 винта в зеркале.

 

Производительность не страдает?

 

по моис параметрам не смотрели может мне по памяти кэш что увеличить?

[Negator]

1.Настраивайте партицирование

http://unixadm.info/content/%D1%80%D0%B0%D0%B7%D0%B1%D0%B8%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%B5%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B2-%D0%B1%D0%B4-zabbix-mysql

 

2. Оптимизируйте сбор информации с железок. Собирать всю инфу каждые 30 сек с каждой железки бессмысленно.

3. Старые данные из базы можно чистить, даже вручную, зачем вам графики полугодовой давности.

 

У нас все это крутится на Xeon-ах еще первого поколения с 4 гбайтами памяти. А хостов чуть больше 1000.

Без партицирования были проблемы. Сейчас давно все ок.

[saaremaa]

Производительность не страдает?

при бэкапах да есть проблемы.

[fractal]

1.Настраивайте партицирование

http://unixadm.info/content/%D1%80%D0%B0%D0%B7%D0%B1%D0%B8%D0%B5%D0%BD%D0%B8%D0%B5-%D1%81%D0%B5%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%B2-%D0%B1%D0%B4-zabbix-mysql

 

2. Оптимизируйте сбор информации с железок. Собирать всю инфу каждые 30 сек с каждой железки бессмысленно.

3. Старые данные из базы можно чистить, даже вручную, зачем вам графики полугодовой давности.

 

У нас все это крутится на Xeon-ах еще первого поколения с 4 гбайтами памяти. А хостов чуть больше 1000.

Без партицирования были проблемы. Сейчас давно все ок.

 

графики необходимо полугодовой, так решила дирекция, денег не жалко) по партиционированию не понял, в частности по дням, даты вводить до конца года?

 

mysql> ALTER TABLE `history_uint` PARTITION BY RANGE ( clock)
(PARTITION p2014_02_01 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-02 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_02 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-03 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_03 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-04 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_04 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-05 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_05 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-06 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_06 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-07 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_07 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-08 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_08 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-09 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_09 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-10 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_10 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-11 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_11 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-12 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_12 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-13 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_13 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-14 00:00:00") div 1) ENGINE = InnoDB,
PARTITION p2014_02_14 VALUES LESS THAN (UNIX_TIMESTAMP("2014-02-15 00:00:00") div 1) ENGINE = InnoDB);

 

по дням до конца месяца с текущего дня когда начинаю делать? или я не совсем понял?) не совсем с sql дружу) и потом далее там про автоудаление старых данных, за какой срок удаляться будут?

 

даты вводить до конца года? или можно взять 10 дней и далее уже все автоматом будет создаваться?

[zlolotus]

Покажи лог, забикс пишет почему он остановился.

 

Сколько у Вас узлов мониторится? Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

Значит не правильно настраивали, у меня больше 1000 узлов и 100к элементов данных, крутиться все на mariadb в виртуальной машине (4 vCPU, 4 vRAM)

 

В виртуальной машине? Вы серьезно?

[FATHER_FBI]

Покажи лог, забикс пишет почему он остановился.

 

Сколько у Вас узлов мониторится? Мы после 1000-го узла перевели Zabbix на PostgreSQL. Плохело Mysqlу очень.

Значит не правильно настраивали, у меня больше 1000 узлов и 100к элементов данных, крутиться все на mariadb в виртуальной машине (4 vCPU, 4 vRAM)

 

В виртуальной машине? Вы серьезно?

 

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

 

[root@zabbix ~]# cat /proc/cpuinfo | grep 'model name'
model name      : Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
model name      : Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
model name      : Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
model name      : Intel(R) Xeon(R) CPU           X5670  @ 2.93GHz
[root@zabbix ~]# w
12:14:12 up 28 days, 13:57,  2 users,  load average: 0.26, 0.24, 0.33
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1                      Mon14    2days  0.01s  0.01s -bash
root     pts/0    ***.**.**.***    12:10    4.00s  0.01s  0.00s w
[root@zabbix ~]# free mem
             total        used        free      shared  buff/cache   available
Mem:        4047324     1504608      200636       71944     2342080     2191456
Swap:       1048572      352756      695816

[fractal]

а у меня что то Zabbix дохнет

[FATHER_FBI]

а у меня что то Zabbix дохнет

На графике видно что запустился хаускипер и следом появилась нагрузка на синкере, на 99% уверен что у тебя не хватка IOPS на дисковой подсистеме. Есть график загрузки дисков? Так же покажи график потребления памяти, если не хватает IOPS, у тебя база должна жрать память из за кеширования.

[fractal]

а у меня что то Zabbix дохнет

На графике видно что запустился хаускипер и следом появилась нагрузка на синкере, на 99% уверен что у тебя не хватка IOPS на дисковой подсистеме. Есть график загрузки дисков? Так же покажи график потребления памяти, если не хватает IOPS, у тебя база должна жрать память из за кеширования.

 

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

 

free -m
            total       used       free     shared    buffers     cached
Память:       5968       5837        131         36        147       4756
-/+ буферы/кэш:        932       5035
Swap:         1023         52        971

[SergeiK]

+1 к FATHER_FBI.

 

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

Самый простой и эффективный способ помочь беде - сделать для всех одинаковое время истории, и одинаковое время трендов, зайти в общие настройки, там в настройки хаускипера, и выставить для истории и трендов эти общие для всех настройки, не забыв поставить галку "перезаписывать значения для всех параметров".

 

Более сложный, но еще более производительный способ, позволяющий выставлять время хранения строковых значений, целых, десятичных раздельные - это партирование таблиц.

 

Плюс, смотреть в настройках, сколько максимально можно данных удалять, а в логах, сколько данных удалено, и если удаляется всегда максимум, максимум этот увеличить.

 

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

 

free -m
            total       used       free     shared    buffers     cached
Память:       5968       5837        131         36        147       4756
-/+ буферы/кэш:        932       5035
Swap:         1023         52        971

В стандартном Linux шаблоне есть графики CPU, там есть параметр io. Вот он наверняка под 30-35%, это очень много.

[fractal]

+1 к FATHER_FBI.

 

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

Самый простой и эффективный способ помочь беде - сделать для всех одинаковое время истории, и одинаковое время трендов, зайти в общие настройки, там в настройки хаускипера, и выставить для истории и трендов эти общие для всех настройки, не забыв поставить галку "перезаписывать значения для всех параметров".

 

Более сложный, но еще более производительный способ, позволяющий выставлять время хранения строковых значений, целых, десятичных раздельные - это партирование таблиц.

 

Плюс, смотреть в настройках, сколько максимально можно данных удалять, а в логах, сколько данных удалено, и если удаляется всегда максимум, максимум этот увеличить.

 

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

 

free -m
            total       used       free     shared    buffers     cached
Память:       5968       5837        131         36        147       4756
-/+ буферы/кэш:        932       5035
Swap:         1023         52        971

В стандартном Linux шаблоне есть графики CPU, там есть параметр io. Вот он наверняка под 30-35%, это очень много.

 

iowait time? партицирование планирую делать по данной статье http://unixadm.info/content/разбиение-секционирование-в-бд-zabbix-mysql инфу необходимо хранить полгода, по партицированию не понял сколько дней надо делать.

 

Плюс, смотреть в настройках, сколько максимально можно данных удалять, а в логах, сколько данных удалено, и если удаляется всегда максимум, максимум этот увеличить. а где посмотреть сколько максимум можно удалять? логи хаускипера также будут в server.log?

 

и про самый простой способ как временный, он находится в администрирование и там очистка истории?

[SergeiK]

 

iowait time? партицирование планирую делать по данной статье http://unixadm.info/content/разбиение-секционирование-в-бд-zabbix-mysql инфу необходимо хранить полгода, по партицированию не понял сколько дней надо делать.

Да.

У вас есть история, где хранится каждое пришедшее в заббикс значение.

У вас есть есть тренды, где хранится усреднение за час. Вам полгода что хранить? Вы уж определитесь заранее.

На полгода я бы рекомендовал бы недельные интервалы делать.

 

Плюс, смотреть в настройках, сколько максимально можно данных удалять, а в логах, сколько данных удалено, и если удаляется всегда максимум, максимум этот увеличить. а где посмотреть сколько максимум можно удалять? логи хаускипера также будут в server.log?

Да, там пишется, что стартовал процесс, потом пишет, что по факту его работы удалил столько-то записей истории, столько-то событий и прочего.

Надо почитать, сколько времени у вас проходит между стартом и результатом, и сколько записей он удаляет.

 

и про самый простой способ как временный, он находится в администрирование и там очистка истории?

Я не помню названия пунктов, сейчас под рукой нет. Типа того.

Разница должна быть заметна сразу (если процесс хаускипер в работе - лучше рестартовать сервер, через 30 минут хаускипер запустится, но можно толкнуть его вручную командой серверу).

 

P.S. Да, будут проблемы с партированием в MySQL - пишите в личку, что смогу - подскажу.

[FATHER_FBI]

По поводу мониторинга дисков, вот статья https://habrahabr.ru/post/220073/ и вот http://blog.bissquit.com/monitoring/zabbix/zabbix-monitoring-diskovoj-podsistemy/

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

 

P.S. Еще очень сильно сжирает производительность дисков, журналирование файловой системы, в ext это процесс jdb2

Edited June 30, 2016 by FATHER_FBI

[fractal]

 

iowait time? партицирование планирую делать по данной статье http://unixadm.info/content/разбиение-секционирование-в-бд-zabbix-mysql инфу необходимо хранить полгода, по партицированию не понял сколько дней надо делать.

Да.

У вас есть история, где хранится каждое пришедшее в заббикс значение.

У вас есть есть тренды, где хранится усреднение за час. Вам полгода что хранить? Вы уж определитесь заранее.

На полгода я бы рекомендовал бы недельные интервалы делать.

 

Плюс, смотреть в настройках, сколько максимально можно данных удалять, а в логах, сколько данных удалено, и если удаляется всегда максимум, максимум этот увеличить. а где посмотреть сколько максимум можно удалять? логи хаускипера также будут в server.log?

Да, там пишется, что стартовал процесс, потом пишет, что по факту его работы удалил столько-то записей истории, столько-то событий и прочего.

Надо почитать, сколько времени у вас проходит между стартом и результатом, и сколько записей он удаляет.

 

и про самый простой способ как временный, он находится в администрирование и там очистка истории?

Я не помню названия пунктов, сейчас под рукой нет. Типа того.

Разница должна быть заметна сразу (если процесс хаускипер в работе - лучше рестартовать сервер, через 30 минут хаускипер запустится, но можно толкнуть его вручную командой серверу).

 

P.S. Да, будут проблемы с партированием в MySQL - пишите в личку, что смогу - подскажу.

 

спасибоза информацию, буду пробовать на лнять партиционировани делать