Пул соединений и производительность

Клиент драйвера держит пул соединений к каждому серверу отдельным хозяйством: операция берёт коннект из пула, выполняет команду и возвращает его обратно. Дефолтный потолок — сто соединений на сервер: параметр maxPoolSize, а ноль означает отсутствие лимита. Когда потолок достигнут, новые операции не разворачиваются и не падают — они блокируются в очереди до освобождения коннекта или до дедлайна своего контекста. Отсюда простая арифметика пропускной способности: сто коннектов и операция в пятьдесят миллисекунд дают около двух тысяч операций в секунду на сервер, а тот же пул с операциями по секунде — сотню. Рядом живут три настройки, которые дополняют потолок. minPoolSize поддерживает минимальный запас готовых коннектов: по умолчанию ноль, и фоновая горутина клиента подогревает запас, если его опустошили. maxConnecting ограничивает, сколько рукопожатий устанавливается одновременно, — по умолчанию два, чтобы всплеск нагрузки не обрушил на сервер сотню параллельных подключений. Сердцебиение в десять секунд держит карту живости серверов свежей, а connectTimeout ограничивает установку одного соединения тридцатью секундами. Все пять параметров задаются через options.Client() при создании клиента, и менять их стоит осознанно: дефолты подобраны так, чтобы обычный сервис не трогал их вовсе.

Очередь за коннектом имеет предел — дедлайн контекста операции. Если все сто коннектов заняты, а контекст истёк раньше, чем кто-то вернул свой, операция получает WaitQueueTimeoutError с текстом «timed out while checking out a connection from connection pool»: внутри сидит причина из контекста, а предикат IsTimeout из урока про ошибки возвращает на него true. Кто держит коннекты долго? Незакрытый курсор: Find возвращает соединение в пул только после исчерпания всех батчей или явного Close — горутина, прочитавшая первую страницу и вышедшая по return, утащила коннект навсегда. Долгая агрегация и транзакция держат коннект на всё время работы. Симптом исчерпания характерен: сервис здоров, но с некоторого момента каждая операция начинается с миллисекунд ожидания, потом сыплются таймауты с текстом про connection pool, хотя сама база отвечает мгновенно. Похожую картину даёт и сетевой сбой: пул после ошибки соединения чистится и наращивается заново, и кратковременный провал пропускной способности после каждого обрыва — нормальное поведение, а не отдельная поломка. Диагноз ставится событиями пула, о которых дальше, а лечение всегда одно: найти того, кто держит коннекты, а не растить потолок.

У пула нет метода вроде Stat с готовыми счётчиками — сравнить с пулом pgx не получится, и это честно задокументировано архитектурой драйвера. Наблюдение строится на событиях: options.Client().SetPoolMonitor принимает PoolMonitor, чей колбэк вызывается на каждое событие жизненного цикла соединений. Полезные типы: ConnectionCheckedOut и ConnectionCheckedIn — взятие и возврат коннекта, ConnectionCheckOutFailed — операция не дождалась соединения, с полем Reason и ошибкой контекста, ConnectionCreated и ConnectionClosed — рождение и смерть коннекта. Каждое событие несёт адрес сервера и длительность, поэтому пары CheckedOut и CheckedIn дают живую картину: сколько коннектов занято прямо сейчас, сколько операций ждало и на чём именно. На графах обычно достаточно трёх серий: занятые коннекты, время ожидания коннекта и число CheckOutFailed — последняя серия обязана быть нулевой, и каждая единица там — будущий таймаут в хендлере. Рядом стоит SetMonitor для команд: CommandSucceededEvent и CommandFailedEvent приходят на каждую команду с полем Duration — готовый материал для замера p95 без внешних агентов. Оба монитора ставятся при создании клиента и пишут в вашу метрику одной строкой кода.

Пул — транспорт, а тормоза живут в плане запроса. Скан коллекции читает все документы подряд, ход по индексу — только нужные записи дерева: именно эту разницу делает CreateOne из урока про индексы. Проверяется она explain: команда explain оборачивает ваш запрос и с параметром verbosity executionStats возвращает, что сервер делал на самом деле. Ключевые поля лежат в executionStats: nReturned — сколько документов вернулось, totalDocsExamined — сколько прочитано, totalKeysExamined — сколько записей индекса перебрано, executionTimeMillis — время в миллисекундах. Здоровый запрос читает близко к тому, что возвращает: examined примерно равен returned. Особый случай — покрытие: когда все нужные поля лежат в индексе, totalDocsExamined падает до нуля, и сервер вообще не заглядывает в документы. Запрос, который на десяток строк перечитал миллион документов, — кандидат на индекс или на перестройку фильтра. Опцию SetHint можно принудить запрос к конкретному индексу, когда планировщик промахивается, а compound-индексы проектируются по правилу равенство, сортировка, диапазон — все эти буквы живут в уроке про индексы. С таймингами в v2 проще, чем в v1: отдельных опций maxTime у операций нет, дедлайн берётся из контекста, а клиентский SetTimeout уезжает на сервер как maxTimeMS сам.

Конвейер агрегаций стоит ровно столько, сколько данных через него проехало. Первое правило из базового урока агрегаций — $match первым: до группировки сервер опирается на индексы, после — фильтрует уже свёрнутые итоги. Второе — отсекать объём как можно раньше: $limit и $project перед тяжёлыми этапами уменьшают и число документов, и ширину каждого, а сортировка с лимитом после сужения — дешевле той же сортировки по всей выборке. Третье — помнить потолки: память этапа ограничена сотней мегабайт, а документ — шестнадцатью, и длинный $push добирается до обоих; SetAllowDiskUse разрешает выгрузку на диск, но это не ускорение, а возможность долететь — обмен с файлами медленнее памяти. Четвёртое — не считать в Go то, что считает сервер: выкачивать сырые документы циклом и суммировать в приложении — значит перекачивать сеть и держать коннекты дольше необходимого. Размер батчей курсора регулируется SetBatchSize: крупные батчи экономят поездки, мелкие — память; для панельных отчётов обычно достаточно дефолта. Все эти приёмы не требуют ничего, кроме перестановки этапов, — самая дешёвая оптимизация из возможных.