| 큐브리드버젼 | |
|---|---|
| 사용환경(OS) |
안녕하세요
큐브리드로 서버를 구성하고 있는데요
스트레스테스트를 하는 중인데
쿼리 응답이 없는 현상이 발생해서 추적을 하다보니
cci_execute()함수에서 lock이 걸리는 증상을 발견했습니다
현재 테스트에 사용되는 쿼리는 select와 update만 사용하고 있습니다
무한루프를 돌면서 쿼리를 날리는데요 몇 분 정도 돌리다 보면 발생합니다
특정한 부분에서만 발생하는것이 아니라 원인을 찾기가 힘든데요
루프 안에서 하나의 트랜잭션에 사용하는 함수들은
cci_prepare
cci_get_result_info
cci_bind_param
cci_execute <-- 여기서 lock
cci_close_req_handle
cci_cursor
cci_fetch
cci_get_data
cci_close_req_handle
cci_end_tran
입니다
혹시 cci_execute가 중복 실행되는 부분이 있나해서
윈도의 CRITICAL_SECTION으로 cci_execute를 중복호출하지 않게 Lock, Unlock을 사용해서 테스트 해봐도
여전히 발생을 하는데요
참고로 7.3, 2008 둘 다 발생합니다
cci_execute에서 lock걸렸을 때 지정된 시간이 지나면 풀린다던가 하는 옵션이 있나요?
lock이 걸릴 만한 상황이 어떤 상황이 있나요?
문제가 발생했을 때 큐브리드 메니저로 확인해 볼만한 사항이 있나요?
그럼 답변 부탁드리겠습니다
큐브리드로 서버를 구성하고 있는데요
스트레스테스트를 하는 중인데
쿼리 응답이 없는 현상이 발생해서 추적을 하다보니
cci_execute()함수에서 lock이 걸리는 증상을 발견했습니다
현재 테스트에 사용되는 쿼리는 select와 update만 사용하고 있습니다
무한루프를 돌면서 쿼리를 날리는데요 몇 분 정도 돌리다 보면 발생합니다
특정한 부분에서만 발생하는것이 아니라 원인을 찾기가 힘든데요
루프 안에서 하나의 트랜잭션에 사용하는 함수들은
cci_prepare
cci_get_result_info
cci_bind_param
cci_execute <-- 여기서 lock
cci_close_req_handle
cci_cursor
cci_fetch
cci_get_data
cci_close_req_handle
cci_end_tran
입니다
혹시 cci_execute가 중복 실행되는 부분이 있나해서
윈도의 CRITICAL_SECTION으로 cci_execute를 중복호출하지 않게 Lock, Unlock을 사용해서 테스트 해봐도
여전히 발생을 하는데요
참고로 7.3, 2008 둘 다 발생합니다
cci_execute에서 lock걸렸을 때 지정된 시간이 지나면 풀린다던가 하는 옵션이 있나요?
lock이 걸릴 만한 상황이 어떤 상황이 있나요?
문제가 발생했을 때 큐브리드 메니저로 확인해 볼만한 사항이 있나요?
그럼 답변 부탁드리겠습니다
2010.02.06 22:52:23
안녕하세요.
올려주신 상황만으로는 정확히 파악하기가 어렵습니다. 우선 사용하신 질의하고, 에러메세지를 올려주시면 감사하겠습니다.
혹, 가능하시다면 테스트 프로그램도 올려주시면 더욱 감사하겠습니다. 비밀글로 올려주시면 저희만 볼 수 있읍니다.
보통 lock 관련 에러(locktimeout) 이 발생하면, 이미 lock 상황은 정리되었을 수 있습니다. 즉, locktimeout 은 lock 이 풀리기를 기다리다 locktimeout 시간이 지나면 기다리기를 포기하고 나오면서 보여주는 에러이기 때문에 그렇습니다.
올려주신 상황만으로는 정확히 파악하기가 어렵습니다. 우선 사용하신 질의하고, 에러메세지를 올려주시면 감사하겠습니다.
혹, 가능하시다면 테스트 프로그램도 올려주시면 더욱 감사하겠습니다. 비밀글로 올려주시면 저희만 볼 수 있읍니다.
보통 lock 관련 에러(locktimeout) 이 발생하면, 이미 lock 상황은 정리되었을 수 있습니다. 즉, locktimeout 은 lock 이 풀리기를 기다리다 locktimeout 시간이 지나면 기다리기를 포기하고 나오면서 보여주는 에러이기 때문에 그렇습니다.
첫페이지
이 현상이 발생했을 때 lockdb로 출력한 결과 lock이 걸린 상황은 아닌 것 같습니다
*** Lock Table Dump ***
Lock Escalation at = 100000, Run Deadlock interval = 1
Transaction (index 0, (unknown), (unknown)@(unknown)|-1)
Isolation REPEATABLE CLASSES AND READ UNCOMMITTED INSTANCES
State TRAN_ACTIVE
Timeout_period -1
Transaction (index 1, cub_cas, DBA@duyoungk-PC|7648)
Isolation READ COMMITTED CLASSES AND READ UNCOMMITTED INSTANCES
State TRAN_ACTIVE
Timeout_period -1
Transaction (index 2, lockdb, dba@duyoungk-PC|9680)
Isolation READ COMMITTED CLASSES AND READ UNCOMMITTED INSTANCES
State TRAN_ACTIVE
Timeout_period -2
Object Lock Table:
Current number of objects which are locked = 0
Maximum number of objects which can be locked = 10000
브로커의 쿼리 로그를 봤을 때도 마지막으로 남은 로그에는 end_tran COMMIT이 수행되어 있습니다