И снова про производительность. Zabbix 1.8.2 и mysql innodb

[mschedrin]

вообще 202 в секунду это мягко говоря дохрена. sar -d 1 20 бы увидеть.
А чего база такая маленькая? Время хранения маленькое?

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

а конфиг мускуля где? Сколько памяти вы ему отдали?

Конфиг мускуля могу выложить. Кучу тредов я уже прочитал в этом форуме, советами воспользовался, памяти под innodb_buffer_pool отдано 1024 метра из 2048.

Вообще что конкретно волнует? Тот долгий запрос? Или чего? Я так понимаю что тот запрос из фронтэнда? Зачем он вам?

Волнует, что работает всё это медленно. А если хранить историю чуть чуть больше временин, то вообще мониторинг практически останавливается. База не справляется.

Сейчас многие запросы выполняются с помощью копирования во временную таблицу на жесткий диск. �*то вызывает большую нагрузку на жесткий диск, увеличивает load average, и вообще тормозит процесс мониторинга. От этого я и хочу избавиться.

[Alexei]

Конфиг мускуля могу выложить. Кучу тредов я уже прочитал в этом форуме, советами воспользовался, памяти под innodb_buffer_pool отдано 1024 метра из 2048.

Одного гигабайта достаточно только для небольших (может, 5-10gb) баз данных. Для хорошей производительности нужна память!

[mschedrin]

Одного гигабайта достаточно только для небольших (может, 5-10gb) баз данных. Для хорошей производительности нужна память!

Моя база данных весит 3.3 Гб.
Меня удивляет вот что. При выполнении некоторых запросов заббикса mysql просматривает огромную таблицу history_uint, копирует это во временную папку(в моем случае это /var/tmp) а затем только выдает результат. Копируемые данные в моем случае могут занимать несколько сот мегабайт, сами понимаете сколько времени будет занимать такой запрос. А ведь базы у людей бывают и в десятки гигабайт.
До недавнего времени БД mysql и /var/tmp жили у меня на одном HDD, сейчас я разнес их на разные - это немного улучшило производительность, но до удовлетворительного уровня еще далеко.

Мне кажется, что копирование результатов во временную таблицу - это очень плохой и медленный процесс, особенно с такими объемами данных. По-хорошему, надо было бы оптимизировать запросы заббикса таким образом, чтобы mysql не приходилось использовать временные таблицы.

В моем случае, я собираюсь добавить еще 2Гб оперативной памяти и смонтировать /var/tmp на ramdrive. Ну и конечно же увеличить innodb_buffer_pool.

Алексей, мне кажется, что оптимизация некоторых sql запросов может сильно увеличить производительность взаимодействия zabbix и mysql. Есть ли в планах у разработчиков такой пункт?

[Aly]

innodb_file_per_table есть. Тюнинг innodb тоже проводил скриптом tuning-primer.sh.
Убивают вот такие запросы в slow query log:

# Time: 100413 20:31:13
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 3731  Lock_time: 0  Rows_sent: 80784  Rows_examined: 245941
SELECT i.itemid,i.lastclock,i.description,i.key_,i.type,h.host,h.hostid,h.proxy_hostid,i.delay,i.delay_flex FROM items i,hosts h WHERE i.hostid=h.hostid AND h.status=0 AND i.sta
tus=0 AND i.value_type not in (2) AND i.key_ NOT IN ('status','zabbix[log]') AND NOT i.lastclock IS NULL AND ( i.type in (7,13,14,3,5,8,10,15) OR (h.available<>2 AND i.type in (
0)) OR (h.snmp_available<>2 AND i.type in (1,4,6)) OR (h.ipmi_available<>2 AND i.type in (12))) AND  (h.hostid IN (10404,10403,10470,10449,16600,14880,17377,16651,17730,14856,14
886,16650,10390,17726,10412,10391,10401
... <очень много цифр>
16114,16139) OR h.hostid IN (15439,17158,14972,15951,14979,14985,14984,15938,14986))  AND ((h.hostid  BETWEEN
 000000000000000 AND 099999999999999)) ORDER BY i.lastclock,h.host,i.description,i.key_;

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

Оптимизация запросов приоритетный пункт, подобные проблемы постоянно решаются (по мере поступления).
Данный запрос определённо еще не оптимизировался, не добрались... Он находится в разделе "Queue".
Исправления в запросе будут в ближайшем будущем.

[mschedrin]

Оптимизация запросов приоритетный пункт, подобные проблемы постоянно решаются (по мере поступления).
Данный запрос определённо еще не оптимизировался, не добрались... Он находится в разделе "Queue".
Исправления в запросе будут в ближайшем будущем.

Рад слышать.
Однако таких запросов много. У меня очень часто в tmp каталоге mysql появляются таблицы по 500Мб, что совершенно ненормально.

