많은 항목 수와 제한된 보기가 성능에 미치는 영향 이해

마지막으로 수정된 항목: 2009-01-14

이 항목에서는 온라인 모드에서 실행되는 Microsoft Office Outlook을 사용하거나 캐시 모드에서 대리인 액세스가 가능한 Outlook을 사용하거나 Outlook Web Access를 사용할 때 중요 경로 폴더의 많은 항목 수와 제한된 보기 요청과 관련된 Microsoft Exchange Server 2007 성능 문제를 이해하고 진단하며 해결하는 데 유용한 정보를 제공합니다. 중요 경로 폴더는 일정, 연락처, 받은 편지함 및 보낸 편지함 폴더입니다. 제한된 보기는 검색 조건을 기준으로 정보를 제한하는 데이터 보기로, 이를 통해 한 폴더에 있는 항목의 하위 집합 보기만 표시됩니다. 이러한 상황과 관련된 성능 문제는 상호 관련되는 경우가 많으며 최종 사용자에게 클라이언트 액세스 속도 저하의 형태로 나타날 수 있습니다. 중요 경로 폴더에 비정상적으로 많은 항목 수를 가지고 있어 전체 Exchange 조직에서 느끼는 성능 문제를 유발하는 사용자는 일부에 지나지 않습니다.

Exchange Server 2003의 폴더당 권장 최대 항목 수는 5,000개였습니다. Exchange 2007에서는 I/O가 개선되고 페이지 크기가 커졌으며 캐시가 증가하여 권장 최대 항목 수를 증가시킬 수 있습니다. 적절히 설계된 하드웨어를 갖춘 환경에서는 항목 수를 20,000개까지 늘려도 적절한 사용자 환경을 유지할 수 있습니다.

이 권장 최대값은 타사 프로그램이 사용자 사서함에 액세스하는지 여부에 따라 달라집니다. 이러한 타사 프로그램에는 다음 프로그램 및 기타 유사 프로그램이 포함됩니다.

• Outlook 추가 기능

• 전자 메일 보관

• 바이러스 백신

• 모바일 장치

• 음성 메일

• 뷰 또는 검색 폴더를 추가로 만드는 기타 프로그램 또는 Outlook 추가 기능

이 경우 항목 수는 전체 서버 로드와 서버에서 특정 타사 프로그램의 각 요청을 처리하는 방법을 함께 검토하여 확인해야 합니다.

이 권장 최대값 역시 Exchange 환경의 성능 기능에 따라 달라집니다. 어떤 하드웨어를 선택하는지에 따라 최대 항목 수가 줄어들 수도 있습니다. 이상적으로는 받은 편지함과 보낸 편지함 폴더의 항목 수를 20,000개 미만으로, 연락처와 일정 항목은 5,000개 미만으로 유지하는 것이 좋습니다. 권장되는 최대값 이하인 항목 수를 유지 관리할 때도 일부 작업은 시간이 1분 정도로 오래 걸릴 수 있기 때문입니다. 이러한 작업으로는 처음으로 폴더를 선택하거나 새 정렬 순서를 사용하는 작업 등이 있습니다. 처음으로 폴더를 볼 때는 보기를 생성하는 데 시간이 더 오래 걸릴 수도 있습니다. 중요 경로 폴더는 사용자 사서함에서 가장 자주 액세스되는 폴더이므로 이 폴더에 항목 수가 많으면 서버 성능에 좋지 않은 영향을 줍니다. 그러나 다른 폴더, 특히 최종 사용자가 만드는 사용자 지정 폴더와 같은 경우에는 액세스 빈도가 비교적 낮으므로 사용자 경험에 좋지 않은 영향을 주지 않고도 더 많은 수의 항목을 처리할 수 있습니다. 액세스 빈도가 비교적 낮은 폴더에는 항목 수가 더 많아도 성능에 미치는 영향이 더 적지만, 이와 같은 폴더 수가 늘어나고 서버의 활성 사용자 수가 늘어나면 이러한 폴더에 항목 수가 많은 것이 여전히 일시적인 성능 문제를 일으킬 수 있습니다.

