Comments 17
Прошу сделайте статью где подробно покажете как мониторить и искать проблемы в базе данных при сложных и длиельных запросах которые тормозят систему. т.е. что нужно оптимизировать и улучшить чтобы повысить производительность?
pgTune - не открывается. Настройки Постгресса, сделали, размещён в системе виртуализации, как и MsSQL. Разница во времени выполнения запроса, по сравнению с MsSQL, на таблице с миллионом записей в 100 раз (2с vs 0.02с). План запроса - нормальный, индексы используется (запрос, элементраный, оптимизировать - нечего). Каким образом протестировать Постгресс, что бы можно было сказать, что он работает достаточно производительно на выделенных ресурсах или, что ресурсов не достаточно?
Статья выглядит пересказом из родной документации. Вот если бы в статье было описано исследование влияния хотя бы одного из описанных параметров на производительность при разных профилях нагрузки, тогда бы она представляла самостоятельную ценность.
Расскажите, как быть с лимитом соединений на юзера? Его надо выставлять сразу при создании пользователя, который может потреблять пару часов в сутки свой максимум, а в остальное время впустую занимать лимит, при том, что новых пользователей уже нельзя будет завести, хотя ресурсы фактически свободны. Понимаю, что там в pg трэш с обработкой запросов процессами и этими приблудами-пулерами, но как с этим жить вообще после божественного ms sql?)
Чем вам мешает лимит подключений на пользователя?
Не тратит свой лимит - ничьих лимитов, ресурсов, и чего вы там еще напридумывали, не занимает, тем более это никак не влияет на возможность заводить новых пользователей.
Насколько я знаю, такой дичи нет и в божественном ms sql, может вы это из 1с притащили (не знаю, как в 1с)?
В ms sql - нет, а в pg - есть. И непонятно, как в этом треде 1С очутился)
вы ссылаетесь на документацию конкретного облачного сервиса. В PG такой параметр у юзера есть, но он не обязательный, по дефолту не задан, и даже если задан — он не отбирает лимиты у других юзеров. Ну, просто потому, что у них-то этого лимита нету.
https://postgrespro.ru/docs/postgresql/16/sql-createrole
Что-то сомневаюсь, что pg при max_connections = 100, например, даст завести 10 юзеров с connection limit = 20.
ну как-то не понятно зачем сомневаться, если легко проверить.
portnov=# show max_connections;
max_connections
-----------------
100
(1 row)
portnov=# create user usr1 with connection limit 30;
CREATE ROLE
portnov=# create user usr2 with connection limit 30;
CREATE ROLE
portnov=# create user usr3 with connection limit 30;
CREATE ROLE
portnov=# create user usr4 with connection limit 30;
CREATE ROLE
portnov=# create user usr5 with connection limit 30;
CREATE ROLE
portnov=# create user usr6 with connection limit 30;
CREATE ROLE
portnov=# create user usr7 with connection limit 30;
CREATE ROLE
portnov=# create user usr8 with connection limit 30;
CREATE ROLE
portnov=# create user usr9 with connection limit 30;
CREATE ROLE
portnov=# create user usr10 with connection limit 30;
CREATE ROLE
portnov=# \du usr*
List of roles
Role name | Attributes | Member of
-----------+----------------+-----------
usr1 | 30 connections | {}
usr10 | 30 connections | {}
usr2 | 30 connections | {}
usr3 | 30 connections | {}
usr4 | 30 connections | {}
usr5 | 30 connections | {}
usr6 | 30 connections | {}
usr7 | 30 connections | {}
usr8 | 30 connections | {}
usr9 | 30 connections | {}
вот подключиться всем этим пользователям по 30 раз каждому одновременно — PG не даст, max_connections не позволит.
А я-то думаю, откуда вы этого набрались..
Это не postgres, это продукт Яндекса по мотивам postgres'а. Так сказать, почти идентичный натуральному.
1с - потому что сейчас тренд с перетаскиванием 1с с mssql на postgres, когда спецы по mssql плюются от того, что постгрес не так устроен, но вынуждены использовать. Предположил, что это как раз ваш случай.
Упд.
Проверил, действительно в Яндексе так.
На мой взгляд, похоже, что они готовят почву для тарификации по пользователям.
Выше ответил, не знаю или вы следите за всей темой: у обычного pg тоже есть такие лимиты у юзеров, и больше max_connections вряд ли получится использовать. Может все выставляют -1 и не подозревают)
Быстрее проверить.
Какой же тогда смысл в этой настройке в чистом pg? Как я понял, суть в том, чтобы один юзер не мог все соединения сервера захватить. Т. е. в managed postgres от Яндекса, она хотя бы работает)
Получается, что Яндекс пытается отнять [все ресурсы], и поделить поровну, что не вполне соответствует пожеланиям пользователей, см. ваш первый комментарий.
В ванильном postgres эта настройка отдается на откуп администратору, что дает гораздо большую гибкость.
Вот этот указанный выше вариант, когда суммарный connection limit много больше, чем max_connection, можно истолковать так, что ресурсов хватает максимум на 100 подключений, но для оптимальной работы системы не принципиальна пропорция между подключениями разных пользователей.
Если нужно именно жестко зафиксировать пропорцию, то нужно назначать лимиты всем пользователям так, чтобы в сумме не случилось превышения лимита подключений.
это именно лимит, а не способ разделить ресурсы по разным пользователям. На практике, юзер в БД — это обычно не юзер в смысле человек, а приложение. Поэтому, если у вас например есть какое-нибудь мониторинговое приложение, и есть основания опасаться, что оно внезапно (из-за бага или уязвимости) откроет 100 подключений, можно ему зарезать connection limit. А основному бизнес-приложению не ограничивать, т.к. это как раз для него предназначенная БД.
В яндексовом pg этот лимит резервируется за юзером и невозможно завести новых юзеров, превысив max_connections. Что очень мешает, когда на кластере у нас 100 БД, каждая со своим юзером, нагрузки никакой, т. к. тестовый кластер, а соединения никогда не используются по максимуму одновременно. Скорее наоборот, полчаса в день работы под каждым юзером)
В целом неплохо, но очень-очень поверхностно.
max_wal_sizeиmin_wal_size: параметры контролируют максимальный и минимальный размеры журнала.
Здесь смысл настроек не объяснен, а возможно даже и не понят автором.
Активные сессии: максимальное количество активных сессий должно быть настроено через параметр
max_connections
Через параметр ограничиваются подключения в целом, а не активных сессий. Это другое.
Частота взаимоблокировок: отслеживание взаимоблокировок помогает предотвратить доп. нагрузку на ресурсы ОС и задержки в будущем.
Не частоту нужно отслеживать, а их появление в принципе - т.е. ошибки в дизайне приложения.
По рекомендациям изменения параметров - очень неплохо было бы упоминать, в каких пределах стоит их менять, какие требуют перезапуска БД, какие перечитывания конфигурации, а какие можно и на уровне сессии поменять.
Если рекомендуете конфигурилки типа pgTune, тем более не открывающейся, неплохо бы упомянуть, что есть подобные от cybertec (https://pgconfigurator.cybertec-postgresql.com/), https://www.pgconfig.org и проч.
Ну и в целом - хорошо было бы эту статью перед публикацией на вычитку специалисту дать.
Основные настройки для управления ресурсами в PostgreSQL: настройка памяти, CPU и I/O