Почему так мало соединений с базой данных на 1ГБ оперативной памяти?

Question

[orbit070]

Всем привет.
Прошу помочь разобраться, почему приведены такие цифры у digitalocean.

Если я правильно понимаю, то там написано, что одно соединение ест около 10мб.
При этом дальше пишут, что нода с 1ГБ оперативки сможет держать примерно 25 соединений.
Сначала подумал что остальная память на обслуживание самой ноды и операционной системы и тд, но нет: даже если взять ноду с 4ГБ оперативной памяти, все равно на каждый ГБ будет +25 соединений(то есть на 4ГБ всего 100 соединений).

Прошу помочь с ответами на вопросы, кто чем может, буду очень благодарен:

1. Почему так мало соединений на каждый ГБ оперативной памяти, ведь исходя из "примерно 10МБ на соединение" их должно минимум раза в три больше чем 25?

2. Правильно ли я понимаю, что пул соединений не помогает в плане экономии оперативной памяти и каждое соединение в нем все равно кушает все те же 10МБ, а пул лишь снижает нагрузку на процессор из-за отсутствия необходимости каждый раз создавать/убивать соединение?

3. Правильно ли я понимаю, что эти 10МБ оперативки на соединение это именно на процесс, который относится к базе данных, а не к серверному коду? Имею в виду если база данных и серверный код на одной машине, из кода подключаемся к БД, тогда база будет кушать 10МБ оперативки на одно соединение а сервер будет кушать свои N МБ на соединение, и тогда на одной машине одно соединение уже будет 10+N МБ?

Заранее всем большое спасибо.

Comments

[Сергей Горностаев]

Вы видать забыли, что СУБД тратит память не только на соединения.

[orbit070]

Сергей Горностаев, не забыл, даже если предположить, что остальная память это обслуживание всего остального, то как объяснить то, что на каждый следующий ГБ тоже идет 25 соединений?

Есть нода 1ГБ, 250МБ(25 соединений) - на соединения, 750-все остальное.
Добавили еще 1ГБ и соединений стало 50(500мб), все остальное как помним это 750мб, тогда на что идут новые 750мб? если они нужны чтобы обслуживать дополнительные 25 соединений, тогда какой смысл говорить что одно соединение это 10мб, а не 40мб?

Прошу прощения если туплю, просто правда не могу понять почему так

[Сергей Горностаев]

orbit070, во-первых, надо понимать, что 10 Mb на соединение - это условность. Оптимальный объём памяти на соединение зависит от множества факторов и может существенно отличаться в разных сценариях использования. Во-вторых, СУБД нужна память на построение планов запросов, на кэширование горячих данных, на выполнение фоновых задач, таких как построение индексов, сборка мусора и т.д. и т.п. Чем больше памяти доступно СУБД и чем оптимальнее она распределена между подзадачами, тем выше производительность.

[orbit070]

Сергей Горностаев, большое спасибо

Answer 1

[Melkij]

Вот честно могу ответить - ни малейших представлений как можно абстрактно сказать, сколько памяти займёт client backend процесс базы.
Это будет меняться от:
- очевидно версии базы, плюс от компилятора и настроек сборки
- session_preload_libraries, work_mem (к слову о work_mem - вы знаете, что один запрос может использовать несколько work_mem?), temp_buffers. Да ещё maintenance_work_mem для некоторых операций
- величины системного каталога - как pinned таблиц, так и затем кэшированных при обращениях
- выполняемых ранее запросов. Тот же кэш хранимых процедур у каждого backend свой

Один backend вполне и десятки гб памяти может использовать и такие настройки может иметь смысл делать для, например, построения индекса.

Помимо собственной private памяти на каждое активное соединение всё множество max_connections резервирует себе некоторое место в сегменте разделяемой памяти, независимо от того, сколько соединений вы затем используете.

Чтобы админить калькуляторы и чайники обычно DBA не нанимают. Тем более если на том же самом калькуляторе помимо базы ещё и приложение отъедает непредсказуемо сколько памяти. Чего там от этого 1гб останется? Видимо даже shared_buffers с 128мб поднимать некуда, а то может и уменьшать придётся. Так что по опыту сложно что-то сказать о такой конфигурации.

Скорей всего не трогайте max_connections. Оставьте дефолтные 100.

Правильно ли я понимаю, что пул соединений не помогает в плане экономии оперативной памяти

Смотря какой пул и как работает приложение.
pgbouncer в pool_mode = transaction вполне может свести пару сотен подключений к баунсеру на десяток коннектов в базе. Ну а 10 процессов базы будут использовать наверняка поменьше памяти чем 200.
Для pool_mode = session - да, только сгладить стоимость fork годится.

Comments

[orbit070]

Да понимаю, что нюансов очень много и однозначно невозможно сказать сколько чего займет. Я просто ориентировался на средние значения, приведенные сервисом, и хотел понять, не сильно ли они занижены. А вообще если я правильно понял managed databases в большинстве своем заменяют DBA за относительно небольшие деньги, ведь все нужные настройки из коробки + бэкапы, реплики и прочие плюшки в пару кликов. По крайней мере думаю грамотный DBA обошелся бы дороже для небольшого проекта

Answer 2

[Fixid]

Не спец по PSQL
Но:
1. А где хранить данные в быстро доступе? Где хранить кэш таблиц и запросов?
2. Почти так
3. Со стороны СУБД нужно держать коннект и для этого требуется 10МБ на один коннект и со стороны клиента тоже надо держать коннект и тратить уже свою память (размер зависит от конкретной реализации конкретного клиента)

P.S. зачем вам столько соединений? Обычно достаточно одного соединения одному клиенту. И если у вас просто back, то ему хватит одного коннекта

Comments

[orbit070]

Похоже я не очень понимаю смысл соединений.
Вот допустим взять любой мессенджер. Если двое пользователей общаются, это не значит что каждый из них занял по одному соединению?
Или чат с 10-ью пользователями не означает, что занято 10 соединений?

Просто хочу понять, сколько ресурсов нужно на поддержание примерно 1000 пользователей онлайн.

[Fixid]

orbit070, на 1000 пользователей надо равно 1 коннект и немного больше при определенных ситуациях.
Чат проходит через back которому надо ровно одно соединение с базой. А вот уже для http/socks соединения с back надо по одному соединению

[orbit070]

Fixid, большое спасибо