|
Обслуживание postgresql
| ☑ |
0
bolero
22.06.20
✎
11:09
|
У меня выключен автовакуум, вместо этого по ночам раз в сутки гоняется VACUUM; ANALYZE;
За день базы не успевают критично распухать, народу немного.
VACUUM FULL не применяю, т.к. результат практически одинаков с обычным VACUUM, зато огромная нагрузка на саму базу и сеть при синхронизации на реплику.
Однако же пошел искать, куда место делось, топ-1 стоит pg_catalog.pg_attribute.
Выяснилось, что там постгрес хранит данные о всех таблицах, в т.ч. временных, а 1с временные таблицы использует (создает и удаляет) ну очень много.
Обычный vacuum почему-то не уменьшает размер конкретно этой таблицы.
Добавил к еженощным процедурам:
VACUUM FULL pg_catalog.pg_attribute;
FULL для примера сократил с 29GB до 111MB, вся база была 85GB, стала 55GB
Какие еще полезные процедуры знаете?
|
|
1
Волшебник
модератор
22.06.20
✎
11:10
|
DROP DATABASE тоже может сильно уменьшить размер базы
(шутка)
|
|
2
МихаилМ
22.06.20
✎
11:20
|
зачем уменьшать размер таблицы, если он она опять вырастет. но коли обрезали - соберите статистику роста.
|
|
3
fisher
22.06.20
✎
11:26
|
Обычно автовакуум все же не отключают, а настраивают его параметры под свой профиль нагрузки. Это более эффективно.
А вот борьба с bloat:
|
|
4
fisher
22.06.20
✎
11:28
|
При настроенном автовакууме, кстати, bloat гораздо меньше.
|
|
5
fisher
22.06.20
✎
11:35
|
В статье описывается работа с pg_repack, но мне больше понравилась идея pg_compact и типа него. Там просто последние записи переносятся в пустые места, чтобы пустое место образовалось в конце и тогда его легко срежет обычный вакуум (без лишних локов и резких телодвижений). Я давно уже с постгри не работаю, да и когда работал - не сказать что глубоко разбирался. Может, что более интересное есть на текущий момент.
|
|
6
fisher
22.06.20
✎
11:42
|
Вообще, плотнее всего с 1С на постгри в суровом продакшене вроде работал Лустин и его команда из silverbulleters.
У них было много наработок по обслуживанию и повышению производительности. Можно попробовать поискать доступные материалы.
|
|
7
bolero
22.06.20
✎
17:46
|
(2) > зачем уменьшать размер таблицы, если он она опять вырастет
в пухлую таблицу вставлять новые записи в целом дороже, чем в худенькую, а вставляются они туда при каждом открытии документа, подборе в поле ввода и т.п.
(2) > коли обрезали - соберите статистику роста
за 6 часов размер вырос с 111 MB до 227 MB, при этом в базе работают три калеки
(3) > настраивают его параметры под свой профиль нагрузки
полностью согласен. у меня профиль нагрузки - три калеки, оптимальный профиль - выкл и по крону раз в день
(5) все это здорово, но я думаю такими вещами стоит заморачиваться, когда приложение предсказуемо и пользуется базой как базой, а не второй оперативной памятью
ну т.е. какбе для 1с это не очень актуально, штатный autovacuum средненько, но справится
|
|
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший