Очистка разросшейся БД

[fryfuturama]

Здравствуйте! Имеется Zabbix 2.2.5 + Postgres 9.4 + Apache 2 на gentoo x64. Пока был в отпуске база разрослась до немалых размеров - почти 130 GB. Вакуумировать нет места на диске. Встала задача ее почистить.
По одному из мануалов почистил таблицы history, history_uint и trends
Мануал
Оставил последний месяц истории.

После очистки любой запрос SELECT к БД стал вешать процессор на 100%. Будь то график или просто значения элементов посмотреть.
Postgres почти не тюнил, но на старой неочищенной бд размером в 130Гб шевелится все шустро.
В интернетах решение проблемы не нашел.
Заранее спасибо!

Количество узлов сети (под наблюдением/без наблюдения/шаблоны) 91 63 / 1 / 27
Количество элементов данных (активных/деактивированых/не поддерживаются) 5396 4953 / 75 / 368
Количество триггеров (активированных/деактивированных) [проблема/ок] 1125 1063 / 62 [19 / 1044]

[sadman]

https://habrahabr.ru/post/169939/

[fryfuturama]

Я слегка не то написал перед редактированием..
в общем, по мануалу по ссылке было так - создавалась отдельная таблица, в которую уже запросами insert из таблицы history перемещались строки за последний август. Запросов delete не было, только drop table в последствии.

[sadman]

Я слегка не то написал перед редактированием..
в общем, по мануалу по ссылке было так - создавалась отдельная таблица, в которую уже запросами insert из таблицы history перемещались строки за последний август. Запросов delete не было, только drop table в последствии.

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

[fryfuturama]

Попробовал удалить из боевой таблицы запросами типа

DELETE FROM tablename WHERE clock<='epochtime'

записи поудалялись, результат положительный. База после vacuum уменьшилась, все работает быстро и без нареканий.

Выходит если переносить историю в другую таблицу, например, history_new,а потом перименовать ее в history, то zabbix сходит с ума. Предполагаю есть какая привязка к идентификатору таблицы (в sql нуб, не знаю есть такое или нет).

[sadman]

Выходит если переносить историю в другую таблицу, например, history_new,а потом перименовать ее в history, то zabbix сходит с ума. Предполагаю есть какая привязка к идентификатору таблицы (в sql нуб, не знаю есть такое или нет).

https://habrahabr.ru/post/247373/

[DRVTiny]

У нас делается партиционированием и очисткой устаревших партиций (последнее на 3 порядка быстрее DELETE'ов при размерах базы в районе нескольких сот гигабайт).

Если бы Zabbix в серверном коде не пополнял dbcache варварскими методами, запрашивая сначала день, потом неделю, потом месяц (!!), потом вообще всё - проблем с партиционированием бы не было.

А так - да, без патча на код сервера малейшая попытка найти последнее значение метрики в тот момент, когда метрика ещё ни разу не была записана (только что созданная метрика, собственно) - приводит к частичному коллапсу партиционированной базы. Т.е. оно и без партиционирования было бы так, но чуть полегче.

Чудо-кодерам из Zabbix, которые не способны представить данные, собранные по метрике, в виде связного списка - просто гигантский ... респект, в общем.

[yukra]

Чудо-кодерам из Zabbix, которые не способны представить данные, собранные по метрике, в виде связного списка - просто гигантский ... респект, в общем.

Свои патчи можно отправлять сюда например.