다음을 통해 공유

클라이언트 스로틀 이해

  • 아티클

 

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2009-04-20

Microsoft Exchange Server 2007에서는 관리자가 최종 사용자가 느끼는 성능을 편리하게 관리할 수 있도록 하는 RPC 클라이언트 스로틀이라는 새 기능을 제공합니다. RPC 클라이언트 스로틀은 클라이언트 응용 프로그램이 초당 Exchange 서버로 보낸 RPC 작업 수가 너무 많아 전반적인 서버 성능이 저하되는 현상을 방지하기 위해 도입되었습니다. 이러한 클라이언트 응용 프로그램에는 사용자 사서함 내의 모든 개체를 검색하는 데스크톱 검색 엔진, Exchange 사서함에 있는 데이터를 조작하기 위한 사용자 지정 응용 프로그램, 엔터프라이즈급 전자 메일 보관 제품 또는 전자 메일 자동 태깅 기능이 있는 CRM 사용 가능 사서함 등이 포함됩니다. 클라이언트 스로틀을 사용하면 일부 사용자에 의한 서버 독점 현상을 확인하고 방지할 수 있습니다. Exchange 서버에서 한 클라이언트가 서버에 적절하지 않은 영향을 미치는 것으로 확인되면 서버는 서버 성능에 대한 영향을 줄이도록 "백오프" 요청을 이 클라이언트에 보냅니다.

참고

Microsoft Exchange Server 2003에서는 "Disable MAPI Client Processes"라는 레지스트리 키가 사용되었습니다(A feature is available to disable MAPI program access to a computer that is running Exchange Server 2003(영문)에 설명되어 있음). 이 레지스트리 키를 사용하면 특정 프로세스의 정보 저장소 서비스 연결을 잠글 수 있었습니다. Exchange 2007에서는 이 레지스트리 키가 더 이상 구현되지 않고 새 RPC 클라이언트 스로틀 메커니즘으로 대체되었습니다.

RPC 클라이언트 스로틀 작동 방식

Exchange 2007 서버의 RPC 평균 대기 시간이 정상인 경우보다 높으면 Exchange 서버 사용자는 현저한 서비스 저하를 느낄 수 있습니다. 최종 사용자가 받아들일 수 있는 적정한 수준을 유지하기 위해서는 RPC 평균 대기 시간이 100밀리초 미만으로 유지되어야 합니다.

RPC 클라이언트 스로틀은 전체 RPC 평균 대기 시간 및 ROP(원격 작업) 통계를 바탕으로 계산하여, 특정 클라이언트가 서버에 대해 수행할 수 있는 작업 수를 제한하기 위한 백오프 요청을 해당 클라이언트가 받게 되는지 여부를 결정합니다. 이 방식에서는 특정 시간(분) 동안의 세 샘플링 기간에 걸쳐 ROP 간의 평균 지연 시간을 계산합니다. 이 논리에서는 마지막 1분 동안의 ROP 비율의 이동 평균이 사용됩니다. 이 값이 결정되면 전체 RPC 평균 대기 시간과 비교하여 계산된 이 값이 작을 경우 백오프 요청이 클라이언트에 보내집니다.

중요

초당 ROP 수가 순간적으로 높더라도 마지막 1분 동안의 평균 RPC 대기 시간이 낮다면 클라이언트에 백오프 요청을 보내지 않습니다.

예를 들어, RPC 대기 시간이 25밀리초인 경우 정상적으로 동작하는 클라이언트에서는 스로틀 없이 초당 최대 40개의 ROP를 전송할 수 있습니다(40*25=1000밀리초). 하지만 RPC 대기 시간이 100밀리초로 늘어난 상태에서 클라이언트가 동일한 개수의 ROP를 보내려고 할 경우에는 클라이언트에게 서버의 백오프 요청이 전송되기 시작합니다. 이때부터 서버는 다음 RPC 평균 대기 시간 샘플이 다시 100밀리초 아래로 떨어질 때까지 클라이언트에게 초당 최대 10개의 ROP만 보내도록 허용합니다.

