Большой размер базы

[volgd_admins]

С переходом мониторинга с Zabbix 2.0 на 2.4 и переводом БД с PosgtreSQL 9.2 на 9.4 стала непомерно расти база: если до перехода она была ~12 Гб (а при переходе уменьшилась до 6-7 (подозреваю, что какие-то данные очистились - прошло как раз 2 года с момента внедрения)), то сейчас выросла до ~31Гб, хотя ничего принципиально нового туда не добавлено. Сегодня делал

vacuumdb --all --full --analyze --verbose

и база уменьшилась с 33 до 31Гб.
Система: FreeBSD 10.1 amd64, СУБД PostgreSQL 9.4. Переносил БД через бэкап.
Может так и должно быть? Но меня настораживает, учитывая мои не очень глубокие знания PostgreSQL.
Поэтому прошу помочь разобраться: проблема это или нет. И если ответ "да", то помочь решить.

[Webman]

Была аналогичная проблема. При ~400 новых значениях в секунду, база разрослась до ~40 гигабайт меньше чем за неделю, плюс проблемы с высоким I/O, как следствие - почти нулевая отзывчивость веб-интерфейса и большие очереди. Очистили таблицы с данными, сделали вакуум, получили уменьшение БД до ~28 Гб (хотя, честно говоря, ожидался существенно меньший размер, видимо удалили не всё, что нужно). После, сделали партицирование как описано тут - https://www.zabbix.org/wiki/Docs/how...topartitioning. БД растёт примерно на гигабайт в день, 504 узла, 132536 элементов данных, требуемое быстродействие 282.8 новых значений в секунду.

[volgd_admins]

Была аналогичная проблема. При ~400 новых значениях в секунду, база разрослась до ~40 гигабайт меньше чем за неделю, плюс проблемы с высоким i/o, как следствие - почти нулевая отзывчивость веб-интерфейса и большие очереди. Очистили таблицы с данными, сделали вакуум, получили уменьшение БД до ~28 Гб (хотя, честно говоря, ожидался существенно меньший размер, видимо удалили не всё, что нужно). После, сделали партицирование как описано тут - https://www.zabbix.org/wiki/docs/how...topartitioning. БД растёт примерно на гигабайт в день, 504 узла, 132536 элементов данных, требуемое быстродействие 282.8 новых значений в секунду.

У нас куда меньше: 110 узлов, 3761 параметров, 1414 триггеров. Циски есть, но я отключил контроль всех портов (оставил только транковые). Да и, повторюсь: на 2.0 было всё тоже, но с куда меньшей базой.
Может что-то в структуре БД поменялось или в параметрах (глубина хранения некоторых данных, например). Сейчас (после выходных) опять 33Гб. Если архив дампа до переноса был ~600-700 Мб, то сейчас почти 2,4 Гб.

Очистили таблицы с данными

А что под этим подразумевается? Я думал, что всеми чистками занимается сам Заббикс в соотв. в настройками для каждого контролируемого параметра (глубина хранения и/или что-то ещё).

[yukra]

А что под этим подразумевается? Я думал, что всеми чистками занимается сам Заббикс в соотв. в настройками для каждого контролируемого параметра (глубина хранения и/или что-то ещё).

никто не мешает вам самостоятельно удалить все из history_* и trends_* таблиц и если удалять "только оттуда", то ничего сломаться не должно.

[volgd_admins]

никто не мешает вам самостоятельно удалить все из history_* и trends_* таблиц и если удалять "только оттуда", то ничего сломаться не должно.

Согласен, это сделать можно, но, по моему, это не лучший вариант: зачем удалять данные (которые система хранит в соотв. с настройками) обходными путями? Тогда уж надо менять настройки хранения для параметров. Но тогда надо понять, какие параметры так себя ведут, чтобы делать контролируемо.

[yukra]

я честно говоря PosgtreSQL не умею, от слова совсем, но может быть проблема не в заббиксе, а в PosgtreSQL? типа изменились какие то внутренние структуры внутри БД и теперь они занимают больше места?

Вы можете попробовать посчитать сколько у вас весят конкретные таблицы и попытаться найти куда именно тратиться место.

[sadman]

постгрес страдает от table bloat. Тут уже была тема с "лечением" через периодическое сжимание (не через vacuum!)

[volgd_admins]

постгрес страдает от table bloat. Тут уже была тема с "лечением" через периодическое сжимание (не через vacuum!)

А подробней можно?
И интересно: почему в 9.2 таких проблем не было? Может vacuum теперь по другому работает?

P.S. Нашёл подходящую тему, но тут пишется про VACUUM FULL, а я и делаю "vacuumdb --all --full --analyze --verbose". Или вы про что-то иное?

[sadman]

https://wiki.postgresql.org/wiki/VACUUM_FULL

Насколько я понял - vacuum full имеет смысл при переодическом простом вакуумировании, а без него это все равно, что мертвому припарка. Я c 9.2 на 9.4 не переходил, статистики не имею. Vacuum full базу мне сильно не жал, но помогла утилитка pgcompactor: http://m.habrahabr.ru/post/169939/

[volgd_admins]

Вчера сделал бэкап-ресторе а новую базу: тектовый файл дампа занял чуть менее 19 Гб, но после восстановления из него БД стала всё те же 43 Гб.
Т.е. это, получается, реальный разме базы, только почему так - непонятно.

P.S. Поучается, что смысла в использовании pgcompactor нет.

[sadman]

Получается, что в вашем случае смысла нет. Я периодически жму и мне pgcompactor помогает.

А понять "почему", наверняка сможете, если поставите и запустите параллельно работать два инстанса заббикс-сервера с разными версиями postgres. Таблицы посравниваете, то-се.

[molody]

Вчера сделал бэкап-ресторе а новую базу: тектовый файл дампа занял чуть менее 19 Гб, но после восстановления из него БД стала всё те же 43 Гб.
Т.е. это, получается, реальный разме базы, только почему так - непонятно.

p.s. Поучается, что смысла в использовании pgcompactor нет.

Вы наверное забываете что база кроме саммих данных хранит и множество индексов с разными параметрами, из-за этого разница в объемах тестового фалй и данных Базы