RPC 요청이 늦게 처리되는 문제 해결
마지막으로 수정된 항목: 2008-11-12
Microsoft Office Outlook을 MAPI 모드에서 사용하면 Outlook에서 클라이언트 작업을 클라이언트와 서버 간의 RPC(원격 프로시저 호출)로 실행합니다. 사용자가 온라인 모드에서 실행하는 경우에는 이러한 RPC 호출이 동시에 발생합니다. 서버에서 이러한 동시다발적 요청을 수행할 때 지연이 발생하면 사용자 경험과 Outlook 응답에 직접적인 영향을 미칩니다. 이와 달리 캐시 모드에서 실행할 때에는 수행되는 대부분의 작업이 사용자의 사서함 로컬 복사본에 대해 발생하거나 비동기(백그라운드) RPC 형태로 서버에 보내집니다. 일반적으로 비동기적 RPC는 Outlook 클라이언트 자체에 대한 전반적인 경험이나 응답에 영향을 주지 않습니다.
Microsoft Exchange 정보 저장소 서비스가 서버에서 처음 시작되면 RPC 서비스에 등록된 다음 500개의 RPC 스레드를 할당받습니다. 클라이언트는 일별 작업을 수행하면서 개별 스레드에 대한 연결을 만들고 연결을 해제합니다. 이 작업에는 전자 메일 읽기 및 보내기, 약속 및 작업 만들기 및 일정 보기 등이 있습니다. MSExchangeIS\RPC Requests 성능 카운터는 현재 사용 중인(클라이언트에 의해 "소유된") 스레드 수를 나타냅니다. MSExchangeIS\RPC Operations/sec 성능 카운터는 서버가 마지막 1초 동안 받은 작업 수를 나타냅니다. 따라서 RPC 요청 수가 지속적으로 늘어나는 경우에는 서버에서 클라이언트 작업을 신속하게 처리할 수 없습니다. MSExchangeIS\RPC Requests 성능 카운터가 500에 도달하면 모든 RPC 스레드가 소모되었으므로, 기존 스레드의 모든 작업이 완료된 후 해당 스레드가 해제될 때까지 클라이언트가 서버에 새 요청을 보낼 수 없습니다.
MSExchangeIS\RPC Operations/sec 성능 카운터는 서버의 현재 작업 부하를 나타내므로, 관리자가 특히 서버 사용량이 최고일 때와 정상 작업 기간 동안에 예상되는 서버 값을 알고 있는 경우에 Exchange 처리에서의 병목 현상을 확인하는 데 매우 유용합니다. 초당 300개의 RPC 작업을 받을 때는 문제 없이 수행되는 서버가 초당 1500개의 RPC 작업을 처리하기는 어려울 수 있습니다. 따라서 관리자는 항상 MSExchangeIS\RPC Operations/sec 카운터를 살펴보고 이 값의 변화를 RPC 요청 수의 변화와 관련시켜 생각해야 합니다.
클라이언트가 Exchange 성능 저하에 대해 불평하지만 MSExchangeIS\RPC Requests 및 MSExchangeIS\RPC Operations/sec가 모두 0이하인 경우에는 서버 자체의 병목 현상은 아닙니다. 여기서의 문제는 서버 이외의 어떤 요인으로 인해 서버에서 정보를 전혀 받을 수 없다는 것입니다. 관리자는 Active Directory 성능, 네트워크 성능, 클라이언트 구성 및 그 밖에 Exchange 서버에서 데이터를 받을 수 없는 원인을 검토해야 합니다.
MSExchangeIS\RPC Requests는 점차 증가하는데 MSExchangeIS\RPC Operations/sec가 상당히 안정되어 있다면 이는 서버가 기존 작업 부하를 처리할 수 없음을 나타냅니다. 관리자는 실제 메모리, 저장소 및 프로세서 기능을 비롯한 하드웨어 구성 요소를 확인하거나 서버 사용자 수를 줄여야 합니다.
MSExchangeIS\RPC Requests는 점차 증가하는데 MSExchangeIS\RPC Operations/sec가 점차 감소한다면 이는 Exchange 서버가 병목 현상의 원인임을 나타냅니다. 이 경우에는 어떤 원인으로 인해 정보 저장소가 RPC 작업을 완료할 수 없으며 연결된 RPC 스레드가 할당된 채로 남아 있습니다. 스레드가 더 많이 할당될수록 새 작업에 사용할 수 있는 서버의 스레드 수는 더 적어지므로 새 작업 수가 감소합니다. 서버에 대기 중인 RPC 요청 수가 500개에 이르면 새 RPC 작업은 거부됩니다. 이 문제는 대개 정보 저장소나 통합 구성 요소(바이러스 백신, 저널링 등)의 프로세싱 문제나 실제 리소스(메모리 또는 디스크)가 매우 부족해서 발생합니다.
다음 표에서는 RPC 프로세싱 문제를 파악하고 해결하는 데 매우 중요한 카운터에 대해 설명합니다.
RPC 처리 관련 성능 카운터
| 카운터 | 예상 값 |
|---|---|
MSExchangeIS\RPC Requests Microsoft Exchange 정보 저장소 서비스에서 현재 처리되고 있는 MAPI RPC 요청 수를 나타냅니다. Microsoft Exchange 정보 저장소 서비스는 최대 500개의 RPC 요청을 동시에 지원할 수 있으며, 그 이후의 새 클라이언트 요청은 거절합니다. |
|
MSExchangeIS\RPC Averaged Latency 이전 1024개 RPC 패킷에서 이루어진 모든 RPC 작업의 평균 대기 시간을 밀리초 단위로 나타냅니다. 전체 서버 RPC 평균 대기 시간이 증가할 때 클라이언트에 미치는 영향에 대해 알아보려면 이 항목의 후반에 나오는 "클라이언트 스로틀"을 참조하십시오. |
|
MSExchangeIS\RPC Operations/sec 초당 정보 저장소에 전송되는 RPC 현재 작업 수를 나타냅니다. |
|
MSExchangeIS\RPC Num. of Slow Packets 이전 1024 패킷 중 대기 시간이 2초를 넘는 RPC 패킷 수를 나타냅니다. |
|
클라이언트 쪽 모니터링
Microsoft Office Outlook 2003 및 Office Outlook 2007에는 클라이언트 쪽 모니터링 기능이 추가되어 있습니다. 클라이언트 쪽 모니터링을 사용하면 클라이언트 오류 및 대기 시간 문제를 찾아낼 수 있습니다. 서버의 레지스트리를 수정하여 Exchange 서버에서 클라이언트 쪽 모니터링 기능을 사용하도록 설정할 수 있습니다. 이 기능을 사용하도록 설정하면 Outlook 2007 및 Outlook 2003 클라이언트가 실패한 RPC 요청 및 오류 상태 등이 포함된 연결 상태를 바탕으로 데이터를 서버에 보냅니다. 이 정보는 서버에서 집계되고 서버의 이벤트 로그 항목에 기록됩니다. Outlook에서 클라이언트 쪽 모니터링 기능을 사용하도록 설정하는 방법에 대한 자세한 단계는 클라이언트 쪽 모니터링을 사용하도록 설정하는 방법을 참조하십시오.
클라이언트 스로틀
Exchange 2007에는 관리자가 최종 사용자가 느끼는 성능을 편리하게 관리할 수 있도록 하는 RPC 클라이언트 스로틀이라는 새 기능이 있습니다. RPC 클라이언트 스로틀은 클라이언트 응용 프로그램이 초당 Exchange 서버로 보낸 RPC 작업 수가 너무 많아 전반적인 서버 성능이 저하되는 현상을 방지하기 위해 도입되었습니다. 이러한 클라이언트 응용 프로그램에는 사용자 사서함 내의 모든 개체를 검색하는 데스크톱 검색 엔진, Exchange 사서함에 있는 데이터를 조작하기 위한 사용자 지정 응용 프로그램, 엔터프라이즈급 전자 메일 보관 제품 및 전자 메일 자동 태깅 기능이 있는 CRM 사용 가능 사서함 등이 포함됩니다. 클라이언트 스로틀을 사용하면 일부 사용자에 의한 서버 독점 현상을 발견하고 방지할 수 있습니다. Exchange 서버에서 한 클라이언트가 서버에 적절하지 않은 영향을 미치는 것으로 확인되면 서버는 서버 성능에 대한 영향을 줄이도록 "백오프" 요청을 이 클라이언트에 보냅니다. Exchange 2007의 클라이언트 스로틀 기능에 대한 자세한 내용은 클라이언트 스로틀 이해를 참조하십시오.