백오프 요청의 논리는 크게 두 가지 부분으로 구성됩니다. 첫 번째는 서버가 클라이언트 스로틀을 결정하는 방법이며 두 번째는 서버에 액세스하지 못하도록 클라이언트를 차단하는 결정과 관련된 것입니다. 정보 저장소 서비스에는 특정 서버에 대한 각 사용자의 작업을 추적하는 클라이언트 작업 로그가 있습니다. 각 클라이언트 작업 로그는 사용자 MAPI 세션과 연결됩니다. 서버에서 클라이언트를 스로틀하기로 결정하면 백오프 요청이 해당 사용자 MAPI 세션의 세션 백오프 큐에 추가됩니다. 그런 다음 이 백오프 정보를 통해 서버에서 클라이언트 요청을 허용할지 아니면 거부할지가 결정됩니다. 사용자가 단일 MAPI 세션에 대해 여러 사서함을 열었다면 이 백오프 정보는 해당 MAPI 세션의 모든 사서함에 적용됩니다.

사용하는 Microsoft Office Outlook 버전에 따라 클라이언트의 RPC 응답 스트림에 보내는 서버의 백오프 정보가 다릅니다.

  • Microsoft Office Outlook 2007 클라이언트의 경우에는 ropBackoff 요청이 사용자의 백오프 큐에 추가됩니다. 이 요청에는 현재 백오프 지연에 대한 정보가 포함되어 있어 클라이언트에게 지정된 시간 동안 서버에 추가 요청을 보내는 것을 지연하라고 알립니다. 지정된 시간이 지나면 클라이언트가 요청을 보내려고 다시 시도합니다. 이 백오프 지연의 최대 시간은 2000밀리초, 즉 2초로 하드코드되어 있습니다.

    참고

    최적의 클라이언트 환경을 위해 Exchange 2007 서버에는 Outlook 2007 클라이언트를 사용하는 것이 좋습니다.

    참고

    ropBackoff는 Outlook 2007의 새 기능이므로 이전 Outlook 클라이언트에서는 이 기능을 인식하지 못합니다.

  • Microsoft Office Outlook 2003 이전 버전의 경우에는 상태 코드 RPC_S_SERVER_TOO_BUSY가 전송됩니다. 이 상태 코드는 정보 저장소 RPC 스레드가 소모되었을 때 Exchange 2003 서버가 클라이언트에게 보내는 응답을 나타냅니다. 이전 버전에서는 이 예외를 catch한 다음, 서버가 클라이언트에게 보내는 응답에 지정된 대로 호출을 다시 시도할 때까지 기다립니다. 이 지연의 기본 시간은 1초입니다. 클라이언트가 1분 동안 1초마다 요청을 시도하며 매번 같은 예외를 받게 되면 클라이언트는 요청을 포기하고 Exchange 서버로의 세션 연결을 끊습니다.

초당 RPC 작업 수가 많은 상태 모니터링

클라이언트가 백오프되는 때를 편리하게 검색하려면 사서함 서버 역할이 설치된 Exchange 서버에서 성능 카운터 "MSExchangeIS\RPC Client Backoff/sec"를 모니터링하여 백오프 요청이 발생되는 비율을 확인하면 됩니다.

카운터 Outlook 2007에서의 예상 값 Outlook 2003 및 이전 버전에서의 예상 값

MSExchangeIS\RPC Client Backoff/sec

서버가 클라이언트에 백오프하도록 알리는 비율입니다.

클라이언트당 50회

클라이언트당 1회

스로틀되는 Outlook 2007 클라이언트의 경우 "MSExchangeIS\RPC Client Backoff/sec" 카운터를 모니터링하면 각 클라이언트에 대해 초당 약 50회의 백오프가 예상되고, Outlook 2003 이전 버전의 경우에는 각 클라이언트에 대해 기껏해야 초당 1회의 백오프가 예상됩니다. 이러한 예상 비율의 차이는 각 클라이언트에 사용되는 백오프 방식의 단위 때문입니다. Outlook 2003의 최소 백오프 시간이 1초인 반면 Outlook 2007의 최소 백오프 시간은 1밀리초입니다.

