Отладка Postgres «слишком много уведомлений в очереди NOTIFY»
Я использую таблицу Postgres, которая получает 2000-3000 обновлений в секунду. Я использую для обновления этой таблицы запросы, созданные с помощью помощника по обновлению библиотеки pg-promise.
Каждое обновление вызывает уведомление с помощью функции pg_notify(). Некоторые сценарии nodejs обрабатывают эти уведомления. По какой-то причине в журналах Postgres продолжают появляться сообщения «слишком много уведомлений в очереди NOTIFY», а также указание о размере очереди уведомлений, который продолжает увеличиваться до 100%. Я прочитал несколько постов типа: https://postgrespro.com/list/thread-id/1557124 или https://github.com/hasura/graphql-engine/issues/6263 но я не могу найти способ отладить эту проблему. Как правильно поступить в этой ситуации?
Да, я читал это, но мне не очень понятно, что означает «еще не обработано всеми сеансами прослушивания -». Я использую событие «уведомление» реализации pg-node, насколько я понимаю, каждый раз, когда это событие запускается, уведомление обрабатывается.
Ваша проблема связана не с библиотекой или даже средой NodeJS, а строго с сервером, поэтому вам нужно подходить к этому соответственно — либо путем изменения стратегии уведомлений, либо стратегии обновления/объема, либо даже отслеживать размер очереди с помощью функция в документации.
Ответы 2
Ваш слушатель, кажется, не потребляет уведомления достаточно быстро, или, возможно, не потребляет вообще. Таким образом, первым шагом будет что-то вроде регистрации обработки каждого уведомления из кода вашего приложения, чтобы выяснить, что на самом деле происходит.
что вы имеете в виду под потреблением? Я использую событие уведомления библиотеки pg-node, поэтому каждый раз, когда запускается уведомление, оно запускает обратный вызов, в котором я что-то делаю.
pg_notify вызывается в триггере таблицы при обновлении. Вы предлагаете мне где-то регистрировать каждый вызов pg_notify и сравнивать этот журнал с журналом, созданным обратными вызовами событий уведомлений. ХОРОШО. Будет ли это делать? А что делать, если некоторые уведомления пропали?
«поэтому каждый раз, когда срабатывает уведомление, он вызывает обратный вызов, когда я что-то делаю». Да, это то, что вы хотите. Работает? Откуда вы знаете?
Большинство из них рабочие. Я не мог знать наверняка, потому что все это выглядит так, как и ожидалось. Единственная досада — это неконтролируемый рост размера очереди. Вы говорите, что некоторые события уведомлений не срабатывают? Что может быть причиной? Я проверю это, регистрируя как уведомления, так и инициированные события уведомлений.
Это может быть связано с тем, что существует длительная транзакция, которая блокирует выпуск старых сообщений из буфера. Этот процесс описан в руководствах и чем-то похож на очистку — старые транзакции должны быть завершены, чтобы очистить старые данные.
Суть в том, что любой длительный запрос может задержать очистку; для меня это был процесс, который запускал Listen — он был разработан, чтобы просто продолжать работать вечно. В журнале сервера PG есть внутренний PID, который может быть виновником, поэтому вы можете найти его в pg_stat_activity и продолжить оттуда.
PostgreSQL документирует это — см. Примечания.