powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Много update
13 сообщений из 13, страница 1 из 1
Много update
    #39603329
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет.
Имеется БД ~200GB с одной основной таблицей около 110ГБ , с интенсивным инсертом + апдейтом (суммарно около 2-3 млн модификаций в сутки)
ВНЕЗАПНО :) начал тормозить процесс update (конструкция вида UPDATE t SET status='z' WHERE id in (SELECT id FROM t where status = 'x' and cond1=false and cond2=1 FOR UPDATE)

Первым делом сделали vacuum+analyze на таблицу. Значения автовакума cost_limit , cost_delay выставил более агрессивным. Таблица начала практически непрерывно вакумиться.

Подзапрос из SELECT идет по индексу (partial), но делает очень большое кол-во чтений (в т.ч физического). При том что индекс занимает 300МБ, чтений делается на 2-3ГБ (реальная выборка несколько сотен строк). При пересоздании индекса (после пересоздания занимает 5 МБ), кол-во чтений резко падает все работает быстро.
1. Я правильно понимаю, что индекс пухнет из за неполного удаления вакумом из него строк?
2. Даже если индекс распухший, но 99% его это пустые и или почти пустые страницы, откуда так много чтений?
3. Почему апдейт в индекс не добавляет строки на свободные страницы, уменьшая распухание индекса?

PostgreSQL 9.5, RedHat
...
Рейтинг: 0 / 0
Много update
    #39603345
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21,

1. Пухнет в первую очередь таблица, а т.к. в индексе нет “видимости”, то на каждую запись в таблице в индексе создаются новые листочки. Возможно вам следует также повысить `autovacuum_max_workers` (это требует рестарта).
2. По 2 причинам: (1) данные с диска читаются постранично, и если листочки в индексе сильно фрагментированы, то для N обращений к индексу потребуется больше страничек с диска поднять и обработать; (2) индекс имеет структуру и даже если вакуум подчищает его, то физический формат страниц он не меняет, т.к. это слишком нетривиально, ибо дерево.
3. Добавляет, если вставляемое значение должно быть на такой странице в индексе и там есть место. Но если значения приходят такие, что их надо в основном добавлять в один конец дерева (возрастающая последовательность), то приходиться их размещать в новых страницах, оставляя старые нетронутыми.

Проблема известная и давняя.
...
Рейтинг: 0 / 0
Много update
    #39603356
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21Привет.
Имеется БД ~200GB с одной основной таблицей около 110ГБ , с интенсивным инсертом + апдейтом (суммарно около 2-3 млн модификаций в сутки)
ВНЕЗАПНО :) начал тормозить процесс update (конструкция вида UPDATE t SET status='z' WHERE id in (SELECT id FROM t where status = 'x' and cond1=false and cond2=1 FOR UPDATE)

Первым делом сделали vacuum+analyze на таблицу. Значения автовакума cost_limit , cost_delay выставил более агрессивным. Таблица начала практически непрерывно вакумиться.

Подзапрос из SELECT идет по индексу (partial), но делает очень большое кол-во чтений (в т.ч физического). При том что индекс занимает 300МБ, чтений делается на 2-3ГБ (реальная выборка несколько сотен строк). При пересоздании индекса (после пересоздания занимает 5 МБ), кол-во чтений резко падает все работает быстро.
1. Я правильно понимаю, что индекс пухнет из за неполного удаления вакумом из него строк?
2. Даже если индекс распухший, но 99% его это пустые и или почти пустые страницы, откуда так много чтений?
3. Почему апдейт в индекс не добавляет строки на свободные страницы, уменьшая распухание индекса?

PostgreSQL 9.5, RedHat

индекс -- дерево. куда вставляться определяется значением, а не пустотой.
а неприятность в том, что индекс не знает, что он смотрит на уже мертвую запись, если узел не почикан.
т.е. автовакуум надо как можно злее делать.

как и идет ли ребалансинг дерева при вакууме -- не знаю, но и чтения мертвяков вполне достаточно. (кто--то писал,что подбор окончательных мертвяков в инд-се при вот таком боевом чтении и происходит)

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

проблема может возбуждаться наличием длинных транзакций -- растягивающих псевдо--"андо" т.е. жизнь зомби записей и не дающих их отвакуумить. начать с отстрела висяков.(т.е. конкурентно висеть в создании альтернативы вредно по определению)

когда-то замечал большие проблемы с инд-сами на тостах (после очистки тостов индексы висели многомеговые на !пустых тостах)
...
Рейтинг: 0 / 0
Много update
    #39603358
qwwq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
qwwq,

ещё -- если активных записей -- на 5-меговый индекс -- нет ли возможности вытащить их все в отдельную партицию? типа ротацию забубенить.
...
Рейтинг: 0 / 0
Много update
    #39603409
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спасибо за ответы!
Я провел эксперимент - создал таблицу, индекс на нее. Вставил 1млн. строк.
Отключил на нее вакум.
SELECT по индексу (Index Scan) cache hit read = 9
Модифицировал 1млн, первый SELECT читает по индексу (Index Scan) cache hit read = 350, следующий уже cache hit read =11
И так далее, после каждого апдейта, всегда первый селект читал на порядок больше.

В общем это еще раз убеждает меня делать автовакума больше и злее :)
Неясным остался момент, какой приемлемый для меня процент "мертвых" строк можно оставить для этой таблицы (scale_factor)?
Сейчас установлено 8%, но видимо этого недостаточно.
...
Рейтинг: 0 / 0
Много update
    #39604576
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Спустя неделю наблюдений обратил внимание, что почти при непрерывной работе вакума над большой таблицей - кол-во мертвых строк в ней растет!
Так же вспомнили, что проблемы начались одновременно с добавлением новой реплики в каскадной конфигурации.
Отключил везде hot_standby_feedback, и ЦПУ на мастере упало в 3 раза, и таблица наконец очистилась!
Теперь грешу на глюк hot_standby_feedback при добавлении реплики, т.к. на самих репликах долгих запросов не было.
...
Рейтинг: 0 / 0
Много update
    #39604627
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21Спустя неделю наблюдений обратил внимание, что почти при непрерывной работе вакума над большой таблицей - кол-во мертвых строк в ней растет!
Так же вспомнили, что проблемы начались одновременно с добавлением новой реплики в каскадной конфигурации.
Отключил везде hot_standby_feedback, и ЦПУ на мастере упало в 3 раза, и таблица наконец очистилась!
Теперь грешу на глюк hot_standby_feedback при добавлении реплики, т.к. на самих репликах долгих запросов не было.

