Чистка myaql, притормаживает в процессе работ&

[step_slim]

Доброго времени суток.
Пришлось поднимать заново этот вопрос, уж извините.
Ну сбился уже с ног..., опять та же проблема- добавил все ХОСТЫ и всё, опять жуткие тормоза при загрузки страницы zabbix. Отчёты не посмотреть, всё жутко зависает. И графики перестали отображаться. Перепробовал всё, что предлагалось выше. После недели работы, подобное наблюдалось, но из ХОСТОВ были только Cisco, сделал

optimize table history;

Всё опять заработало, возрадовался. Добавил все остальные ХОСТЫ (принтеры), прихожу после 3х дневных выходных. WEB морда zabbix`а не грузится, а если и загружается, спустя минут 20, то графики показывают что нет данных... Иными словами всё заново
Запускаю оптимизацию:

2 rows in set (1 hour 57 min 39.02 sec)

Но ничего не изменилось, второй раз не прокатило.. Так же всё тормозит. Смотрю размер базы 1,5 ГБ, 500 мегабайт за 3 дня!!!!
Господа, что делать? Такими темпами, мне не то что время ожидания ответа от базы не дождаться, мне места на жёстком не хватит, а пересоздавать базу каждую неделю, но это согласитесь не выход...

[dima_dm]

А почему Вы оптимизируете только таблицу history, а не все таблицы?
Настраивайте интервалы опросов и время хранения истории и трендов.
Оценка размера базы:
http://www.zabbix.com/documentation/...n/requirements -> 2.6. Размер базы данных

[step_slim]

А почему Вы оптимизируете только таблицу history, а не все таблицы?

Потому как в примерах выше, было только про оптимизацию таблицы history. Вот только её и оптимизировал. А как выбрать полную оптимизацию? Посмотрел по форумам, многие предлагают делать:

mysql > RESET MASTER;

Выполнил, ничего не изменилось.

Настраивайте интервалы опросов

Уже пробовал, особой разницы пока не вижу...

время хранения истории и трендов.

Вот с этим не разобрался, это где?

Касательно мануала, цитирую:

Базе данных Zabbix, в зависимости от типа базы данных, требуется около 128 байт на один элемент. Предположим, что если требуется хранить тенденции в течении 5 лет. Значения 3000 элементов данных потребуют (3000/3600)*(24*3600*365)* 128 = 6.3GB за год, или 31.5GB за 5 лет. Первое значение в формуле 3600 представляет собой период усреднения тенденций в один час.

3 дня +70 Хостов и у меня менее чем 3000 элементов проверки = 500 метров, в примере за ГОД 6.3 ГБ

[dima_dm]

Потому как в примерах выше, было только про оптимизацию таблицы history. Вот только её и оптимизировал. А как выбрать полную оптимизацию?

Точно так же и остальные таблицы
optimize table history_uint;
optimize table trends_uint;
и т.д.

Посмотрел по форумам, многие предлагают делать:
mysql > RESET MASTER;

Это вообще из другой оперы, речь про replication. Вы бы документацию почитали, какие команды вводите, и что они делают.

время хранения истории и трендов.
Вот с этим не разобрался, это где?

В настройках Item.
Хранить историю (дни) - абсолютные значения
Хранить динамику изменений (дни)
http://www.zabbix.com/documentation/...n/requirements
Zabbix хранит ежечасную статистику max/min/avg/count для каждого элемента в таблице trends и trends_uint. Эти данные используются для отслеживания тенденций и для графиков при отображении длительного времени.

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

[step_slim]

Почистил таблицу history_uint, именно она занимал большую часть, точнее 1.2Гига. Сделал оптимизацию всех таблиц- стало немного лучше.

В настройках Item.
Хранить историю (дни) - абсолютные значения
Хранить динамику изменений (дни)

А нет ли возможности изменить эту настройку масштабно? Менять 755 Item на каждый ХОСТ, это же кошмар.

[sersad]

а шаблоны собственно для чего?

[prostrelov]

Хранить History: 90 дней
Хранить Trends: 365 дней
New values per second: 135
Hosts: 77
Items: 22150
вес history части базы при периоде в 90 дней: 53 ГБ
вес trends части базы в 1 год: 24 ГБ
вес events части базы в 1 год: 4 ГБ
-------------------------------------------------------------------
81 ГБ.

За 2 месяца база выросла до 30 ГБ.

01. В даннй момент уже есть проблемы с Disk I/O is overloaded on Zabbix server.
02. Есть ли смысл уходить с mysql на postgres без применения сегментирования

[Heilig]

prostrelov, я понимаю, что это не ответ на Ваш вопрос, но все же...
Может Вам стоить уменьшить период для History (например до 30 дней) у большинства элементов данных, а 90 оставить для действительно важных? Думаю, что для "стандартных" метрик (cpu, memory, disk utilization, etc) не нужен такой длительный период хранения истории.

[prostrelov]

Да, это в планах. Но проблемы это не решит. В данный момент смотрим в сторону postgres и партишанинга. Но хотелось бы услышать ответы на вопросы от тех кто уже сталкивался с подводными камнями такой реализации БД.

[dima_dm]

06. /var/lib/mysql/zabbix содержит только *.frm файлы. *ibd нет.
mysql> SHOW CREATE TABLE history;
ENGINE=InnoDB
cat /etc/my.cnf
innodb_file_per_table=1
Сам забикс крутиться под Hyper-V из vmx образа с оф сайта

Каждая таблица в отдельном файле. (работает при создании новой таблицы).
Читайте

https://www.zabbix.com/forum/showthread.php?t=19215

Там и про то, как MySQL оптимизировать написано.

[prostrelov]

Спасибо. Помимо прочего буквально минут 10 назад наткнулся на инструкции с вики по секционированию.
Сразу ряд вопросов был снят.
Пока остался только след. вопрос: чем чревато удаление foreign key и primary key.

[Jimson]

Спасибо. Помимо прочего буквально минут 10 назад наткнулся на инструкции с вики по секционированию.
Сразу ряд вопросов был снят.
Пока остался только след. вопрос: чем чревато удаление foreign key и primary key.

А тебе действительно важно партиционировать всякие сервисные таблицы?
У history и trends нет PK и удалять индексы не нужно. А что бы кипер не пытался чистить эти таблицы от старых данных просто всем итемам даем 3000 дней хранения истории и trends.

Мысли в слух, мне тоже предстоит партиционировать, думаю ограничится только числовыми history и trends.

[prostrelov]

Дело в том что изначально zabbix был с позиционирован мне
начальством как виртуальный сервер и отвести под него отдельную
физическую машину у меня возможности пока нет. Виртуальная
машина крутится под Hyper-V и спустя 2 месяца со старта БД весит 41
ГБ. По рассчётным формулам к концу года база будет весить 81 ГБ. Я
опасаюсь что работать на виртуальном сервере такая база
нормально не сможет. К тому же архивировать такую базу
достаточно проблематично.

Соответственно мне требуется выбрать решение в рамках виртуальной машины
которое снимет нагрузку на IO (уйти от запуска housekeeper'a каждый час) и
позволит контролировать размер базы просто перемещая по
расписанию сегментированные части этой базы.

В данный момент я не представляю к каким последствиям может
привести удаление foreign key. Как я понял удаляя эти ключи мы
частично удаляем контроль уникальности значений между таблицами.
Или я не так понял ?

[Jimson]

Как я понял удаляя эти ключи мы
частично удаляем контроль уникальности значений между таблицами.

Ну так не удаляй, партиционируй только history/trends, у них нет праймари ключей. Чем этот вариант плох?

[prostrelov]

Дело в том что основные вЕсящие таблицы у меня :
history_uint _ 22ГБ
history_log _ 6ГБ
trends_uint _ 2ГБ

а в них есть foreign key и primary key.