문제 : linux centos 환경에서 돌아가는 java application이 있다. 2종류의 thread를 돌린다.
1. 통신 선로로부터 data packet을 체크하여 해당 패킷을 분류 DB의 테이블에 입력함. 1개의 thread 존재
2. db를 체크하여 설정된 에러의 interval time을 계산 하여 초과할경우 에러 메일 송신 . 20초마다 thread생성.
하지만 에러 메일이 송신되지 않는 경우가 있어 thread를 분석해본 결과 2가지 문제점 발견
1. thread의 로직에서 회복 flag를 제대로 회복시키지 못하는 경우가있었음.
두번째가 예상치 못한 문제점이었는데
2. 에러 체크 thread에서 db에서 데이터를 얻어올때 access delay가 발생 할 경우
(*같은 DB를 통해 통계를 내는 웹페이지가 존재하기때문에 140만건 이상의 테이블로 접속할경우
db로 부하가 걸릴때가 있다.)
20초를 넘어서는 딜레이의 경우는 동시에 thread가 생성되어 같은 메일을 보내거나 같은 에러 회복을 하는
경우가 있었다.
1번의 문제는 flag체크 로직을 개선하여 해결했지만
2번 문제는 꽤나 난감했다.
먼저 db에 접속전 접속후의 acess delay를 체크하여 로그기록을 남겨 나중에 확인하도록 수정한 뒤에
web쪽의 db query로직을 개선하여 속도를 올려 조금 의 속도 개선을 하였지만,
완전이 해결된게 아니기에 thread의 생성시간을 늘리고 db 체크 인터벌 시간을 상향조정했다.
1. 통신 선로로부터 data packet을 체크하여 해당 패킷을 분류 DB의 테이블에 입력함. 1개의 thread 존재
2. db를 체크하여 설정된 에러의 interval time을 계산 하여 초과할경우 에러 메일 송신 . 20초마다 thread생성.
하지만 에러 메일이 송신되지 않는 경우가 있어 thread를 분석해본 결과 2가지 문제점 발견
1. thread의 로직에서 회복 flag를 제대로 회복시키지 못하는 경우가있었음.
두번째가 예상치 못한 문제점이었는데
2. 에러 체크 thread에서 db에서 데이터를 얻어올때 access delay가 발생 할 경우
(*같은 DB를 통해 통계를 내는 웹페이지가 존재하기때문에 140만건 이상의 테이블로 접속할경우
db로 부하가 걸릴때가 있다.)
20초를 넘어서는 딜레이의 경우는 동시에 thread가 생성되어 같은 메일을 보내거나 같은 에러 회복을 하는
경우가 있었다.
1번의 문제는 flag체크 로직을 개선하여 해결했지만
2번 문제는 꽤나 난감했다.
먼저 db에 접속전 접속후의 acess delay를 체크하여 로그기록을 남겨 나중에 확인하도록 수정한 뒤에
web쪽의 db query로직을 개선하여 속도를 올려 조금 의 속도 개선을 하였지만,
완전이 해결된게 아니기에 thread의 생성시간을 늘리고 db 체크 인터벌 시간을 상향조정했다.