OpenVOS 운영 체제는 전체적으로 시스템을 프로그래밍할 수 있는 높은 수준의 응용 프로그램 프로그래밍 인터페이스(API)를 제공합니다. 그러나 때로는 너무 쉬워집니다 - 간단한 서브 루틴 전화가 $... 루틴은 복잡성을 많이 숨길 수 있습니다. 사용자는 때때로 간단한 호출이 많은 작업을 초래할 수 있으며 시스템 및 응용 프로그램에 문제가 발생할 수 있다는 것을 깨닫지 못합니다.
이것은 당신이 당신의 응용 프로그램 디자인에서 피할 수있는 함정에 주의를 호출하는 게시물의 불규칙한 시리즈의 두 번째입니다.
서버 대기열에 대한 list_messages 악
OpenVOS의 list_messages 명령은 OpenVOS의 트랜잭션 보호 제품의 일부인 큐와 함께 사용됩니다. OpenVOS에 대한 StrataDOC는 이 명령이 "지정된 큐의 메시지에 대한 정보를 표시"하는 것을 표시합니다. 따라서 큐가 프로덕션 환경에서 백업을 시작할 때 이 명령을 사용하여 큐에 있는 메시지 수를 찾아보려는 유혹을 받을 수 있습니다. -totals_only 옵션은 필요한 것과 같습니다. 이 명령의 작동 방식을 이해하면 이것이 좋은 선택이 아닌 이유를 이해할 수 있습니다.
list_messages 명령의 작동 방식
명령은 파일에 포트를 연결하고 포트를 SERVER_TYPE(또는 단방향 서버 큐의 RECV_ONLY_SRV_TYPE)로 열고 no_wait_mode 넣습니다. 큐가 트랜잭션이 보호되면 명령이 우선 순위 -1에서 트랜잭션을 시작하여 경합이 있는 경우 항상 손실되며 작업이 완료되면 s$abort_transaction 호출됩니다.
다음으로 큐의 첫 번째 레코드에서 시작하여 s$read_msg 호출하고 수신할 수 있는 모든 레코드를 계산한 다음 레코드를 출력 포트에 카운트 및/또는 덤프합니다.
각 메시지에 대한 정보를 표시하려면 메시지를 보낸 모듈 및 프로세스에 대한 정보를 조회해야 합니다.
마지막으로 큐에서 찾은 레코드에 대한 합계를 인쇄합니다.
이러한 접근 방식의 문제
이 명령은 응용 프로그램 개발 프로그래머가 메시지가 큐에 있는 동안 메시지를 보고 메시지가 제대로 포맷되고 적절한 필드가 포함되어 있는지, 서버에서 받았는지 여부 등 올바른 우선 순위로 큐에 대기하는 데 사용되었습니다. 그러나 명령을 다른 용도로 사용할 때 많은 제한 사항과 숨겨진/오해의 소지가 있는 데이터가 있습니다.
- 큐에서 메시지에 대한 정보를 얻으려면 메시지에 대한 액세스를 실행, 읽기 또는 작성해야 합니다. 큐에 대한 액세스를 실행하거나 읽은 경우 메시지에 대한 정보만 얻을 수 있습니다. 쓰기 액세스 권한이 있는 경우 모든 메시지에 대한 정보를 얻을 수 있습니다.
- 큐가 서버 큐인 경우 list_messages 서버에서 아직 응답하지 않은 메시지만 나열합니다. 회신되었지만 아직 큐에서 삭제되지 않은 메시지는 msg_receive_reply.
- 큐가 가득 max_queue_depth 찼고 더 이상 새 메시지를 수락하지 않을 수 있지만 모든 메시지가 수신되지 않은 경우 list_messages 큐에 메시지가 없는 경우 메시지가 표시되지 않을 수 있습니다.
- list_messages 명령은 메시지를 검색하는 동안 큐의 서버로 나타나므로 큐를 서비스하는 서버 수에 대한 클라이언트 및 기타 제어 프로세스를 속일 수 있습니다.
- 요청자가 다른 모듈에 있는 경우 요청자 프로세스에 대한 모듈 및 프로세스 정보를 검색하려면 네트워크 트랜잭션이 필요할 수 있습니다.
- 각 메시지에는 메시지를 읽기 위해 커널로 이동해야 합니다. 큐를 소유한 모듈에서 명령이 실행되지 않으면 각 메시지를 읽는 네트워크 트랜잭션이 필요합니다.
- –totals_only 지정되더라도 각 메시지를 계산하려면 읽어야 합니다.
- -totals_only 표시되는 값은 서버에 대해 대기중이거나 서버에서 처리중인 메시지에 대해서만 표시됩니다. 큐에 남아 있는 양방향 서버 큐 메시지에 대한 수신되지 않은 회신에 대한 정보가 표시되지 하므로 -totals_only 값이 오해의 소지가 있습니다.
- 메시지의 데이터는 중요한 정보(예: 신용 카드 계정 번호)일 수 있습니다.
다른 방법
1990년에는 s$get_server_queue_info 새로운 API가 제공되었습니다. 큐의 경로 이름을 감안할 때 이 루틴은
- server_queue 종류(편도 또는 양방향)
- 메시지 수
- 비사용 메시지 수
- 메시지 수가 가장 많은 메시지
- 처리된 총 메시지 수입니다.
- 이 큐에 대해 구성된 최대 메시지 수(max_queue_depth)입니다.
list_messages 이 루틴에는 많은 장점이 있습니다.
- 총 정보를 검색하기 위해 커널 및/또는 네트워크를 통해 한 번의 여행.
- 아직 받지 못한 답장을 포함하여 모든 종류의 메시지를 고려합니다.
- 큐의 중단이 없습니다. 큐 헤더는 마이크로초 동안 잠겨 있으며, 큐 헤더에서 5개의 카운터로 일관된 세트를 얻을 수 있을 만큼 길다.
- 큐를 요청자로 열 때 정보를 얻을 수 있습니다.
check_queue_depth 명령
몇 년 전 나는 check_queue_depth 썼다, 이 인터페이스를 사용 하 여 하 고 하나 이상의 큐에 대 한이 정보를 표시 하는 데 사용할 수 있습니다.
check_queue_depth 큐 [-warn_percent 번호] [간격 번호]
【user_name 통보】 【-간략한 설명】 【롱】
[-ignore_invalid_type] 【-시저】
[-exit_after_warning]
명령의 소스 코드는 Stratus 공용 FTP 사이트에서 사용할 수 있습니다.
- 문서 http://ftp.stratus.com/vos/perf/check_queue_depth.txt
- 소스 코드 http://ftp.stratus.com/vos/perf/check_queue_depth.pl1
자유롭게 사용하거나, 향상시키고, 자신의 응용 프로그램 모니터링 명령에 포함하십시오.