조직에 적합한 최대 항목 수를 고려할 때 최대값은 제한 없이 원하는 대로 선택할 수 있지만, 그렇게 하는 경우 성능이 점진적으로 저하된다는 점을 기억해야 합니다. 지정한 최대값 제한은 하드 코드되지 않으며, 테스트 및 코드 분석을 기반으로 하는 숫자일 뿐입니다. 항목 수가 늘어나면 사용자가 체감할 수 있을 정도로 성능이 떨어질 수 있습니다. 작업 중인 환경에서 사용자에게 적절한 성능 수준에 따라 해당 환경에 적합한 최대 항목 수가 지정됩니다.

개별 사서함에 대한 고유 크기 제한은 없습니다. 사서함 크기를 제한하는 주요 요소는 사용 가능한 디스크 공간, 백업 및 복원 시간, 서비스 수준 계약, Outlook 성능입니다. Outlook 성능이라는 것은 구체적으로 최종 사용자가 경험하는 대기 시간을 말합니다.

하드웨어 선택이 성능에 미치는 영향 이해

조직의 하드웨어 크기가 적절하지 않은 경우 항목 수가 적더라도 성능이 저하될 수 있다는 점이 분명하지만 이러한 현상은 계속 반복되고 있습니다. 온라인 모드에서는 사서함의 항목 수가 늘어날수록 시스템의 I/O 요구 사항이 증가합니다. 디스크 대기 시간은 많은 항목 수에 대해 하드웨어 성능을 평가할 때 가장 중요한 하드웨어 고려 사항 중 하나입니다. 최적의 사용자 환경을 유지하려면 서버 사용량이 최대인 경우에도 디스크 대기 시간은 20밀리초 이하로 짧아야 합니다.

디스크 대기 시간이 어떻게 합산되며 서버 성능에 어떤 영향을 줄 수 있는지 알아보기 위해 다음 예를 살펴보겠습니다. 보기를 요청할 경우 데이터에 대한 요청은 디스크에서 일괄 작업이 아닌 연속된 개별 요청으로 수행됩니다. 예를 들어, 플러그 인에서 1000개의 항목 보기를 반환하면 Exchange 저장소에서 데이터에 대한 약 200개의 별개 요청을 만들 것입니다(각 요청마다 5개의 메시지가 검색된다고 가정). 20밀리초인 경우 디스크 하위 시스템에서만 4초 지연됩니다. 디스크 대기 시간이 50밀리초 또는 100밀리초로 늘어나면 성능에 미치는 영향이 커진다는 사실을 고려해야 합니다. 여러 플러그 인이 사용되어 비슷한 요청이 만들어지는 경우 문제가 더 복잡해집니다. 이러한 상황에서는 사용자가 Outlook이 자주 차단된다고 느낄 수 있습니다.

Exchange 2007에서 좋은 성능을 얻기 위한 서버 크기 조정 권장 사항에 대한 자세한 내용은 서버 및 저장소 아키텍처 계획을 참조하십시오.

추가 처리 시간이 필요할 수 있는 이유 이해

서버의 처리 능력과 관련해 많은 항목 수와 제한된 보기 요청이 성능에 미치는 영향을 고려할 때, 발생되는 기본 프로세스를 알고 많은 항목 수와 제한된 보기 요청이 이러한 프로세스와 어떤 연관이 있는지 알아야 합니다.

폴더 내용은 정보 저장소 데이터베이스의 테이블에 저장됩니다. 항목 수가 늘어날수록 그에 따라 저장소가 더 복잡해집니다. Exchange 저장소의 저장소 메커니즘은 ESE(Extensible Storage Engine)입니다. ESE에서는 B+ 트리 데이터 구조를 사용하여 레코드를 저장합니다. 레코드 수가 늘어날수록 정보를 찾고 B+ 트리를 트래버스하는 데 필요할 것으로 예상되는 디스크 I/O 요청 수도 늘어납니다. 자세한 내용은 Extensible Storage Engine 아키텍처를 참조하십시오.

항목 수가 늘어날수록 요청된 데이터가 하드 디스크에서 실제로 가까운 위치에 있을 가능성이 크게 줄어듭니다. 따라서 더 많은 I/O 요청이 필요합니다.

제한된 보기를 만들려면 Exchange 서버에서의 처리가 필요합니다.

다음과 같은 두 가지 방법으로 MAPI의 메시지를 필터링합니다.

• 검색 폴더

