низя на проде просто так запустить вакуум фул

ORLY? Давайте Вы честно засечёте время, которое потратите (и уже потратили, кстати — на этот вот cron/VACUUM FULL) на решение этой "проблемы", а потом нам сообщите?

20 минут от начала команды vacuum full analyze;

низя на проде просто так запустить вакуум фул

Потому что он для исключительных ситуаций.

именно

например когда денег на диск нет

и повторюсь еще раз

20 минут от начала команды vacuum full analyze;

Эээ... что? Ваше (оплачиваемое) время, на сервер мне вообще как-то...

когда тейблспейсы ведут себя как боян, то растягиваясь то сжимаясь в ручном режиме, в моей картине мира - это не нормально

моё - 10 минут

когда тейблспейсы ведут себя как боян, то растягиваясь то сжимаясь в ручном режиме, в моей картине мира - это не нормально

Так это же результат Ваших действий, нет? Поэтому, не делайте VACUUM FULL.

простой системы на время вакуума - 20 минут

так я не понел кто тут тролль

если я не буду делать вакуум, то в месяц прирост примерно 30ГБ

за год - 300ГБ

моё - 10 минут

А сейчас нам эта дискуссия снится, да? И Вы и ранее над этой проблемой не думали, вместо того, чтобы заниматься чем-то ещё?

это нормально, вы считаете?

А, я знаю этот типаж.

Извините что трачу ваши деньги... не отвлекайтесь на меня...

это нормально, вы считаете?

Я считаю, что Вы неправильно считаете. Мне кажется, у Вас бы база стабилизировалась в районе ~ 60 ГБ.

нет

она непрерывно растёт

автовакум включи

и если я правильно понял ситуацию, это происходит из за непрерывного удаления/записи

да

он не "дефрагментирует"

именно

не пробовал поискать обычно это спец таблицы с массивным обнволение удалением

пересоздание таблицы "дефрагментирует"

этим ты и занимаешься

она непрерывно растёт

Тогда это интереснее. Почему же Вам помогает VACUUM FULL?

эмм....

он сжимает пустоты

моё - 10 минут

плюс еще минимум час на планирование операции и согласование ее со всеми

он сжимает пустоты

Я знаю, что он делает. Что насчёт моего вопроса? ;)

тогда уточните

я вас не понимаю

Вот что у меня на автовакууме сейчас

autovacuum_analyze_scale_factor: '0.01' autovacuum_max_workers: '5' autovacuum_naptime: '5s' autovacuum_vacuum_cost_delay: '5' autovacuum_vacuum_scale_factor: '0.02' autovacuum_work_mem: '1GB'

диск NVMe, RAM 32GB

CPU - 16

амазан

допустим...

По идее, если у Вас в месяц примерно 30 ГБ добавляется и столько же удаляется (ну, или update), autovacuum должен "вычищать" dead rows, и новые, в норме, попадают в это свободное место.

А Вы говорите, что этого не происходит, вопрос — почему?

он вычищает, но место всёравно отъедается

а, пардон

главное, PgSQL - 9.6

:)

он вычищает, но место всёравно отъедается

Всё равно размер где-то должен стабилизироваться, и вовсе не на 300 ГБ. Вообще, стандартный совет — сделайте autovacuum агрессивнее.

Я вот подозреваю что тут дело в архитектуре

у меня 2 таблицы-бункера

каждая колеблется от 2 до 10ГБ

скейл и косты понизить?

По идее, да. А что анализ bloat по этим таблицам даёт?

не понял вас

у меня 2 таблицы-бункера

А что это значит, конкретно?

длинные и широкие таблицы, в которые идёт интенсивное добавление/изменение данных

20+ столбцов

100+млн записей

не понял вас

Запросы, показывающие bloat таблиц/индексов... их много повсюду валяется. Попробуйте посмотреть на эти таблицы.

длинные и широкие таблицы, в которые идёт интенсивное добавление/изменение данных

Постоянное? Не так чтобы: вставляем-вставляем-вставляем... и иногда много удаляем?

про ритмичность и последовательность не скажу

там разработчики что-то делают

я только статистику по мёртвым кортежам снимаю периодически