Были (или как вариант - какая то из реплик отставала на заметное время - а это при hot standby feedback эквивалентно тому что все это время открытая транзакция висела на этой реплике)
...
Рейтинг: 0 / 0
Много update
    #39605483
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Чем отличаются поля pg_replication_slots.xmin от pg_stat_replication.backend_xmin?

В документации написано что "pg_stat_replication.backend_xmin" -значение xmin, полученное от резервного сервера при включённом hot_standby_feedback

pg_replication_slots.xmin - Старейшая транзакция, которая должна сохраняться в базе данных для этого слота. VACUUM не сможет удалять кортежи, удалённые более поздними транзакциями.

В контексте hot_standby_feedback разве эти поля не должны показывать одно и тоже?

При транзакции на реплике, значение "select age(xmin) from pg_replication_slots" на мастере постоянно растет (я интерпретирую это как кол-во транзакций которое прошло с транзакции xmin), однако pg_stat_replication.backend_xmin при этом NULL.
...
Рейтинг: 0 / 0
Много update
    #39605549
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21,

Не должны. Если на реплике с включенным h_s_f идёт долгий запрос, а из слота активно читается лог, то psr.backend_xmin будет явно старше, чем prs.xmin.
...
Рейтинг: 0 / 0
Много update
    #39605579
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vyegorov,
Экспериментирую - включен HSF, делаю на реплике:
begin; select count(*) from table; (100ГБ),
затем
select age(xmin) from pg_replication_slots, на мастере, непрерывно растет
select age(backend_xmin) from pg_stat_replication - возвращает null
Что я делаю не так? :)
Может backend_xmin работает при отсутствии слотов?
...
Рейтинг: 0 / 0
Много update
    #39605607
Фотография vyegorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21,

Упс, я не понял что у вас реплика через слот работает.

А в pg_stat_replicaiton есть запись для реплики?
...
Рейтинг: 0 / 0
Много update
    #39605623
Melkij
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
gav21select age(xmin) from pg_replication_slots, на мастере, непрерывно растет
Хм, а у вас слот физический или логический? Физические же вроде не используют ни xmin ни catalog_xmin и там null - за ненадобностью.
...
Рейтинг: 0 / 0
Много update
    #39605717
gav21
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Melkij,

Слот физический.


vyegorov ,
да, конечно, в pg_stat_replication есть статистика по активной реплике
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Много update
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]