백오프 정보를 클라이언트에 보낼 때 데이터에는 두 부분이 포함됩니다. 첫 번째 부분은 백오프가 삽입된 시간이며, 두 번째 부분은 백오프가 지속되는 시간입니다. 백오프가 지속되는 시간은 (MSExchangeIS\RPC 평균 대기 시간 * RPC 스로틀 인수)/1000 공식을 바탕으로 계산됩니다. 기본적으로 RPC 스로틀 인수 값은 1000입니다. 즉, 백오프 시간이 바로 RPC 평균 대기 시간 값임을 의미합니다. 서버가 클라이언트에 보내는 백오프 값은 백오프 시간이 끝날 때까지의 시간(밀리초)입니다. 지정된 백오프 시간이 끝나기 전에 클라이언트가 다른 작업을 서버에 보내면 서버는 지연 값이 업데이트된 다른 ropBackoff를 반환합니다. 이러한 현상은 백오프 시간이 끝날 때까지 계속 일어나므로 사용자의 백오프 큐에서 ropBackoff가 제거됩니다. 성능 모니터에서 이와 유사한 샘플이 다음 그림에 나와 있습니다.

성능 모니터 RPC 클라이언트 백오프

초당 RPC 작업 수가 많은 상태 조정

사서함 서버 역할이 설치되어 있는 Exchange 서버에서 레지스트리 키를 사용하여 스로틀 계산을 편리하게 조정할 수 있습니다. RPC Throttling Factor라고 하는 이 레지스트리 키는 HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem 키 아래에 있습니다.

참고

이 값은 기본적으로 설정되지 않으므로 앞서 언급된 키 아래에 DWORD 값으로 추가해야 합니다.

[HKLM\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem]

RPC Throttling Factor

DWORD: 값 범위는 0-5000입니다.

RPC Throttling Factor 수정에 따른 변화를 알아보기 위해, 더 긴 백오프 시간(예: RPC 평균 대기 시간의 두 배) 동안 클라이언트를 백오프하도록 서버를 구성하는 시나리오를 가정합니다. 이러한 구성을 위해 RPC Throttling Factor 값을 2000으로 설정하면 각 MAPI 세션의 백오프 시간이 두 배로 늘어납니다. 이 경우 RPC 평균 대기 시간이 50밀리초이면 스로틀 인수 2000(50밀리초 * 2000/1000)은 100밀리초가 됩니다. 각 백오프 요청은 기본값인 50밀리초가 아닌 100밀리초로 늘어나 100밀리초 동안은 서버로 보내는 클라이언트의 MAPI 요청이 지연됩니다. 이러한 구성 변경으로 클라이언트에게는 서버 성능이 저하된 것으로 인식될 수 있습니다. 하지만 이 클라이언트로 인해 전체 서버 성능에 나쁜 영향을 미친다면 이 클라이언트의 Exchange 서버 리소스 사용량이 최소화될 것입니다. 이렇게 함으로써 서버의 모든 사용자가 느끼는 서버 성능을 향상시킬 수 있습니다.

중요

서버의 여러 클라이언트 또는 모든 클라이언트에게 이 문제가 발생하는 경우에는 병목 현상을 감지하기 위해 서버에 대한 조사를 수행해야 합니다.

이러한 스로틀 메커니즘을 통한 최적의 환경을 보장하기 위해 최소한 Outlook 2007 및 Exchange 2007이 권장됩니다.

스로틀 인수 값을 0으로 설정하여 스로틀을 전혀 사용하지 않도록 설정할 수 있습니다.

중요

정보 저장소에는 클라이언트 스로틀 기능을 사용하는 것이 좋습니다. 이 기능을 사용하지 않으면 비정상적으로 동작하는 클라이언트에 의한 서버 성능 저하가 발생하게 됩니다.

클라이언트 스로틀 기능을 사용하지 않아야 한다고 판단되면 서버의 성능 병목 현상에 대한 원인을 먼저 확인하는 것이 좋습니다. 대부분의 경우 이 원인을 파악하고 해결하면 서버가 클라이언트에 백오프 요청을 보내지 않아도 됩니다.

자세한 내용

RPC 요청이 늦게 처리되는 문제를 해결하기 위한 자세한 방법은 RPC 요청이 늦게 처리되는 문제 해결을 참조하십시오.

클라이언트 쪽 모니터링 기능을 사용하도록 설정하는 방법에 대한 자세한 내용은 클라이언트 쪽 모니터링을 사용하도록 설정하는 방법을 참조하십시오.