그 알 수 없는 조건이 혹 DB 서버 기준으로 여러 동시에 쿼리를 실행하는 세션 수가 많아지면서 발생한 것이라면, 동시 쿼리 처리 능력의 한계로 보면 될 것 같습니다.

그 외 나머지 상황은 그 때 그 상황을 종합적으로 판단하지 않으면 답을 찾아내기 힘든 부분입니다. 간헐적 네트워크 장애일 수도 있고, OS 차원의 디스크 읽기 쓰기의 잠깐 멈춤일 수도 있고, 온갖 경우가 있어 뭐라고 하기 힘든 상황이네요.

jdbc가 의심이 되면 jdbc를 바꿔서 확인해 보시고요. 일반적으로 jdbc 커넥션의 속성 가운데, prepareThreshold , preparedStatementCacheQueries 이런 속성들이 0이 아니여서 jdbc 차원에 캐시와 서버 차원의 prepare를 쓰겠끔 되어있어 이 부분의 문제일 수도 있습니다.

https://jdbc.postgresql.org/documentation/head/connect.html

 답변 감사드립니다.

이유를 확실히 알았습니다. 댓글보기 전에 이미 jdbc 버전도 바꿔서 해봤고 여러 시도를 해봤는데

콘솔이나 pgadmin에서는 빠른데 어플리케이션에서 느린 이유는 바인딩 변수 때문이었습니다.

콘솔에서는 상수값으로 넣었기 때문에 빠르게 나왔는데 psql 커맨드에서 직접 prepare을 만들고

바인딩 변수를 주었더니 성능이 확 떨어지고 말았습니다. 스택오버플로우에서 이러한 사례가 있어서

지금 찾아보는 중인데 혹시 이에 대한 경험이 있으시면 나눠주시길 부탁드립니다.

(참고로 개발 중인 상황에서 성능이 떨어진 문제이기 때문에 세션 수의 문제는 아니었습니다.)

 조회하는 부분이 pg 사용자 함수로 만드셨나요? 아니면 자바 소스에 쿼리?

 JPA를 사용하고 있는데 orm.xml에 네이티브 쿼리로 작성하였습니다. 순수 sql입니다.

아래는 바인딩 변수 사용 시 뜬 실행계획입니다.

product_term을 풀스캔해서 왕창 버리는 비효율은 있긴 합니다만 전체적으로 느린 성능을 보여주지는 않습니다.

이해가 안되는것은 빠르게 나오다가 한순간에 먹통이 되는 현상입니다.

pg사용자 함수로 조회부분 바꿔서 테스트 해보시구요.

아니면  pg_stat_statements 추가 하셔서 점검 해 보셔도 될듯

조회 목록에 실행횟수(calls)하고 실행 시간 등등 정보 많으니 쿼리 재사용 하는지 보세요.

jpa라....db에게는 pg함수 아니면 그냥 ad-hoc쿼리일뿐입니다.  

-----------------------------------------------------

CREATE EXTENSION pg_stat_statements;  

postgresql.conf 설정화일을 아래와 같이 수정후 PostgreSQL 을 restart 합니다.

맨앞에 #을 지워야 적용됨.

.....

shared_preload_libraries = 'pg_stat_statements'

pg_stat_statements.max = 10000

pg_stat_statements.track = all

SELECT query, calls, total_time, rows, 100.0 * shared_blks_hit / nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent FROM pg_stat_statements ORDER BY total_time DESC LIMIT 5;

https://explain.depesz.com/

PostgreSQL실행 계획 공유는 위에 사이트로 해주세요~

의심했던 부분이 맞을 것 같네요.

커넥션 데이터 소스 만드는 부분에 connection url 부분에

윗 두 설정값을 0으로 해서 jdbc 차원의 캐시와 서버 prepare를 쓰지 않는다고 해서 지정해 보세요.

jdbc:postgresq://host/db?prepareThreshold=0&preparedStatementCacheQueries=0

 김상기님의 생각이 맞았습니다.

설정바꾸고 나니 성능저하가 사라졌습니다. 사람 하나 구하셨습니다. 감사합니다~

관심가져 주신 지현명님도 감사드려요~

http://pgday.postgresql.kr/

이번주 토요일 PostgreSQL 사용자 그룹에서 PG행사가 있습니다. 

오셔서 질문해 주세요~ 김상기님이 답변 잘해 주십니다.

 --------------

pg_stat_statements 익스텐션 추가하셔서 orm jpa가 던지는 ad-hoc쿼리 살펴보세요

어떤짓(?)하는지 orm은 끝까지 감시해야 합니다.

말씀해주신 익스텐션을 설치해서 확인해보겠습니다.

그런데 orm에서 날아간 쿼리는 이미 알고 있습니다. 로깅을 찍어보면 실제 생성되서 날아간

쿼리는 확인이 가능하거든요. 그리고 위에서 말씀드린 것처럼 jpql이나 그래프 탐색을 통해

만든 쿼리가 아니고 제가 직접 만든 네이티브 쿼리였습니다. 그렇기 때문에 jpa와는 전혀

무관한 문제였습니다. 관심가져주셔서 감사드립니다.