Не нашел пока проблемы в бд . все кажется только как проблема в алгоритме

всем привет. подскажите один момент. над методом сервиса висит аннотация cacheable/ метод ходит в базу и достает оттуда коллекцию сущностей. сущность связана с другими сущностями, которые грузятся лениво. (соответственно и в кэше не отражаются) при попытке к ним обратиться, закономерно всё падает из-за lazyInit.
ок. над методом репозитория, который дергается, прописал запрос с join fetch, дабы зависимые сущности вытащить. вроде в дебаге все ок. но кэшится все равно без зависимостей. и также падает. в чем может быть проблема?

можно, конечно, просто убрать кэш и каждый раз ходить в базу... но.. это тупое решение

Как анализировали?

Бенчмарки писал, небось

в онлайне смотрел активные запросы в БД, вручную выполняю запросик просмотра активности, если есть плохой запрос, он попадается на глаза обычно,  стандартно вижу почти нулевую утилизацию на уровне ОС. и в statspack тоже ничего не нашел  (хотя там сложно сопоставить запросы с моим кейсом)

на схеме продукта видно 200тыщ выполнений какого то запроса в сумме 108 секунд, выполнение каждого запроса меньше 0.0сек, то есть он быстро выполняется, разве что проблема что часто

Не серьезно, делаешь мониторинг, собираешь метрики системы и базы, смотришь какой ресурс проседает. Это самое простое, у нас Prometheus + grafana, собираем системные метрики через node exporter, с базы postgres exporter

Без такого мониторинга я даже не знаю как мы решали бы большую часть вопросов производительности

А щас как решаете ?

Вот через мониторинг и анализируем

Так какие там метрики которые я линуховыми утилитами в ос не вижу?

Так там все в одном месте с сохранением историчности, можешь конечно датой копать, твое дело)

Основное что смотрим - утилизация cpu со структурой, ожидание io, активная работа. Карта оперативки, кэш, буферы, своп. Дисковый io.

По метрикам пг смотрим статистику выполнения запросов, время, количество, какие запросы больше проблем доставляют

Да, по пг свой дашборд ваяли. За основу брали базовый, сейчас возьмём скоро более подробный и добавим туда свои примочки. Там уже будет отображение локов, ещё куча полезного, те же буферы именно пг

Вот сегодня буквально ускорили пг буквально раза в полтора минимум за счёт анализа и корректировки shared buffers

Ну это Так себе достижение

Выходит настройки некорректные были

Универсальных не бывает, все зависит от данных в базе и запросов, поэтому приходится крутить по результатам работы, для этого и мониторят

Дело твое, использовать или нет