안녕하세요. 맥스클라이언트는 300보다는 크게 잡아야 합니다. 왜냐하면 질의편집기나 매니져에서 접속하는 부분도 있기 때문이며 보통 10 정도 더 잡아주시면 됩니다. 또한 큐브리드 브로커도 설정을 조정하셔야 합니다. 33000번 포트를 이용하여 응용에서 접근하고 있다면 브로커의 설정정보중 broker1 에 대하여 MAX_NUM_APPL_SERVER 의 값을 300으로 맞춰주어야 합니다. 클라이언트가 늘어났다고 해서 죽지는 않습니다만, 어떠한 상황인지 조금더 자세히 알려주시면 감사하겠습니다. 서버가 죽었다면 죽었을 당시의 시간과 에러를 올려주면 감사하겠습니다. 에러는 CUBRID 홈 디렉토리아래 log/server 에 존재합니다. 가장 최근의 화일부터 확인하시면 됩니다.
04/12/10 22:46:47.496 ERROR -76 4 12 Your transaction (index 4, 서버명|29688) timed out waiting on READ on page 9|631. You are waiting for user(s) 서버명|29686 to release the page lock.
답변해 주신 메시지는 lock에 관련한 메시지로 max_client설정과 관련한 메시지는 아닙니다. $CUBRID경로 conf디렉토리 밑에 cubrid.conf파일을 열어 max_client의 값을 310으로 수정하신 후 DB를 재구동 시켜 parameter가 적용되도록 하시기 바랍니다. max_client에 표기되는 숫자는 모든 broker에 있는 MAX_NUM_APPL_SERVER의 총합계 값보다 10정도 많게 하셔야합니다. 위의 lock관련 메시지가 자주 발생한다면 해당 시점에 사용되는 쿼리의 transaction처리나 기타 사용현황에 대해서 모니터링이 필요할 것으로 보여집니다.
가장 좋은 트랜잭션 처리 방법은 lock을 빨리 놓아 주는 것입니다. lock은 동시성 제어를 위해 사용되는 DB의 리소스이며 서로 다른 트랜잭션들이 경쟁하여 lock을 선점하도록 되어 있습니다. 따라서 트랜잭션에 대한 처리를 빠르게 해준다면 lock에 대한 경쟁이 적어들겠죠. 이런 처리를 해주기 위해서 시스템 튜닝 및 DB튜닝등이 필요합니다. 사용자 입장에서 쉬운 튜닝 방법으로는 주기적인 통계정보갱신, 질의튜닝 및 DB처리 완료 후 트랜잭션 종료를 바로 해주는 방법이 있습니다. DB처리 완료 후 트랜잭션 종료의 한 예로는 응용에서 트랜잭선 발생 시킨 후 결과를 fatch한 후 응용에서 연산을 수행한 후 종트랜잭션을 종료하게 될 경우 응용에서 연산하는 시간동안 트랜잭션이 존재하게 되므로 lock이 유지 되므로 fatch 후 바로 트랜잭션으로 종료하여 트랜잭션 관리를 하여야 합니다.
PS. 트랜잭션은 DBMS의 원자성 요소에 의해 Commit/Rollback 에 의해 종료되어 집니다.
맥스클라이언트는 300보다는 크게 잡아야 합니다. 왜냐하면 질의편집기나 매니져에서 접속하는 부분도 있기 때문이며 보통 10 정도 더 잡아주시면 됩니다. 또한 큐브리드 브로커도 설정을 조정하셔야 합니다. 33000번 포트를 이용하여 응용에서 접근하고 있다면 브로커의 설정정보중 broker1 에 대하여 MAX_NUM_APPL_SERVER 의 값을 300으로 맞춰주어야 합니다.
클라이언트가 늘어났다고 해서 죽지는 않습니다만, 어떠한 상황인지 조금더 자세히 알려주시면 감사하겠습니다. 서버가 죽었다면 죽었을 당시의 시간과 에러를 올려주면 감사하겠습니다. 에러는 CUBRID 홈 디렉토리아래 log/server 에 존재합니다. 가장 최근의 화일부터 확인하시면 됩니다.