ERROR: S client not available

они откатываются

но всёравно хвост вырастает методично

про ритмичность и последовательность не скажу

А это может быть важно. Autovacuum не очень хорошо справляется с insert-only таблицами.

точно не insert only

там и update'ов много

Всем привет, не подскажете, где можно почитать про формирование данных для оконных функций при начитке датасета. Именно с точки зрения архитектуры самого PG

я только статистику по мёртвым кортежам снимаю периодически

Ну так покажите результаты этих запросов... но интересно, конечно, по состоянию, когда Ваш VACUUM FULL был давно, а не только что.

Всем привет, не подскажете, где можно почитать про формирование данных для оконных функций при начитке датасета. Именно с точки зрения архитектуры самого PG

В смысле?

сорян, засветить запрос не могу. чревато последствиями :(

В общем целом понял про агрессивность вакуума , покручу

В смысле?

ну оконки это вроде как однопроходные функции, которые выполняются после выборки датасета. Мне интересно, в какой стуктуре хранятся данные перед выполнением агрегации.

сорян, засветить запрос не могу. чревато последствиями :(

Ну, тем не менее, читайте про настройку autovacuum. Ваша ситуация, на первый взгляд, типичная, т.е. должно помочь.

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

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

Да, можно настраивать потаблично параметры autovacuum.

ну оконки это вроде как однопроходные функции, которые выполняются после выборки датасета. Мне интересно, в какой стуктуре хранятся данные перед выполнением агрегации.

Обычно, ни в какой. Т.е. план строится так, чтобы tuples попадали на вход WindowAgg отсортированными.

спасиб

ну оконки это вроде как однопроходные функции, которые выполняются после выборки датасета. Мне интересно, в какой стуктуре хранятся данные перед выполнением агрегации.

Попробуйте планы посмотреть, например. Там, правда, есть тонкость для каких-то агрегатных функций (ordered-set? hypotetical set? забыл :( ) — они частично сортируют сами.

@maxdukov будет жить. Поприветствуем!

вопрос возник по pgpool - там можно сделать так, чтобы SELECT шли на все узлы - и масте и стендбаи, а INSERT/UPDATE - только на мастера? Если да, то где про это лучше почитать?

@igrnn будет жить. Поприветствуем!

вопрос возник по pgpool - там можно сделать так, чтобы SELECT шли на все узлы - и масте и стендбаи, а INSERT/UPDATE - только на мастера? Если да, то где про это лучше почитать?

там это итак сделано, если в режиме hot-standby будете использовать

опасно. Привет всем, кто-нибудь юзал cube extension? везде написано про ограничение на измерения (100), я правил вручную, боролся, потом попробовал - не вижу никаких ограничений впринципе. В таблицу вставляются кубы любой размерности

там это итак сделано, если в режиме hot-standby будете использовать

так вроде postgre настроил в режим hot-standby, в pgpool backend`ы прописал, включил load_balance_mode = on master_slave_mode = on master_slave_sub_mode = 'stream' а в логах почему-то ошибки: авг 10 12:19:12 loadbalancer pgpool[11407]: 2018-08-10 12:19:12: pid 11407: ERROR: unable to read data from DB node 1 авг 10 12:19:12 loadbalancer pgpool[11407]: 2018-08-10 12:19:12: pid 11407: DETAIL: EOF encountered with backend Как я понимаю, ему что-то не нравится в описании backend для ноды 1?

угу

точнее, он не может что-то прочесть с нее

мой вам совет, не используйте pgpool

ну, от него собираются уходить ?

EDB разработало новый движок zheap с in-place update. Там вакуума нет. Сейчас пытаются его интегрировать с разрабатываемым Pluggable storage API. А так, настраивайте автовакуум и мониторинг через pgstattuple_approx

уже понятно :)

или оптимизировать алгоритм?

Наткнулся тут на тред https://www.postgresql.org/message-id/f49bb262-d246-829d-f835-3950ddac503c%40postgrespro.ru где хотят сделать более гранулированный автовакуум - чистить не по всей таблице и по конкретным страницам. Не знаю, пройдёт ли идея или нет.

да понятно всё в целом

ситуация еще долго не изменится