Очень быстро заканчивается место на серв

[gorodgeroy]

Приветствую, коллеги!
Последние пару недель база стала расти приблизительно на 30гб в неделю. Есть ли возможность узнать что именно наполняет ее такими темпами? (Например, если ли возможность узнать сколько данных генерируют узлы, чтобы найти "виновников")

[Semiadmin]

Для начала посмотрите размер таблиц БД. Сделайте несколько замеров, определите, какая именно таблица быстро растет. Если это айтемы, то какого именно типа (целые, вещественные, текстовые, логи).

[gorodgeroy]

Для начала посмотрите размер таблиц БД. Сделайте несколько замеров, определите, какая именно таблица быстро растет. Если это айтемы, то какого именно типа (целые, вещественные, текстовые, логи).

history_uint и trends_uint выросли за 13 часов на 2Gb каждая. Остальные таблицы растут скромнее.

[Semiadmin]

history_uint и trends_uint выросли за 13 часов на 2gb каждая. Остальные таблицы растут скромнее.

Значит, айтемы с типом "целое положительное". Непонятен синхронный рост истории и трендов.

[gorodgeroy]

Значит, айтемы с типом "целое положительное". Непонятен синхронный рост истории и трендов.

А можно как-то посмотреть какие узлы генерируют данные? "Тяжелые" шаблоны я удалил, проверил что от них не осталось элементов данных. Узлов больше 2000, очень трудно понять откуда идут данные.

[yukra]

А можно как-то посмотреть какие узлы генерируют данные? "Тяжелые" шаблоны я удалил, проверил что от них не осталось элементов данных. Узлов больше 2000, очень трудно понять откуда идут данные.

1) я не уверен что удаление айтемов в заббиксе вызовет удаление истории, операция относительно тяжелая и разумнее чистить историю штатным образом
2) Если у вас mysql, то вероятнее всего таблицы в innodb, которая сама по себе место не освобождает.

Что бы освободить место в innodb я делаю "ALTER TABLE history_uint ENGINE='InnoDB';". Выполняется долго, требует места примерно столько же, сколько занимает таблица, но на моей перконе 5.6 не блокирует работу заббикса(как поведет себя на нативном мускуле - без понятия).

По поводу того, чем занята таблица:
Запрос типа "select itemid, COUNT(clock) C FROM history_uint GROUP BY itemid ORDER BY C;" - первая колонка номер айтема, вторая - колво строк истории для этого айтема(в 3.2 этот запрос выполняется по индексу, полное сканирование таблицы не требуется)
Запрос вида "SELECT * FROM items WHERE itemid = 70692\G" - понять что это за айтем по itemid. Там найдете hostid и можно сделать что-то типа "SELECT * FROM hosts WHERE hostid = 10331\G" что бы понять на каком хосте живет айтем.

То, что в таблицы пишуться новые данные - это нормально, собственно они для этого и придуманы. Вопрос не в том, что бы сократить колво записей в таблицу, а в том, что бы вовремя убирать более неактуальные данные из таблиц. Хорошей практикой считается короткий период хранения истории, и выкидывание остального в тренды. Для этого есть 2 механизма: Housekeeper и партиционирование БД, что из этого использовать - решать вам, но раз вы задаете такие вопросы, то, кмк при настройке партицирование есть ненулевой шанс все сломать.

Зы уточните что у вас за диски, имеется ли рейд и какие на данный момент размеры таблиц истории?

[gorodgeroy]

1) я не уверен что удаление айтемов в заббиксе вызовет удаление истории, операция относительно тяжелая и разумнее чистить историю штатным образом
2) Если у вас mysql, то вероятнее всего таблицы в innodb, которая сама по себе место не освобождает.

Что бы освободить место в innodb я делаю "ALTER TABLE history_uint ENGINE='InnoDB';". Выполняется долго, требует места примерно столько же, сколько занимает таблица, но на моей перконе 5.6 не блокирует работу заббикса(как поведет себя на нативном мускуле - без понятия).

По поводу того, чем занята таблица:
Запрос типа "select itemid, COUNT(clock) C FROM history_uint GROUP BY itemid ORDER BY C;" - первая колонка номер айтема, вторая - колво строк истории для этого айтема(в 3.2 этот запрос выполняется по индексу, полное сканирование таблицы не требуется)
Запрос вида "SELECT * FROM items WHERE itemid = 70692\G" - понять что это за айтем по itemid. Там найдете hostid и можно сделать что-то типа "SELECT * FROM hosts WHERE hostid = 10331\G" что бы понять на каком хосте живет айтем.

То, что в таблицы пишуться новые данные - это нормально, собственно они для этого и придуманы. Вопрос не в том, что бы сократить колво записей в таблицу, а в том, что бы вовремя убирать более неактуальные данные из таблиц. Хорошей практикой считается короткий период хранения истории, и выкидывание остального в тренды. Для этого есть 2 механизма: Housekeeper и партиционирование БД, что из этого использовать - решать вам, но раз вы задаете такие вопросы, то, кмк при настройке партицирование есть ненулевой шанс все сломать.

Зы уточните что у вас за диски, имеется ли рейд и какие на данный момент размеры таблиц истории?

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

history_uint 84Gb(растёт на 112Mb\час)
history_text 45Gb(растет на 16Mb\час)
trends_uint 13Gb(после оптимизации за одну ночь подросла на 2 гб, теперь практически не растет)
trends 4.5Gb (не растет)

За сутки набегает около 3гб, проблема появилась недавно (последние 2-3 недели). При этом массовых добавлений узлов не было, разве что был добавлен зверский шаблон Cisco (>500 элементов данных), но он позавчера отключен. Также увеличен интервал проверок по многим элементам данных до минимум 1 минуты (с 10-30 секунд) - количество записываемых данных не изменилось.

Вот сводные данные по состоянию сервера заббикса:

Количество узлов сети (активированных/деактивированных/шаблонов) 2260 2145 / 19 / 96
Количество элементов данных (активированных/деактивированных/неподдерживаемых) 45260 43040 / 579 / 1641
Количество триггеров (активированных/деактивированных [проблема/ок]) 11523 11506 / 17 [1093 / 10413]
Количество пользователей (в сети) 21 6
Требуемое быстродействие сервера, новые значения в секунду 714.19

[Semiadmin]

А база - MySQL c innodb? После всех этих изменений рост базы замедлился?
Просто надо иметь ввиду, что размер файла ibdata1 сам по себе не уменьшится, без дампа/раздампа базы.
Но можно увеличить количество "воздуха" в ibdata1. После удаления данных через интерфейс заббикса, очисткой БД занимается housekeeper.
Можно увеличить его эффективность, увеличив количество данных, которые физически удаляются за 1 проход хаускипера, или частоту проходов, но осторожно, чтобы не сильно пострадала производительность сервера.
Оценить освободившееся место можно, сравнив размер ibdata1 с результатом запроса
SELECT table_schema, Sum(data_length + index_length) FROM information_schema.tables;

[gorodgeroy]

А база - MySQL c innodb? После всех этих изменений рост базы замедлился?
Просто надо иметь ввиду, что размер файла ibdata1 сам по себе не уменьшится, без дампа/раздампа базы.
Но можно увеличить количество "воздуха" в ibdata1. После удаления данных через интерфейс заббикса, очисткой БД занимается housekeeper.
Можно увеличить его эффективность, увеличив количество данных, которые физически удаляются за 1 проход хаускипера, или частоту проходов, но осторожно, чтобы не сильно пострадала производительность сервера.
Оценить освободившееся место можно, сравнив размер ibdata1 с результатом запроса
SELECT table_schema, Sum(data_length + index_length) FROM information_schema.tables;

База mysql InnoDB, с разделением на отдельные файлы для таблиц. Оптимизацию самых толстых таблиц делали в прошлый четверг, но проблема-то не в размере базы как таковом, а в её чрезвычайно быстром наполнении - и пока не получается понять, отчего увеличился объем записываемых данных.