Блокировка неактивных соединений в ClientRead для параметризованных запросов (привязок) во время большого трафика - PullRequest
1 голос
/ 11 июня 2019

Я ищу хорошее решение для моей проблемы, которая возникает во время пиковых нагрузок. Я использую postgres на AWS с nodejs (knex для запросов) - подробности ниже.

Когда я смотрю на Performance Insights в моей консоли RDS, я вижу, что некоторые из запросов зависают в ClientRead. Мои экземпляры RDS довольно велики, а загрузка процессора очень низка (1% -10%). Таким образом, я подтвердил это, подключившись к базе данных и запустив запрос для pg_stats, и в результате я увидел, что многие запросы бездействуют в событии ClientRead.

Что связывает эти запросы? Наручники. Я предполагаю, что эти параметризованные запросы ждут получения значений из моих экземпляров EC2. Я думал, что мои службы работают слишком медленно, поэтому я увеличил количество экземпляров, но результаты на RDS были хуже, и было заблокировано больше соединений.

Для тестирования решения я преобразовал несколько запросов из параметризованных в необработанные SQL-запросы без привязок (со значениями непосредственно в запросе). И эти запросы точно были выполнены сразу же без каких-либо проблем. Но, похоже, это не идеальное решение, даже если по соображениям безопасности.

В настоящий момент я понятия не имею, где проблема? Должен ли я уменьшить трафик путем добавления регулирования на API GW? Создавать внутренние очереди в моем сервисе? Это проблема со связью или настройки моего RDS / postgre?

Если у кого-то больше опыта в подобных случаях или есть возможность указать на вероятное решение, обратитесь к документам, которые могут мне помочь, или определите, где проблема, было бы здорово.

AWS RDS (Аврора) Postgres 9.6.9 nodejs 10.12.0 knex 0.17.3 node-postgres 7.4.1

1 Ответ

0 голосов
/ 11 июня 2019

Если ваша база данных заблокирована в ожидании ClientRead, это означает, что база данных ожидает запросов от клиента.

Запросы, которые вы видите, не являются запросами. Если state не является active, query содержит оператор SQL last , который был выполнен для этого соединения с базой данных.

Если у вас возникли проблемы с производительностью, причина, по-видимому, находится за пределами базы данных.

...