ReSQL.ru
     
powered by simpleCommunicator - 2.0.40     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Массовые вставки и autovacuum
10 сообщений из 10, страница 1 из 1
Массовые вставки и autovacuum
    #40131387
Desert_Nomad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Desert_Nomad
Гость
Добрый день, всезнающий ALL.

Есть таблица, 79Гб. В нее осуществляется загрузка данных (~50 млн записей, insert + update). По словам ДБА возникает такая коллизия - поднявшийся autovacuum блокирует таблицу, и начинают копиться WAL, достигая уровня алерта. Как autovacuum заканчивает - WAL понемногу рассасываются.

Первое, что приходит в голову - отключать автовакуум по таблице на период загрузки и включать назад по ее завершению.
А есть ли еще какие-нибудь варианты борьбы с таким явлением?
...
Рейтинг: 0 / 0
02.02.2022, 23:49
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40131395
Фотография DSKalugin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DSKalugin
Участник
Desert_Nomad,
autovacuum может работать параллельно с обычными операциями чтения и записи таблицы, так она не требует исключительной блокировки. Параметры, которые влияют на поведение и нагрузку описаны тут
https://postgrespro.ru/docs/postgresql/12/runtime-config-autovacuum
...
Рейтинг: 0 / 0
03.02.2022, 01:11
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40131435
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Desert_Nomad
По словам ДБА возникает такая коллизия - поднявшийся autovacuum блокирует таблицу, и начинают копиться WAL, достигая уровня алерта. Как autovacuum заканчивает - WAL понемногу рассасываются.


Звучит очень странно ("полный бред") с т.з. анализа причин.
накопление wal никак не связано явным образом с autovacuum, autovacuum таблицу не блокирует тоже.
Для более точного ответа на вопрос требуется информация от базы (предполагая что версия база у вас относительно свежая):

show max_wal_size;
show wal_keep_size;
show checkpoint_timeout;

и самое главное
select * from pg_replication_slots ;

в идеале ещё графики скорости записи wal за сутки и графики количества wal файлов у базы.

Наиболее вероятное предположение - просто много записи идёт и много wal генерируется которые не успевают обрабатываться тем процессом что на replication slot висит (будь то физическая/логическая репликация или dbezium какой), и за счёт этого начинают копиться wal файлы пока их не разберут.

В принципе в такой ситуации два выхода или разбирать кто replication slot читает и почему тормозит или замедлять загрузку данных до той скорости чтобы wal не копились.

PS: "и начинают копиться WAL, достигая уровня алерта." - а да интересно какой alert стоит конечно же тоже.

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
03.02.2022, 11:24
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40131540
Desert_Nomad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Desert_Nomad
Гость
Максим, спасибо за ответ.

PG 12.5

max_wal_size - 4 Gb
wal_keep_size - такого параметра нет, близкий по смыслу wal_keep_segments - 500
checkpoint_timeout - 30min

в pg_replication_slots есть активный physical target.

Из графиков могу только предложить только использование места в pg_data (там и копятся WAL-ы), а также колебания числа архивных логов в pg_archlogs.
...
Рейтинг: 0 / 0
03.02.2022, 19:09
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40131551
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Desert_Nomad
Максим, спасибо за ответ.

PG 12.5

max_wal_size - 4 Gb
wal_keep_size - такого параметра нет, близкий по смыслу wal_keep_segments - 500
checkpoint_timeout - 30min

в pg_replication_slots есть активный physical target.

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


по виду графиков как раз ОЧЕНЬ похоже что скорость вычитывания из "pg_replication_slots есть активный physical target." и является причиной накопления WAL.
Имело бы смысл посмотреть на pg_replication_slots в моменты проблем и посмотреть какое отставание restart_lsn и confirmed_flush_lsn у вас наблюдается во время проблем.
Ну и далее смотреть что там такое твориться.
Если у вас на слоте висит streaming репликация - надо смотреть прежде всего на загрузку канала до реплики и на загрузку самой реплики (ну и её отставание).
Если ничего с этим не получается сделать - уменьшать скорость загрузки данных в базу.

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

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
03.02.2022, 19:59
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40131622
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Теория,
если я правильно понимаю, у Вас на таблице в 79Гб при вставке генериться более 500Гб wal,
в связи с этим есть предположение, из-за max_wal_size - 4 Gb постоянно прибегает checkpoin + full_page_writes при этом генериться еще больше wal
и цикл повторяется.

