5.7. Ввод-вывод фоновых процессов

150Глава 5. Область общей памяти и ввод-вывод

Задача процесса фоновой записи заключается в записи грязных буферов из буферного кеша

восновное хранилище.Процесс выполняет свою работу,чередуя ее с паузами.Перед началом очередной итерации выполняется оценка количества обращений к буферам, которое произошло за предыдущую итерацию,— чем больше обращений,тем больше буферов будет списано

вэтой итерации (см. bgwriter_lru_multiplier), но не более, чем указано в bgwriter_lru_maxpages1.

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

Процесс checkpointerвыполняетконтрольнуюточку,надежнозаписываяизмененныеданные в основное хранилище.В моментзавершения контрольнойточки гарантируется,что все изменения, произошедшие до начала контрольной точки, синхронизированы с диском. Контрольные точки позволяют обслуживать WAL-журнал, удаляя старые сегменты и освобождая место под новые. В процессе выполнения контрольной точки процесс сканирует буферный кеш, отмечая все грязные буферы как требующие синхронизации,а затем постепенно записывает их содержимоевосновноехранилище.Выполнениеэтойработытожеподразумеваетввод-вывод, объем которого напрямую зависит от количества грязных буферов. Исчерпывающую информацию о работе процесса контрольной точки можно получить из документации2 и книг3.

Представление pg_stat_bgwriter. Для отслеживания работы процессов фоновой записи и контрольнойточкиможноиспользоватьпредставлениеpg_stat_bgwriter.Историческиобезадачи выполнялись одним процессом, но в версии 9.2 работа, связанная с контрольными точками, была вынесена в отдельный процесс, а статистика так и осталась в общем представлении. Представление содержит всего одну строку:

# TABLE pg_stat_bgwriter;

Статистика относится не только к процессам фоновой записи и контрольной точки,но и к фоновой записи в целом.Давайте рассмотрим представление более подробно.

1 postgrespro.ru/docs/postgresql/current/runtime-config-resource#RUNTIME-CONFIG-RESOURCE-BACKGROUND-WRITER 2 postgrespro.ru/docs/postgresql/current/wal-configuration

3 www.interdb.jp/pg/pgsql09.html#_9.7.

Причины наступления контрольных точек. Первые два поля описывают количество выполненных контрольных точек:

•checkpoints_timed—количество контрольных точек,выполненных по расписанию;

•checkpoints_req—количество контрольных точек,выполненных по необходимости.

Как видно, контрольные точки могут запускаться либо по расписанию, через интервал времени, указанный в параметре checkpoint_timeout, либо по необходимости, что означает внеплановыйзапускприпревышенииобъемомзаписиограничения,установленноговпараметре max_wal_size. Также к последней категории относятся контрольные точки, запущенные администраторомспомощьюкомандыCHECKPOINT,иконтрольныеточки,выполняемыепривыключении сервера СУБД для синхронизации буферного кеша с основным хранилищем.

При настройке контрольных точек есть две стратегии. Первая стратегия полагается на выполнение контрольных точек по расписанию,когда выбирается относительно длинный интервал времени checkpoint_timeout и выполнение контрольной точки растягивается на этот интервал. Этастратегияпримениманаоборудованииснизкойпроизводительностью,иеесмыслсостоит

враспределениенагрузкиотконтрольныхточектакимобразом,чтобыеевыполнениеменьше влияло на общую производительность. При этом появление контрольных точек по необходимости указывает на то, что нагрузка увеличилась и в WAL-журнал стало записываться больше данныхещедоистечениянастроенногоинтервала.Уэтойстратегииестьнедостаток:еслиувеличивать интервал checkpoint_timeout и предел max_wal_size,то из-за больших объемов записи

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

вWAL,нужно воспроизвести).

Вторая стратегия полагается на выполнение контрольных точек по необходимости на основе значения max_wal_size — как только объем записи в WAL-журнал достигнет указанного значения, будет запущено выполнение контрольной точки. Этот способ хорошо подходит для регулировки времени восстановления после сбоя: оно более предсказуемо, поскольку известно, какой объем WAL нужно воспроизвести, и значение max_wal_size можно подстроить под характеристики производительности оборудования. Но и у этой стратегии есть недостаток. Значение max_wal_size служит только ориентиром, а в реальности в WAL-журнал может быть записано больше изменений,что тоже отразится на времени восстановления.

Особенностью записи в WAL-журнал является то, что после выполнения контрольной точки первое изменение любого буфера в кеше приводит к записи всей страницы (full page write, FPW) из этого буфера в журнал (см. full_page_writes). Все последующие изменения в этом буфере будут журналироваться отдельно.Таким образом,при частом выполнении контрольных точек(неважно,поинтервалуилипонеобходимости)будетвозникатьдополнительнаянагрузка от записи полных образов страниц, и объем этой нагрузки зависит от размера буферного кеша и объема происходящих в нем изменений (операции INSERT,UPDATE,DELETE).

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

152Глава 5. Область общей памяти и ввод-вывод

процессов и выполняемых запросов. При такой стратегии увеличение checkpoints_req расценивается негативно и является поводом для оценки увеличения реальной нагрузки и ее влияния на общую производительность, для пересмотра конфигурации и последующего поиска причин возрастания нагрузки. В современных условиях, когда производительность дисковых подсистем сильно выросла благодаря SSD- и NVMe-носителям, актуальность такого подхода уже ставится под сомнение. В любом случае при выборе стратегии следует ориентироваться на метрики производительности подсистемы хранения и пропускной способности СУБД при выполнении запросов.

