Мы наткнулись на странный сложновоспроизводимый баг где-то в глубине библиотеки Ascynpg (асинхронная библиотека для работы с БД postgres), из-за этого у нас в системе начались утечки памяти, потому что в БД мы хранили реестр аллоцированных участков разделяемой памяти.

Причина состояла в том, что в какой-то момент объекты-соединения (объекты типа Connection) из пула соединений залипали навсегда по непонятной причине. При этом запросов они не выполняли, ничего не делали, а просто висели.

Чтобы разобраться с этим, мы стали смотреть и копать, воспроизводить баг. Но воспроизвести так и не получилось — возникает он довольно редко, в случайном месте в случайное время, поэтому пришлось караулить продовый сервер, и в тот момент когда память начнет утекать, выводить его из прода, подключаться к процессу отладчиком gdb и перелопачивать питоновский garbage collector для поиска причины утечки.

В итоге проблему решили, но изначальную причину внутри либы asyncpg так и не нашли (решилось принудительным прибиванием коннектов, которое влекло за собой создание нового на его месте).

Доклад будет интересен разработчикам, админам и другим людям, кто пользуется python (особенно asyncio), postgres и особенно — либой asyncpg. А также тем, у кого есть доступ на продовые сервера, где крутится питон, и тем, кто считает, что отладку на проде всегда можно избежать.

Из интересного широкому кругу python-разработчиков — можно будет узнать, как отлаживать без использования дополнительных библиотек-отладчиков (стандартными средствами, а именно gdb) уже запущенный процесс, где включен PYTHONOPTIMIZE и нет брекпоинтов в коде. Покажу, какие есть приемы для поиска источника утечки памяти через модуль сборщик-мусора (gc). Расскажу, что с ним можно найти, а что нет.