У меня есть несколько вопросов по этой опции. Понятно, что по умолчанию она закомментирована в app.yml, и может улучшить производительность сортировки, но увеличивает потребление памяти на каждое соединение. Но что это значит на самом деле? Зависит ли это от количества соединений? Что такое db_work_mem? Устанавливается ли он автоматически при установке Discourse, как db_shared_buffers и UNICORN_WORKERS? Безопасно ли его включать или это для продвинутых пользователей?
Сейчас она выглядит так: #db_work_mem: "40MB"
Сервер: Vultr High Frequency Compute 2 vCore, 4096 MB
Спасибо, Джей! На самом деле меня это просто заинтересовало. Я искал способы улучшить производительность форума, но если это может вызвать проблемы, возможно, лучше оставить это закомментированным.
То есть, если я активирую это, есть высокий риск исчерпания памяти, если настройка неверна или трафик возрастёт? Если я правильно понимаю.
work_mem ( integer )
Задает базовый максимальный объем памяти, который может использоваться операцией запроса (например, сортировкой или хэш-таблицей) перед записью во временные файлы на диске. Если это значение указано без единиц измерения, оно интерпретируется как килобайты. Значение по умолчанию — четыре мегабайта ( 4MB ). Обратите внимание, что для сложного запроса несколько операций сортировки или хэширования могут выполняться параллельно; каждой операции обычно разрешается использовать столько памяти, сколько указано в этом значении, прежде чем она начнет записывать данные во временные файлы. Кроме того, несколько активных сессий могут выполнять такие операции одновременно. Следовательно, общий объем используемой памяти может многократно превышать значение work_mem; при выборе этого значения необходимо учитывать данный факт. Операции сортировки используются для ORDER BY, DISTINCT и слияния (merge joins). Хэш-таблицы применяются в хэш-соединениях, хэш-агрегации и хэш-обработке подзапросов IN.
Операции на основе хэширования, как правило, более чувствительны к доступности памяти, чем эквивалентные операции на основе сортировки. Память, доступная для хэш-таблиц, вычисляется путем умножения work_mem на hash_mem_multiplier. Это позволяет операциям на основе хэширования использовать объем памяти, превышающий обычное базовое значение work_mem.
Иногда помогает увеличить рабочую память в два раза по сравнению с закомментированным значением по умолчанию. Я думаю, это полезно для больших сайтов с крупными индексами, но в основном я не уверен. Я однажды сломал сайт, установив слишком высокое значение.
Если вы хотите поэкспериментировать с настройкой, можете посмотреть плагин Prometheus и построить красивые графики с помощью Grafana.
По умолчанию она рассчитывается исходя из 100 соединений.
Общий объем ОЗУ * 0,25 / max_connections
У меня получается 4096 МБ * 0,25 / 100 ≈ 10 МБ.
В шаблоне postgres.template.yml по умолчанию указано db_work_mem: "10MB", что, по-видимому, рассчитывается по этой формуле. На мой взгляд, сейчас 10 МБ — это максимум. Спасибо, Джей