В мониторинге можно использовать график на основе этих метрик (рис. 5.7) и отслеживать пикипоявления«нежелательных»контрольныхточек(взависимости отвыбранной стратегии настройки).

Рис. 5.7.Выполнение контрольных точек

График показывает, что бóльшая часть контрольных точек выполняются по расписанию, значит,объем записи в WAL-журнал укладывается в предел max_wal_size.Есть и контрольные точки, выполненные по необходимости: если бы это была производственная среда, это мог бы бытьпик записи в WAL,но втестовом окружении нагрузка стабильная,и,как следствие,объем записи в WAL тоже ровный, без резких всплесков. Для демонстрации эти контрольные точки были запущены с помощью команды CHECKPOINT.

Продолжительность выполнения контрольных точек. Выполнение контрольной точки можно условноразделитьнадваэтапа:записьсодержимогогрязныхбуферовнадискивызовсинхронизации с основным хранилищем (см. fsync).Запись на первом этапе не дает надежной гарантии сохранности данных, поэтому необходим второй этап с явной синхронизацией (однако и здесь могут быть проблемы1). Разделение на этапы условное, поскольку выполнение контрольнойточкиустроенотак,чтозапросынасинхронизациювыстраиваютсявочередь,и,если очередьзаполнена,записьприостанавливается,выполняется синхронизация уже записанных

1 wiki.postgresql.org/wiki/Fsync_Errors

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

•checkpoint_write_time—время,затраченное на запись страниц;

•checkpoint_sync_time—время,затраченное на синхронизацию.

Запись страниц на первом этапе занимает бóльшую часть времени контрольной точки, а синхронизация является завершающим этапом и, как правило, выполняется существенно быстрее. Однако скорость синхронизации зависит от производительности дисковой подсистемы: намедленныхносителяхнаэтапесинхронизациимогутобразоватьсяочередизапросоввводавывода, что приведет к увеличению задержек и снижению производительности. Следовательно, медленная синхронизация — признак недостаточной производительности дисковой подсистемы. По значениям этих полей мы можем отслеживать время, требуемое на синхронизацию, и, если синхронизация становится долгой, стоит оценить влияние контрольных точек напроизводительностьзапросов(изменениевременивыполнениязапросоввмоментсинхронизации на контрольных точках).

Для отслеживания времени выполнения можно использовать график на основе метрики postgres_checkpoints_seconds_total (рис. 5.8):

Рис. 5.8.Продолжительность выполнения контрольных точек

Наэтомграфикевидно,чтовремявыполненияконтрольныхточекровное,новинтервалеесть две контрольные точки, где синхронизация длится около 10 секунд. Это выделяется на фоне других контрольных точек и является достаточным поводом проявить интерес и разобраться, почему в редких случаях синхронизация выполняется так долго.

Запись буферов. Следующие поля позволяют анализировать объем данных, записанных как фоновыми,так и клиентскими процессами:

•buffers_checkpoint—количество буферов,записанных процессом контрольной точки;

•buffers_clean—количество буферов,записанных процессом фоновой записи;

Резюме 155

Рис. 5.9.Количество буферов,записанных разными процессами

статистика этого представления используется для построения сводных отчетов,то важно смотреть,чтобы статистика была накоплена за относительно длинный период,например 2–4 недели. Статистика за более короткие периоды может быть не очень показательной, азаслишкомбольшие—сильноусредненнойинеотражающейкакие-либовсплескиивоз- можные аномалии.

Завершая главу, стоит отметить, что некоторые другие представления, такие как pg_stat_wal или pg_stat_replication_slots,также содержат статистику ввода-вывода. Они в меньшей степени относятся к вводу-выводу,связанному с пользовательскими данными,однако могут слу- житьисточникоминформацииовводе-выводенауровнеэкземпляраСУБД.Этиидругиепред- ставления будут рассмотрены в следующих главах,посвященных WAL-журналу и репликации.

Резюме

•Представление pg_buffercache позволяет оценить использование буферного кеша с разных сторон.

•Для анализа структуры общей памяти используется представление pg_shmem_allocations.

•Для анализа структуры памяти клиентских процессов используются представление pg_backend_memory_contexts и функция pg_log_backend_memory_contexts.

•Для оценки использования SLRU-кешей используется представление pg_stat_slru.

•Для оценки общего ввода-вывода можно использовать pg_stat_database.

•Детальную оценку ввода-вывода по конкретным объектам БД можно получить в соответствующих представлениях pg_statio_*.

156Глава 5. Область общей памяти и ввод-вывод

•Для оценки ввода-вывода при выполнении запросов можно использовать представление pg_stat_statements.

•Для общей оценки временных файлов можно использовать pg_stat_database.

•Для оценки ввода-вывода,связанного с временными файлами,при выполнении запросов можно использовать pg_stat_statements.

•Отслеживать временные файлы можно с помощью журналов сообщений СУБД.

•Важно отслеживать активные временные файлы.

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

•Для оценки ввода-вывода фоновой записи и процесса контрольнойточки следует использовать представление pg_stat_bgwriter.