Как настроить work_mem на основе журналов временных файлов?

Question

В статье я обнаружил, что одна heuristi c для настройки work_mem - это:

1. Начало с низкого значения: 32-64MB
2. Затем найдите в журналах строки «временный файл»
3. Установите в 2-3 раза больший временный файл

Выполняется:

SHOW log_temp_files; -- res: 0

Я обнаружил, что ведение журнала временных файлов включено.

1. Каковы недостатки ведения журнала temp_files?
2. Как я могу запросить журналы temp_file?
3. Есть ли лучший heuristi c для оценки правильного значения для work_mem?

Answer 1

Heuristi c хорошо. В основном, если вы получаете временные файлы «слишком часто» (намеренно расплывчато), может быть выгодно увеличить work_mem.

Если вы измените log_temp_files, вы получите сообщения в файле журнала. Для их чтения вам необходим доступ операционной системы к серверу базы данных.

Но есть альтернатива: просмотр статистики pg_stat_database имеет два столбца:

• temp_files bigint Количество временных файлов, созданных запросами в этой базе данных.
• temp_bytes bigint Общий объем данных, записанных во временные файлы запросами в этой базе данных.

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

Answer 2

Этот совет кажется мне довольно сомнительным. Он основан на предположении, что использование временных файлов - это плохо. Они неплохие, они определенно лучше, чем рухнуть или предаться забвению. Но если вы принимаете эту предпосылку, зачем начинать с низкого, а затем постепенно увеличивать «правильное» значение? Просто установите для work_mem смехотворно высокое значение для начала и покончите с этим. (Пока вы не поймете, что это была ошибочная посылка.)

Кроме того, размер любого временного файла ограничен 1 ГБ. Если вам нужно больше, чем этот объем временного пространства, он использует несколько файлов, но каждый файл регистрируется отдельно. Таким образом, простой просмотр самой большой зарегистрированной строки не покажет вам максимальный объем временного пространства, который использовал любой отдельный оператор. (Этот факт как бы ограничивает ущерб, который может нанести этот совет, поскольку вы, по крайней мере, не устанавливаете его более чем на 3 ГБ)

SHOW log_temp_files; -- res: 0 

Я обнаружил, что ведение журнала временных файлов отключено .

Нет, 0 означает регистрировать все. -1 означает отключено.

Answer 3

Вы можете включить ведение журнала временных файлов в postgres файле конфигурации (см. log_temp_files , и тогда вы увидите в журналах, какие операции «проливаются» на диск (сортировки, хеширование ..).

При этом я не думаю, что это какой-то серебряный подход к определению хорошего значения work_mem. Нельзя просто умножить какое-то значение из журналов на 3 и использовать его как work_mem. Важно понимать, как работает work_mem - это память для бэкэнда (для каждого соединения) и для каждой операции.

Итак, вы должны думать примерно так: «в типичном сценарии, сколько одновременных пользователей работают с интенсивным использованием памяти одновременно? ". И вы должны затем разделить объем ОЗУ, который вы хотите" зарезервировать "для work_mem (исключая общие буферы, другие процессы, некоторый разумный кеш ядра и т. д. c.). Да, это не точная наука. Если у вас обычно есть один или два одновременно работающих пользователя, выполняющих тяжелые сортировки, вы можете легко установить work_mem на 1 ГБ. Если у вас 500 одновременных пользователей, выполняющих lig ht, вы можете (и должны) установить гораздо меньший размер work_mem.