• 제한

  제한은 MAPI 테이블에 대해 IMAPITable::Restrict 메서드를 호출하여 만들어집니다. 호출 결과 생성되는 테이블에는 지정된 제한에 맞는 항목만 표시됩니다. 제한된 콘텐츠 테이블에는 단일 폴더의 메시지만 표시됩니다. 이러한 종류의 제한을 검색 폴더의 필터 조건을 설명하는 MAPI 정의 구조와 혼동하는 경우가 있습니다. 이러한 종류의 MAPI 정의 구조 역시 제한이라고도 합니다.

검색 폴더 및 제한을 사용하려면 추가 처리 작업을 수행해야 합니다. 예를 들어 검색 폴더를 만들고 사용자 조건에 맞는 항목으로 검색 폴더를 채우는 작업을 수행해야 합니다. 이 프로세스를 처리하기 위해서는 폴더의 각 항목을 검사하여 각 항목을 검색 폴더에 배치해야 하는지 여부를 결정해야 합니다. 따라서 폴더에 여러 항목이 포함되어 있는 경우에는 보기를 만드는 데 더 많은 시간이 필요합니다. 이러한 검색 폴더는 검색이 발생한 각 폴더 아래에 SearchFID로 저장됩니다. 기본적으로 검색 폴더는 채워진 이후 최대 40일 동안 존재할 수 있습니다.

제한된 보기의 존재 여부는 폴더 항목에 대한 수정 속도에 영향을 줍니다. 한 검색 폴더가 다른 폴더와 연결되어 있으면, 이 다른 폴더에서 항목이 추가, 삭제 또는 업데이트될 때 추가 처리가 이루어져야 합니다. 검색 폴더를 업데이트해야 하는지 여부를 Exchange에서 결정해야 하기 때문에 이러한 동작이 발생합니다. 여러 검색 폴더를 설정하면 모든 검색 폴더에 대해 각 변경을 평가하여 검색 폴더를 업데이트해야 하는지 여부를 결정해야 합니다.

Outlook에서 폴더 보기에 비표준 속성을 추가한 경우 Exchange 저장소에서 비표준 속성을 검색하는 데 추가 RPC(원격 프로시저 호출)가 필요할 수 있습니다. 폴더에 여러 항목이 포함되어 있는 경우 Exchange 서버에서 데이터를 검색하는 데 더 많은 왕복 이동이 필요합니다.

일정 폴더를 보려는 경우 Outlook에서 지정된 날짜 범위에 있는 모든 약속을 찾아야 합니다. 이 작업을 위해서는 적어도 두 개의 처리 요청이 필요합니다. 첫 번째 요청에서는 지정된 날짜 범위에 있는 모든 고정 약속을 가져옵니다. 두 번째 요청에서는 지정된 날짜 범위에서 발생하는 모든 되풀이 약속을 찾습니다. 두 번째 요청을 처리하는 데 필요한 시간은 일정 폴더에 있는 항목 수에 비례합니다. Outlook에서 모든 되풀이 약속을 요청하기 때문에 이 동작이 발생합니다. 되풀이 약속 목록을 받았으면 각 되풀이 약속을 검사하여 해당 약속이 지정된 날짜 범위에서 발생하는지 여부를 확인해야 합니다. 일정에 여러 항목이 포함되어 있으면 이러한 요청을 처리하는 데 더 많은 시간이 필요합니다.

항목 수와 사서함 크기가 성능에 미치는 영향 이해

대부분의 성능 문제는 사서함 크기가 크기(2GB 이상의 사서함으로 정의) 때문이 아니라 서버에서 액세스되는 폴더의 항목 수 때문에 발생합니다. 폴더에 항목이 많이 있으면 이러한 폴더에서의 작업이 오래 걸리기 때문에 성능에 좋지 않은 영향을 줍니다. 특히 일정, 연락처, 받은 편지함, 보낸 편지함 폴더와 같은 중요 경로 폴더의 항목 수가 성능에 크게 영향을 줍니다. 큰 사서함을 계획하는 방법에 대한 자세한 내용은 White Paper: Planning for Large Mailboxes with Exchange 2007(영문)을 참조하십시오.