Можно попробовать, поднять max_wal_size до 300Гб, и посмотреть не уменьшиться ли количество(объем) wal-ов.

И еще провести эксперимент, до начала загрузки смотрим

Код: sql
1.
select * from pg_stat_bgwriter \gx



выполняем загрузку и опять смотрим
Код: sql
1.
select * from pg_stat_bgwriter \gx



Второй эксперимент, меняем max_wal_size
и смотрим, что получилось.


И смотрим настройки
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
select name,setting,unit,context 
from pg_settings 
where name in ('checkpoint_timeout'
            ,'checkpoint_completion_target'
            ,'max_wal_size'
            ,'bgwriter_delay'
            ,'bgwriter_flush_after'
            ,'bgwriter_lru_maxpages'
            ,'bgwriter_lru_multiplier') 
order by name;
...
Рейтинг: 0 / 0
04.02.2022, 10:00
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40132384
Desert_Nomad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Desert_Nomad
Гость
Прогнали очередную загрузку под наблюдением. Да, забыл сказать что это patroni - кластер.
Проверили - лага на реплике нет. Так что скорее всего не из-за этого.

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

Есть еще один момент - накануне выполняли перераспределение разделов диска (сократили область на archlogs, добавили в pgdata), но тут неясно, могло ли это как-то повлиять.

Идею насчет изменения max_wal_size - попробуем, решение нужно, но пока не просматривается.
...
Рейтинг: 0 / 0
08.02.2022, 00:37
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40132455
Desert_Nomad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Desert_Nomad
Гость
checkpoint_timeout: 1800 s
checkpoint_completion_target: 0.9
max_wal_size: 4096 Mb
bgwriter_delay: 200 ms
bgwriter_flush_after: 64 8kB
bgwriter_lru_maxpages: 100
bgwriter_lru_multiplier: 2
...
Рейтинг: 0 / 0
08.02.2022, 11:32
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40132460
Guzya
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guzya
Гость
Самое интересное это
до загрузки и после загрузки
Код: sql
1.
select *,now() from pg_stat_bgwriter \gx



что бы понять, сколько раз пришел checkpoint не по расписанию.
...
Рейтинг: 0 / 0
08.02.2022, 11:36
| Ответить | Цитировать | Написать  
Массовые вставки и autovacuum
    #40132481
Фотография Maxim Boguk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxim Boguk
Участник
Desert_Nomad
Прогнали очередную загрузку под наблюдением. Да, забыл сказать что это patroni - кластер.
Проверили - лага на реплике нет. Так что скорее всего не из-за этого.

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

Есть еще один момент - накануне выполняли перераспределение разделов диска (сократили область на archlogs, добавили в pgdata), но тут неясно, могло ли это как-то повлиять.

Идею насчет изменения max_wal_size - попробуем, решение нужно, но пока не просматривается.


Я бы посоветовал триальный okmeter мониторинг на недельку поставить... там сразу всё видно будет на счёт wal ;).
Заодно понятнее будет что именно в вашем мониторинге надо дорабатывать для эксплуатации базы.

Если же по сложному пути то в момент когда много wal посмотреть на разницу между данными pg_stat_archiver и pg_current_wal_lsn().
И всётаки проверить что нет отставания по данным pg_replication_slots в реальности (не по лагу на реплике а по данным на мастере).

--
Maxim Boguk
лучшая поддержка PostgreSQL: dataegret.ru
...
Рейтинг: 0 / 0
08.02.2022, 13:16
| Ответить | Цитировать | Написать  
10 сообщений из 10, страница 1 из 1
Форумы / PostgreSQL [игнор отключен] [закрыт для гостей] / Массовые вставки и autovacuum
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru             Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=53&tid=1993668]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 375ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 45ms
get tp. blocked users:
 1ms
others: 254ms
total:  720ms
созд. / загр.: 720ms
x
x
Закрыть


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