Hibernate, MS-SQL 서버 교착상태 방지..

하이버네이트의 LazyLoding 을 최대한 공격적으로 사용하고..
OSIV (Open session in view)를 이용했더니..

워낙에 복잡하게 얽힌 클래스의 관계구조로 인해 사용자가 많이 몰릴경우 DB에서의 응답시간이 1ms에서 어느순간 600ms로.. 그다음은 8000ms로 늘어나면서 사이트가 먹통이 되는 현상이 발생했다..

더 미치는건.... 같은 프레임이 다른 DBMS를 사용하면 정말 짱짱하게 돌아간다는것.... OTL

DB에서 응답이 없는건 거의 교착상태...(정말 십중팔구는 교착상태이다...)
하지만 이미 운영에 들어간 사이트에 부하가 심하게 걸리는 감사를 활성화시키기에는 무리가 있고.. (실제로 켰더니.. 느리다고 바로 연락이.....)

의도적으로 해당 현상을 발생시키는것도 한계가 있고...

-- 활성화된 트랜잭션 보기.
DBCC OPENTRAN;

해당 문제가 발생했을때... 이 명령으로 현재 활성화되서 자원을 잠금상태로 유지하는 세션정보를 조회할 수 있다.... 하지만 너무 늦게 알았다... 사이트다운이 한두번만 더 생기면.. 신뢰도 급하락이다... 마냥 다운된상태에서 문제점을 찾겠다고 뒤지기엔... 해당 명령을 너무 늦게 알았다... DB도 좀 공부를 해야 하는데...

근본적인 해결책은 아니지만... 잠금시간에 대한 제한시간을 두는것도 좋은 방법이다. 사이트가 무조건 먹통이 된 상태로 문제 해결하겠다고 붙잡고 있을 수도 없는 상황이니...

-- 잠금 제한시간 보기.
SELECT @@LOCK_TIMEOUT;

요렇게 날리면 기본값이 -1이다.. 즉..... 무제한... ㅎㄷㄷ

-- 잠금 제한시간 설정.
SET LOCK_TIMEOUT 2400;

단위가 ms라고 한다. 2초이내에 응답을 안하면... 이건 문제가 있는거니까.. 조금 더 여유를 줘서 2400ms로 설정해두었다..

이제 남은건 클라이언트에서 동일한 문제로 다시 연락이 오는지 기다려 보는것..

의도적으로 사이트 스트레스를 통해서 교착상태에 빠지는 대상 엔티티를 찾는것도 물론 병행해서 근본적인 원인을 수정하는게 물론 정답이다....