보기에 새 열 추가, 새 열에 대한 정렬, 찾기 및 검색 작업은 폴더의 항목 수에 따라 영향을 받는 작업입니다. 다수의 Outlook 플러그 인은 실행 시 정렬 또는 검색 작업을 수행하며 이러한 요청은 다른 Outlook MAPI 요청과 겹칠 수 있습니다. 이로 인해 사용자가 좋지 않은 경험을 하게 됩니다.

캐시 모드(Outlook 2003 이상 버전의 기본 모드)에서 실행하는 경우 폴더의 항목 수가 늘어날수록 클라이언트 성능이 문제가 될 수 있습니다. 이런 경우에는 OST 파일(로컬 데이터 캐시)을 조각이 없는 상태로 유지해야 합니다. 이를 위해 Windows SysInternals 도구인 Contig를 사용할 수 있습니다. 최신 버전의 Contig를 다운로드하려면 Contig v1.55(영문)를 참조하십시오.

중요 경로 폴더의 항목 수 외에도, 많은 항목 수로 인해 악화된 Outlook 경험에 추가로 영향을 미치는 다른 요소들이 있습니다. 기타 MAPI 응용 프로그램 수 또는 사용자 컴퓨터에서 실행되는 Outlook 플러그 인을 예로 들 수 있습니다. 모든 MAPI 요청을 수행하려면 emsmdb32.dll을 사용한 처리 시간이 필요합니다. 사용자가 요청을 만드는 플러그 인을 많이 가지고 있으면 Outlook의 실행 속도가 느려지고 서버에 미치는 영향이 늘어날 수 있습니다. 또한 요청된 작업의 복잡한 정도에 따라서도 영향을 받습니다. 예를 들어, 폴더의 모든 항목을 읽은 상태로 표시하는 데에는 한 항목을 읽은 상태로 표시할 때보다 훨씬 더 시간이 오래 걸립니다. 모임 요청에 대해 많은 사용자의 약속 있음/없음 정보를 검색하거나 여러 폴더를 대상으로 검색을 수행하는 작업도 시간이 오래 걸릴 수 있습니다. 사용자가 복잡한 작업을 자주 수행하거나 많은 Outlook 플러그 인을 가지고 있거나 연락처 및 일정 폴더를 많이 사용하는 경우에는 많은 항목 수로 인해 성능이 떨어질 가능성이 크게 높아집니다.

제한된 보기 이해(MAPI 제한)

일반적으로 MAPI에서는 데이터를 테이블 형태로 나타냅니다. 클라이언트가 공급자 목록, 폴더 테이블, 폴더 내용, 첨부 파일 등을 요청할 경우 클라이언트에게 제공되는 테이블이 있습니다. 각 테이블은 열로 구성됩니다. 각 열은 보낸 사람, 제목 및 배달 시간과 같은 특성을 나타내는 서로 다른 MAPI 속성입니다. 각 행은 특정 항목을 나타냅니다. 폴더 내용 테이블의 경우에는 각 행이 메시지를 나타냅니다. 이러한 테이블에 대한 클라이언트 작업은 데이터 정렬과 같은 작업으로 나타납니다. 클라이언트는 지정된 조건과 일치하는 특정 행을 테이블에서 찾을 수 있는데, 이러한 작업을 FindRow()라고 합니다. 또한 클라이언트는 특정 조건에 맞는 항목만 테이블에 포함되도록 요청할 수도 있습니다. 예를 들어, 특정 날짜에 만든 항목만 포함되도록 할 수 있습니다. 이것을 제한이라고 합니다. 테이블에서 지정된 조건에 맞는 항목만 결과 폴더 내용 테이블에 포함됩니다. 제한은 클라이언트가 동일한 데이터를 표시하도록 자주 요청할 것으로 예상될 때 사용됩니다.

제한된 보기가 성능에 영향을 미치는 방식

제한으로 인한 성능 결과를 이해하려면 정보 저장소가 실제로 MAPI 클라이언트의 요청 데이터를 저장한다는 점과 정보 저장소가 FindRow 및 Restrict와 같은 요청을 어떻게 해석하는지를 고려해야 합니다. 저장소의 저장소 스키마 내부에는 사서함, 폴더, 폴더 내용 및 메시지와 같은 항목을 집합적으로 나타내는 다양한 테이블이 있습니다.

