Comments 10
Вам уже советовали RTFM в первой статье, ну ещё раз посоветую — почитайте про контрольные точки, чтобы не писать такое:
Чекпоинт нужен, чтобы время от времени освобождать место в WAL путем записи данных из него в БД
А совет выставить checkpoint_completion_target в 0.1 не приведет ни к чему, кроме пиковых нагрузок на ввод-вывод.
Да, можно выставить и 0.75, и 0.9. Я вроде уже написал, почему 0.1. Есть максимальный объем журнала, и checkpoint_completion_target - это доля от него. Чем больше самих файлов в WAL - тем дольше система будет восстанавливаться после сбоя. Это полезно учитывать, потому что у большинства кластера нет ни в каком виде. Ну и еще файлы журнала занимают место на диске. В больших системах с HL - да, надо с умом подходить. Но каждый думает, что у них High Load, даже если у них базы суммарным объемом 50 GB.
checkpoint_completion_target = 0.1 и max_wal_size = 10GB
это то же самое, что и (в плане объема данных, которые будут записаны):
checkpoint_completion_target = 0.5 и max_wal_size = 2GB
Про сам чекпоинт я мог бы написать, что эта такая операция, которая сбрасывает на диск все грязные буферы из памяти. Я не пытаюсь прикрыть свою ошибку, просто я сисадмин, а не разработчик, а сисадминам, зачастую, такие вещи не очень интересны (я именно про устройство WAL, грязные буферы и т.п.). Для нас главное - чтобы все работало, чтобы производительность была терпимой и предсказуемой, а восстановление происходило как можно быстрее.
Спасибо, что тратите время на подобные статьи. Уверен, вы также ничего нового из нее не узнаете: вы на порядок выше меня в плане PostgreSQL.
checkpoint_completion_target = 0.1 и max_wal_size = 10GB
это то же самое, что и (в плане объема данных, которые будут записаны):
checkpoint_completion_target = 0.5 и max_wal_size = 2GB
Так ведь нет же.
Если считать, что max_wal_size - это объем данных, который должен быть записан между контрольными точками (что само по себе не верно), то объем данных в первом случае будет 10GB, а во втором - 2GB.
А если смотреть на необходимую скорость записи, то (считая для простоты, что контрольные точки выполняются раз в 10 минут) в первом случае надо писать со скоростью 10GB/min, а во втором - 0.4GB/min. Вот вы и создали пик на пустом месте.
Кстати, с 14-й версии значение по умолчанию 0.9, и это неспроста.
Спасибо, увидел, какую бредятину я написал. Разобрался, исправил. Видимо, не надо ничего писать после рабочего дня. Лучше с утреца.
Кстати, вот по этой второй части, что вы думаете про настройку параметров автоматической очистки? Там все хорошо или как всегда RTFM?
Там есть к чему попридираться (например, «с одним объектом может работать несколько рабочих процессов» — на самом деле нет) и некоторые рекомендации конкретных цифр мне сомнительны, но в целом адекватно, вредных советов я не заметил.
Кстати, в грядущей 17-й версии сильно уменьшили потребление памяти, и она к тому же будет выделяется по мере необходимости, а не вся сразу.
То есть вы хотите сказать, что если автовакуум захочет пройтись по одной таблице из 1 млн. строк, то одновременно будет задействован только один процесс? Если да, то это очень странно. Хотя, чего странного, у нас ведь блокировки. В общем, исправлю. Производительность на ядро опять выстрелила.
По поводу рекомендаций и цифр. Добавлю свои 5 копеек .
Чем дольше, тем больше прихожу к предположению , что эффект тонкого тюнинга конфигурационных настроек СУБД совершенно не стоит потраченного времени и полностью нивелируется побочными эффектами инфраструктуры и приложения .
А с оценкой влияния изменения какого либо параметра на производительностью СУБД в условиях облачной инфраструктуры совсем все печально . Оценить эффект практически невозможно .
Никакого тонкого тюнинга в статье нет. Просто отправная точка. Если система крупная - там да. Но для большинства главное, чтобы не было проблем (как с тем же отключением автовакуума), а повышение производительности и снижение потребления ресурсов для них так, приятный бонус. Очень многих проблем на самом деле можно избежать, просто изменив пару параметров. Если для той же 1Ски оставить объем общих буферов в 128MB для 50 живых юзеров это уже реальная катастрофа. Про оборудование уже сказал. С облаками не работал.
К примеру, если система видит, что чекпоинты стабильно создаются с интервалами по 10 минут, то при значении 0.9 чекпоинт уже начнет записываться через 9 минут, а не 10 (но чуть медленнее).
Неправильно написано.
Администрирование PostgreSQL для начинающих (часть 2)