вижу медленный запрос 2-3 секунды, от приклада на Java. Беру этот запрос и выполняю, под тем же пользователем, в консоли, отрабатывает за десятки миллисекунд. План запроса - нормальный, читает всего 36 буферов. ЦПУ и диски при этом не загружены, от слова - совсем. Версия PostgreSQL 13.2
Кто сталкивался с подобным, в какую сторону смотреть?
сторону idle in transaction и в сторону настроек либы для джава в части какой тип запроса (подготовленный или обычный)
idle in transaction нет, ни мониторинг не ловил, ни глазами не видел. Запрос обычный
тогда включить auto explain и смотреть в логах план запроса
Решил использовать это, как крайний вариант. Но видимо, прейдется ( Спасибо
А можете этот бекенд опознать и попрофилировать?
может результат приложением медленно вычитывается ?
кстати да. у нас аппки на джаве троттлили получение данных от СУБД, потом разработчики поправили этот момент чтобы сразу все данные принять и запрос завершался быстро. Но пока шло получение - транзакция была открыта. Поэтому я и спрашивал - нет ли idle in trx
Недавно столкнулись с проблемй СХД под виртуалкой. иногда чтение могло становиться аномально длинным (даже для 1 страницы было примерно 3 секунды). Смогли точно определить только после получения настоящего эксплейна с IO таймингами
Была тая мысль, но у таких запросов wait_event пустой. Получается, что они ничего не ждут (
тут может быть даже в троттлинге дело а в том что ридер результатов например неосторожно положили в очередь для обработки и он там висит сколько то времени пока его не вычитают и не закроют. Плохая практика, больше похожа на баг
а есть возможность выполнить запрос в консоли на ещё не запрошенных данных - запрос параметризованный? Подобрать параметры чтобы они захватывали ещё ни разу не прочитанных данных и отсутствующих в кэше PG
Да, пробовал. Время на чтение с диска ничтожное, ~13 мс
Обсуждают сегодня