클라이언트가 폴더 내용 목록을 요청하면 해당 요청이 MessageFolder 테이블(MsgFolder)이라는 특수 폴더에 매핑됩니다. 시스템에 만들어진 각 폴더에는 별개의 메시지 폴더 테이블이 있습니다. MsgFolder 테이블은 폴더를 해당 내용에 매핑하기 위한 것입니다.

Restrict 호출(같은 데이터를 빈번하게 다시 요청)의 예상 항목을 처리하기 위해 제한된 검색 폴더라고 하는 새 특수 폴더와 해당 MsgFolder 테이블이 만들어집니다. 이 폴더는 원본 폴더에 대해 역방향으로 연결되고 이 두 폴더 사이에는 논리적 관계가 있습니다. 검색 폴더에는 제한에 의해 지정된 조건에 맞는 항목만 포함해야 한다는 조건이 주어집니다. 이 검색 폴더에는 MsgFolder 테이블에서 제한 조건에 맞는 메시지마다 MsgFolder 테이블의 원래 행에 대한 역방향 연결이 있습니다.

이 동작과 관련하여 발생하는 성능 문제는 각 검색 폴더에 대한 업데이트를 관리하는 데 필요한 시간과 관련된 문제입니다. 원본 폴더가 변경되면 해당 폴더와 연결된 각각의 제한된 검색 폴더와 변경 내용이 비교되어 검색 폴더도 업데이트되어야 하는지 여부가 결정됩니다. 이때 하나 또는 여러 개의 폴더에 대해 많은 검색 폴더가 있는 경우 성능에 미치는 영향이 큽니다. 발생하는 두 번째 문제는 제한된 검색 폴더 만들기와 관련된 문제입니다. 제한된 검색 폴더를 만들려면 제한된 검색 폴더에 연결되어야 하는 개별 항목을 원본 폴더가 추출하는 전체 과정이 필요합니다. 이 프로세스가 클라이언트 작업의 직접적인 결과로 발생하는 경우 시간 지연으로 인해 사용자의 작업이 중단될 수 있고 또는 요청 처리 시간이 오래 걸린다는 Outlook RPC 팝업 상자가 나타날 수 있습니다. 제한된 검색 폴더를 만드는 데 필요한 시간은 일반 폴더의 항목 수에 비례합니다. 폴더의 항목 수가 늘어날수록 이러한 항목이 가까운 디스크 섹터에 있을 가능성이 크게 줄어듭니다. 이로 인해 항목 수가 많은 폴더에 대한 제한된 보기 요청을 수행할 때 임의 디스크 I/O 수가 크게 늘어납니다. 항목 수가 많은 폴더에 대해 제한된 보기 요청 수가 늘어날수록 서버의 리소스에 액세스하는 모든 사용자가 증가하는 I/O 수로 인한 영향을 받게 됩니다.

Exchange 2000 Server, Exchange Server 2003 및 Exchange Server 2007에는 폴더별로 허용되는 제한된 검색 폴더의 최대 개수가 있습니다. 기본 최대 개수는 11개이며 검색 폴더의 기본 수명은 40일입니다.

제한된 검색 폴더는 FIFO(선입 선출) 방식으로 처리됩니다. 폴더에 이미 11개의 제한된 검색 폴더가 연결되어 있는 상태에서 새로운 제한 요청이 이루어지는 경우, 검색 폴더 목록은 제한이 실제로 사용된 마지막 시간을 통해 평가됩니다. 즉, 제한된 검색 폴더 중 가장 적게 사용된 폴더가 제거되어 새로운 요청 처리가 허용됩니다. 앞에서 언급한 대로 여기에는 일반 MsgFolder 테이블의 전체 과정이 필요하며, 클라이언트의 직접적인 작업으로 수행된 경우에는 테이블이 만들어지고 클라이언트에게 제공되는 동안 클라이언트가 성능 문제를 인식할 수 있습니다. 따라서 매일 또는 매주 13개 이상의 제한된 검색 폴더가 필요할 수 있습니다. 따라서 클라이언트가 현재 일치하는 검색 폴더가 없는 제한 요청을 유발하여 제한된 검색 폴더가 삭제되고 새로운 제한된 검색 폴더가 만들어집니다. 이러한 모든 요청은 연속적으로 처리됩니다. 즉, 제한된 보기가 정기적으로 요청되는 폴더에 아주 많은 항목 수를 가지고 있는 사용자가 많을 경우 이러한 요청이 대기 상태에 있을 수 있습니다. 그러면 서버에 있는 사서함 데이터에 액세스하는 모든 사용자가 전체적으로 속도 저하를 느끼게 됩니다. 그러나 해당 사서함에 액세스하는 사용자만 이러한 영향을 받는 것이 아닙니다. 예를 들어, 서버에 저장된 일정 데이터에 액세스하는 다른 서버의 사용자도 속도 저하를 느끼게 됩니다.