Чтобы посомтреть screen с графиками загрузки свитча за сутки мне приходится ждать 1-2 минуты, пока выполнится запрос, хотя таблица history_uint занимает у меня всего 1,6 ГБ. Я храню данные очень мало времени. Даже представить сложно, сколько времени подобные запросы выполняются на более крупных системах, ведь я видел, что у людей базы занимают несколько десятков гигабайт. Никак не пойму, все просто не обращают внимания на эту проблему, или у всех кроме меня такие запросы выполняются с нормальной скоростью? Ведь это повседневные запросы, я ими пользуюсь каждый день.

[ugh]

у меня под 300гб была эта табличка))) и ничего)))

[mschedrin]

Ну и как графики строились по такой табличке, нормально? Очень интересен положительный опыт в таких случаях.

[ugh]

нормально строились, вполне
хаускипинг только не работает на таком размере)))

кстати, ваш запрос отношения к history_uint вроде как никакого не имеет

имхо, что-то не так у вас с конфигом мускуля, или просто вцелом сервера мало?

1,8+ вообще очень серьезно в плане оптимизации фронтэнда вырос, хотя вот у меня проблема https://support.zabbix.com/browse/ZBX-2262 вылезла

а вы апгрейдились до 1,8 или ставили начисто? индексы может где лишние/не хватает?

[mschedrin]

Апгрейдился. Скрпиты по модификации базы данных при апгрейде отработали успешно.

Сейчас включу slow query log и покажу как у меня подобные запросы выполняются на намного меньшей базе.

[ugh]

или в дашборде дебаг-мод включить можно )

[mschedrin]

или в дашборде дебаг-мод включить можно )

Про это первый раз слышу, как включить?

[mschedrin]

Вот из slow query log один из запросов:

mysql> explain select i.itemid,i.hostid,h.proxy_hostid,i.type,i.data_type,i.value_type,i.key_,i.snmp_community,i.snmp_oid,i.snmp_port,i.snmpv3_securityname,i.snmpv3_securitylevel,i.snmpv3_authpassphrase,i.snmpv3_privpassphrase,i.ipmi_sensor,i.delay,i.delay_flex,i.trapper_hosts,i.logtimefmt,i.params,i.status,i.authtype,i.username,i.password,i.publickey,i.privatekey from items i,hosts h where i.hostid=h.hostid and h.status in (0) and i.status in (0,3) and i.itemid between 000000000000000 and 099999999999999 order by i.itemid;
+----+-------------+-------+------+-------------------------+---------+---------+-----------------+------+---------------------------------+
| id | select_type | table | type | possible_keys           | key     | key_len | ref             | rows | Extra                           |
+----+-------------+-------+------+-------------------------+---------+---------+-----------------+------+---------------------------------+
|  1 | SIMPLE      | h     | ref  | PRIMARY,hosts_2         | hosts_2 | 4       | const           | 1598 | Using temporary; Using filesort | 
|  1 | SIMPLE      | i     | ref  | PRIMARY,items_1,items_3 | items_1 | 8       | zabbix.h.hostid |   13 | Using where                     | 
+----+-------------+-------+------+-------------------------+---------+---------+-----------------+------+---------------------------------+
2 rows in set (0.00 sec)

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

[den_crane]

Моя база данных весит 3.3 Гб.
Меня удивляет вот что. При выполнении некоторых запросов заббикса mysql просматривает огромную таблицу history_uint, копирует это во временную папку(в моем случае это /var/tmp)

Проблема в том что запросы могут иметь разный план выполнения. Я вообще временных файлов у базы заббикса >25кб не видел. У вас видимо уникальная ситуация, перекос в сторону кол-ва хостов и items.

А размер базы роли не играет 30 гигов или 300, запросы с хорошим планом, будут выполняться за 0 сек, на 500 метрах памяти.

Если тот запрос queue, то есть отображает items у которых время след. опроса < текущего, значит первой должна обрабатываться именно items и по предикату проверяющему просроченность, в вашем случае похоже начинается с hosts из-за ужасного списка. В общем надо смотреть план, а не гадать. Сколько у вас кстати items в очереди обычно?

[mschedrin]

Количество хостов 2860, Количество items: 81918
На мой взгляд не так уж и много. Историю сократил до жесточайшего минимума.
График очереди приложил.
Странно, если zabbix ведет себя так на такой конфигурации, то вряд ли только я с этим столкнулся. Наверное люди как-то решают для себя такие проблемы. Хотелось бы поделиться опытом.
Так же хотелось бы привлечь внимание разработчиков к этой проблеме, если дело действительно в самом zabbix.

У меня всё еще есть сомнения, правильно ли настроен мой mysql, возможно всё-таки дело в нем?

[ugh]

Про это первый раз слышу, как включить?

для группы активировать "Режим отладки"
добавить юзера в группу
сверху справа будет

...Профиль|[b]Отладка[/b]|Выйти из системы...