как выяснилось, ситуация не поменялась. Рою дальше. В процессе рытья (временно?) смог снизить нагрузку на базу при рестарте https://www.zabbix.com/forum/showthr...677#post150677
-
-
вешает его процесс "timer": сегодня, проработав всю ночь и вчерашний вечер без сбоев, в 10:00 он внезапно начал есть 100% времени и в этот момент появился процесс history_syncer 100% CPU и сервер подвесился. Лог пустой, в смысле последняя запись в 6:41
Картинка загрузки внутренних процессов заббикса такова: https://dl.dropboxusercontent.com/u/...6_10h14_36.png
(мой лимит на вложения внутри форума исчерпан)Comment
-
А зачем вы используете housekeeper? Почему не партиционировать таблицы и не отключить его совсем?
Т.е. понятно что вы ходите по каким то багам и эти баги крайне желательно отловить и зарепортить, но с другой стороны почти наверняка можно обойти эти баги, да и при вашем кол-ве элементов данных партиционирование крайне желательно.Comment
-
Сейчас я не упираюсь в БД, поэтому активно секционирование не рассматриваю. А вот подвешивание заббикса для меня критично, дежурные пропускают сбои в инфраструктуре.
housekeeper я включил вчера, глядя на отсутствие загрузки в базе. У меня плавно с момента апгрейда вырос размер full backup из-за того, что апгрейд молчком выключил удаление старых данных. Правда за 18 часов удалилось всего 100 мегабайт. Секционирование, насколько я понимаю, не удаляет данные квантами меньше месяца, также непонятно получится ли пользоваться секционированием если база на innodb, т.к. ужасно не хочется связываться с конвертацией в myisam.Comment
-
1. когда вы создавали тему у вас были подвисания при выключенном housekeeper? тогда вопрос снимается
2. всего 100 мегабайт потому что одна итерация housekeeper удаляет из базы не более N строк, где N задается в конфигурации сервера
3. нет не правильно, вы удаляете секциями, а чему равна секция решаете только вы описывая партиционирование таблицы, для каждой свой интервал можете задать, например, history по неделям, а history_uint посуточную
4. можно с innodb, вы переключитесь в режим отдельное innodb хранилище для каждой таблицы
P.S. housekeeper выключили как раз потому что удалять данные из таблиц крайне неэффективно и имеет смысл только для маленьких инсталяций, а еще потому что теперь можно запускать housekeeper отдельно для history, trends, events, etc.Comment
-
Продолжаю ковыряние...
По совету из https://www.zabbix.com/forum/showthread.php?p=150784 поставил StartTimers=10. Сервис пережил 2,5 суток без падений, но после опять ушёл в себя как и ранее. Процесс Timer не виноват и за 2,5 суток выше 20% в паре единовременных пиков не подымался. Все процессы кроме housekeeper не нагружены.
внутренние процессы: https://dl.dropboxusercontent.com/u/...9_15h38_11.png
процессы сбора данных: https://dl.dropboxusercontent.com/u/...9_15h45_12.png
В логах (DebugLevel=4) во время сбоя ничего критичного не наблюдаю, процесс history syncer просто ест 100% времени и блочит весь сервер, триггеры не обрабатываются, данные не собираются:
Comment
-
А не может ли проблема с зависанием быть следствием общей проблемы с производительностью? Уж очень долго у Вас работает housekeeper по-моему. Он вообще успевает завершиться до того, как придет время запускать следующий процесс?
Может попробовать пожить без housekeeper'а какое-то время?Comment
-
Проблемы были существенно задолго до запуска housekeeper несколько дней назад, он при апгрейде был выключен разработчиками. Я его недавно включил и он ни на что не повлиял, даже места толком освободить не смог. Отрубил ещё раз. База не перегружена ни по IOPS (есть десятикратный запас от устоявшегося потребления), ни по mbps, ни по процам, ни по памяти (скормлено 8G RAM, mysql_tuning_primer показывает благолепие)Comment
-
очередной сбой случился в 17:25 но я был во всеоружии.
мне удалось отловить детальный вывод (Debuglevel=4) подвисшего процесса: https://dl.dropboxusercontent.com/u/...d15413.log.bz2
его последним действием был корректно работающий в MYSQL запрос на тему ИТ-сервисов: https://dl.dropboxusercontent.com/u/...last_query.txt
Итого процесс иногда спотыкается на вот таком наборе данных (mysqldump -u zabbix -p zabbix services services_links services_times service_alarms >services.sql): https://dl.dropboxusercontent.com/u/...rvices.sql.bz2
Все проблемы начались после того, как была добавлена разветвлённая сеть ИТ-сервисов, демонстрирующая подключение точек к провайдерам для региона, т.е. сделано развесистое дерево. Придётся удалить кропотливо добавленное, иначе жить очень трудно
Comment
-
удаление данных помогло, 4 дня без зависаний. Самое обидное что zabbix-team имел решение проблемы ещё 9 мая
Я уже не в первый раз за историю публичного заббикса в разных инсталляциях напарываюсь на подобное и прошлые разы в итоге уводили меня от заббикса в другие системы. Никто в OSS никому ничего не должен, но практика выпуска стоп-сервис-багфиксов по мере их обнаружения и устранения это нормально во всех известных мне OSS продуктах кроме заббикса и это расстраивает. Change-log для 2.2.4 rc http://www.zabbix.com/rn2.2.4rc2.php прямо пестрит подобным.Comment
-
Вот поэтому я и не перехожу на ветку 2.2. Глюкавая она пока, судя по проблемам, возникающим у тех, кто уже перешел.
А разработчиков несет уже дальше, в версию 2.4....Comment
-
это баг всех версий, включая прошлые, судя по описанию.
Разработчики исторически всё фиксят в транке SVN, но держать продуктивы на developer-версиях это вообще за гранью разумного так как там всё вообще из веточек и обрывков верёвочек, я на одной инсталляции лет 6 назад пытался так жить, больше месяца меня не хватило, ушёл на нагиос...
Сейчас год продержался, радуясь стабильности, но последний месяц внезапно выпил литры крови.Comment
-
На сколько я помню для каждого ZBX/ZBXNEXT попавшего в работу заводится отдельная "ветка" в svn (бранч или как их там), можно в пару кликов выкачать изменения в виде патча.
Живу на FreeBSD на стабильных версиях забикса, свой "порт" с кучей барахла в files/.
P.S. но на 2.2 тоже еще не перешел
каждая новая тема про 2.2 напрягает.
Comment
Comment