제한된 보기 및 공유 일정

다른 사람의 일정, 연락처 폴더 등을 볼 때 폴더가 표시되기 전에 지연이 발생할 수 있습니다. 폴더가 표시된 후에는 아주 빠르게 폴더에서 나오거나 폴더로 돌아갈 수 있습니다. 그러나 어느 정도 시간이 지나면 폴더에 액세스하는 속도가 느려집니다. 일정의 항목 수가 5000개를 넘는 경우 특히 지연 시간이 길어집니다.

Outlook에서 다른 사람의 폴더에 액세스할 때 사용자가 개인 항목을 보지 못하도록 제한하는 보기가 적용됩니다.

폴더에 보기가 적용되면 저장소에 검색 폴더가 만들어집니다. 검색 폴더가 만들어지면 나중에 사용할 수 있도록 캐시됩니다. 사용자가 만들려고 하는 검색 폴더가 이미 있으면 캐시된 검색 폴더가 사용됩니다. 이로 인해 향후 보기 속도가 매우 빨라집니다.

기본적으로 Exchange에서는 모든 검색 폴더를 무제한으로 캐시하지는 않습니다. 너무 많은 검색 폴더를 캐시하면 검색 폴더 업데이트와 관련하여 서버 측 지연이 발생합니다. 반대로 충분한 수의 검색 폴더를 캐시하지 않으면 검색 폴더를 생성 및 업데이트해야 할 때 비슷한 문제가 발생합니다.

이 문제를 설명하기 위해 Exchange 서버가 폴더당 11개의 검색 폴더(보기)를 유지하도록 구성된 시나리오를 생각해 봅니다. Frank가 15명의 다른 사용자와 공유하는 일정 폴더를 가지고 있다고 가정합니다. Sally가 해당 폴더에 액세스한 다음에는 검색 폴더가 만들어지는 동안 지연이 발생합니다. 검색 폴더가 만들어진 후에는 액세스 속도가 빠릅니다. 그런 다음 Sally는 하루 동안 해당 폴더를 보지 않고 11명의 다른 사용자가 해당 폴더에 액세스합니다. 11명의 사용자 각각에 대해 새로운 검색 폴더가 만들어집니다. 11개의 검색 폴더만 캐시되기 때문에 12번째 사용자가 해당 폴더에 액세스하면 Exchange에서 Sally용으로 만든 검색 폴더를 삭제합니다. 이제 Sally가 다음 번에 해당 폴더에 액세스할 경우 Exchange에서 자신의 검색 폴더를 만드는 동안 기다려야 합니다.

대신 Frank의 사서함 서버가 20개의 보기를 캐시하도록 구성한다고 가정합니다. 그러면 Sally 및 다른 14명의 사용자가 모두 Frank의 일정 폴더에 액세스할 수 있고 15개의 검색 폴더만 만들어집니다. 15는 20보다 작기 때문에 보기를 순환할 필요가 없으므로 검색 폴더를 만들기 위해 처음 액세스한 이후 모든 사람의 액세스 속도가 빨라집니다.

캐시된 검색 폴더의 기본 개수는 11개이며 이 구성은 데이터베이스 수준에서 설정됩니다. 구성된 값은 ADSI 편집을 통해 볼 수 있습니다. ADSI 편집을 사용하여 저장소 개체를 확인한 다음 msExchMaxCachedViews 특성을 확인합니다. 고유 이름은 다음과 같습니다.

CN=Database, CN=Storage Group,CN=InformationStore,CN=Server NAME,CN=Servers,CN=AG Name,CN=Administrative Groups,CN=Orgname,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,DC=com.

환경에 미치는 성능 영향을 조정하기 위해 11보다 큰 값으로 수정하는 것이 유용한 경우도 있습니다.