Comments 37
Чему ж вы людей-то учите?
work_mem
Это максимальный объем памяти, выделяемый для каждого подключения (для обработки запросов). Следовательно, посчитать общий объем занимаемой памяти можно путем умножения на максимально возможное количество одновременных подключений со стороны приложения.
Этот объем памяти может при необходимости выделяться каждому узлу плана. (Не говоря уже о том, что в некоторых случаях и это ограничение не учитывается.) Поэтому умножать примерно бесполезно.
Однако рекомендую все же использовать утилиту pg_conftool, это просто снизит вероятность ошибок.
Почему не ALTER SYSTEM SET .... ?
work_memЭто максимальный объем памяти, выделяемый для каждого подключения
Каждый кто прочитает это, и не уточнит по документации, получит аварийную остановку СУБД по причине OOM Killer.
Это высказывание - ложно.
RTFM
А вот это уже мой косяк, признаю. Надо исправить. Может, просто объем памяти поделить на 4 и затем разделить на максимальное количество подключений? Как вы думаете? Потому что 4MB это ни о чем.
Нет нет и ещё раз RTFM
Этот объем памяти может при необходимости выделяться каждому узлу плана.
Другими словами разработчик может написать такой запрос , что при любом значении данного параметра придёт OOM killer
С параметром `listen_addresses` в `postgresql.conf` в статье серьёзная проблема.
Он служит не для задания списка IP-адресов или диапазонов, с которых будут происходить подключения, а для указания списка IP-адресов имеющихся на хосте сетевых интерфейсов, на которых экземпляр postgres должен ожидать ("слушать") и принимать подключения.
По умолчанию учетная запись postgres заблокирована, и подключиться к ней возможно только имея права суперпользователя Linux.
Ничего она не заблокирована, у нее просто пароля нет.
Если ваша ОС настроена так, чтобы не пускать людей с пустыми паролями, то нельзя будет зайти по паролю. Но можно будет например настроить вход по ssh ключу, и вот пользователь оказывается не заблокирован, и можно напрямую логиниться пользователем без суперпользователя.
SSH. Самый популярный – OpenSSH. Сделайте упор на безопасность.
Что SSH? А почему OpenSSH, а не rsync (тоже ssh), или putty?
Грамотное владение терминологией - основополагающее в обучающих статьях, иначе и читателей путаете и сами путаетесь.
Я провел небольшое тестирование 1С:Предприятие с PostgreSQL
А размер конкретно вашей базы?
Или неужели производительность постгреса зависит исключительно от оперативки, а не от размера самих данных?
Но есть одна проблема. Если вы работали с какой-либо системой мониторинга, то прекрасно знаете, что нагрузка на систему всегда выглядит следующим образом: 5-10% CPU и 80-90% RAM. Так что, если вы ограничены по финансам, на CPU можно экономить, но только не на подсистеме памяти.
Прям очень спорное утверждение. Особенно в случае таких баз как постгрес и оракл, у которых можно воспользоваться функционалом и перенести часть логики в саму базу.
По вашей табличке, у вас производительность перестала меняться после примерно 16 гб РАМ. Какой процент стоимости CPU составляет 16 GB RAM в 2024 году?
Про учетную запись исправлю.
Про SSH: речь про сервер. Клиент можно использовать любой.
Про 1С. Это не статья про тестирование 1Ски. Основной целью было показать, что всегда есть объем памяти, после которого производительность перестает расти. Если у вас объем баз будет в сто раз больше - то порог также будет выше. CPU не мониторил, там нагрузок почти не было.
Насчет производительности - это уже личное дело каждого. Статья не для DBA, и не для тех, кто админит 20 серверов СУБД. Статья для сисадминов-универсалов. Вот есть наша реальность, и в реальности есть куча фирм, где сисадмин - единственный ИТшник. А, ну и еще денег на оборудование нет, но вы держитесь.
temp_buffers выделяется так же на каждый сеанс подключения В том числе надо не забывать и фоновые задания. Видел такую "печаль", где 2 бухгалтера и ~30 баз. При расчете ресурсов, из расчета двух пользователей, все забыли про регламентные задания.
Тут же дано описание совсем базовых настроек, для них можно использовать pgtune, с этими параметрами он работает корректно.
А что вы скажете про частую рекомендацию изменения i/o sheduller на elevator=noop для postgreSQL на быстрых дисках?
Это уже на уровне самого ядра Linux, не PostgreSQL, параметра elevator нет в новых версиях ядра (надо гуглить, то ли они его вообще убрали, то ли изменили параметры - не могу вспомнить). Смотря что вы подразумеваете под словом "быстрые". Как бы деньги есть не у всех, и диски SSD Sata это уже подарок. На самом деле действительно проще купить SSD NVMe, если вы об этом. Надо будет почитать про планировщики.
"Вы чепуху говорите и возмутительнее всего то, что говорите ее безапелляционно и уверенно"
Извините.
temp_buffers
Это максимальный объем памяти, выделяемый для работы с временными объектами.
...
желательно выделить памяти побольше, вплоть до нескольких гигабайт, в зависимости от количества пользователей.
Этот параметр определяет размер буфера для каждой сессии, а не для всего экземпляра - никакой зависимости от "количества пользователей" нет.
maintenance_work_mem
Задает объем памяти для операций обслуживания (при ручной и автоматической очистке, массовом перестроении индексов, анализе и т.п.). Рекомендую выставить от 1/32 до 1/8 от общего объема памяти. Все зависит от того, будете ли вы назначать память отдельно для процесса автоматической очистки.
Если не задать autovacuum_work_mem, каждый процесс автовакуума сможет использовать количество памяти, заданное в maintenance_work_mem.
По рекомендации от 1с, максимальное количество воркеров автовакуума должно быть
autovacuum_max_workers =" CPU "cores/4..2 но не меньше 4.
Т.е. уже при 16 ядрах CPU выполнение этих рекомендаций вполне сможет помочь выстрелить себе в ногу.
huge_pages
Всегда отключайте, потому что рабочие нагрузки для баз данных не являются непрерывными при обращении к памяти. Мы получим более высокий уровень производительности, если БД будет помещена в общие буферы (shared_buffers). Основная проблема состоит в том, что Transparent Huge Pages плохо работают с базами, хотя сами по себе HP просто прекрасные. Если вы захотите включить HP – то готовьтесь подбирать еще и их размер методом проб и ошибок на продуктивной системе. По умолчанию стоит значение try, его можно оставить или полностью отключить.
Рекомендация столь сумбурная, что создается впечатление, что с этой темой вы так и не разобрались.
work_mem
Умные люди в комментариях меня поправили. Лучше вообще не менять и оставить по умолчанию 4MB.
Дичь. Параметр необходимо тюнить, посмотрите хотя бы рекомендации 1с, если вы, в основном, с 1с работаете.
work_mem = RAM/32..64 или 32MB..128MB
(хотя, конечно, и эти рекомендации сильно странны)
Про huge_pages - мы просто получим больше пользы (выгоды, профита, называйте как хотите), чем при использовании HP. Да, зависит от приложения. Да, со временем может измениться. Но пока что имеем, что имеем. Если СУБД используется для приложения, у которого, скажем, 1000 таких жирных клиентов, то да, можно подумать об использовании HP.
Про work_mem. Да, конкретно для 1С я видел много рекомендаций по увеличению этого параметра. Вплоть до нескольких гигабайт (общий объем памяти делят на 32-64, что на самом деле является бредом). Но как бы речь не про 1С, и не про сборку PostgreSQL для 1С. А, увидел, тоже считаете подобные рекомендации странными.
Так что, остановимся на том, что можно увеличить work_mem вплоть до 32MB?
Про work_mem - ставим некое разумное значение (начать можно хоть и с 4), если в логах часто встречаются сообщения об использовании темп-файлов, значит стоит задуматься об увеличении. Может быть и 32, и 132..
Путать просто Huge Pages и Transparent Huge Pages - огромная ошибка. Можно (и, возможно, нужно) THP выключить, а HP включить (/etc/sysctl.conf, параметр vm.nr_hugepages= ).
В аппаратное обеспечение все равно придется вкладываться, потому что оптимизировать систему, которая еле-еле отвечает минимальным системным требованиям, бессмысленно. 32 GB памяти и хранилище баз на HDD для той же 1Ски на 300 пользователей это все равно, что стакан воды для слона, и при этом неважно, какая СУБД используется: PostgreSQL, MS SQL или Oracle DB.
Если у вас не осталось ни одного кластера со старой версией, вы можете без проблем удалить пакет сервера этой версии, чтобы освободить место на диске.
Какой-то легкий диссонанс от сочетания этих двух рекомендаций..
В первом случае речь про нормальных таких клиентов, то есть 300 людей работают одновременно. Сервера для 1С (И для самой платформы, и для СУБД) в 90% организаций являются самыми мощными. 32 GB на 300 юзеров (конкретно для самой СУБД, то есть мы не рассматриваем случай, когда и приложение, и СУБД на одном хосте) недостаточно. Просто недостаточно. Они, может, и подключатся, но вот юзеры работать нормально не смогут. Аналогично и с хранилищем на HDD.
А в чем проблема со вторым? Вот есть пакеты postgresql-15 и postgresql-16, к примеру. Я смигрировал все базы на 16 версию, а зачем мне сервер 15?
Или вы про то, что это очевидные вещи? Для нас с вами - да, а вот для остальных - не могу знать.
Писать "кластер" и подразумевать "кластер БД" - штука, сбивающая с толку. Кластеров много всяких, но в компьютерном контексте обычно всё-таки имеют в виду именно набор нескольких серверов + специализированный софт. Кластер БД же такая специфическая вещь, что я скорее удлинил бы наименование, чем сократил бы его (постгресовый кластер БД).
Про большую важность объёма памяти, чем скорости процессора и количества памяти - как всегда, это не универсальный закон. Я вот имею ситуацию в одной БД, когда данные закешированы, поэтому упираемся в скорость одного ядра. А было бы много пользователей...
Про скорость доступа.
Да, у винчестеров необходимость передвижения магнитной головки приводит к тому, что крупноблочным способом мы читаем то же количество данных намного быстрее, чем мелкоблочным. И это важно для оптимизатора - решить, будет ли он пользоваться индексами и делать фуллскан.
И да, у SSD магнитных головок нет, seek time=0. Одна только проблема - у них (по крайней мере тех, которые я тестировал) разница между крупноблочными и мелкоблочными чтениями по пропускной способности ещё выше!
Сразу хочу сказать вам большое спасибо за все комментарии. Вы оставили несколько, я их все прочитал. Спасибо.
Я как раз у себя налетел (правда, на Oracle). Сперва стал рассчитывать правильные параметры и ужаснулся. Потом попробовал эти параметры в деле - ещё раз ужаснулся. Они ведь рассчитаны именно про чтение с диска. Оптимизатор минимизировал и выбрал фуллскан. Проблема в том, что ОЗУ столько, что все данные уже были считаны и реальное время чтения и так, и так = 0, зато нагрузка уже на ядро процессора оказалась выше для фуллскана. Поэтому, я полагаю, 1.0 должно быть правильным ответом в такой ситуации.
"0.1 – для SSD NVMe.
1.0 – для SSD без NVMe.
2.0 – для RAID из HDD.
4.0 – для одного HDD."
RAID для HDD seek time не уменьшает. А разница между мелкоблочным и крупноблочным чтением у SSD выше, чем у HDD.
Администрирование PostgreSQL для начинающих (часть 1)