Exchange 디스크 I/O의 원인

  • 아티클

 

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

마지막으로 수정된 항목: 2010-05-31

Microsoft Exchange Server 2007의 서버 역할에는 허브 전송 서버와 Edge 전송 서버(통틀어 전송 서버라고 함), 클라이언트 액세스, 통합 메시징 및 사서함이 있습니다. 서버 역할마다 부분적으로 서로 다른 기능을 수행하므로 저장소 요구 사항, 백업 및 복원 요구 사항이 모두 다릅니다.

  • 허브 전송 서버 및 Edge 전송 서버:

    • 조직으로 들어오고 나가는 메일

    • 사서함으로 들어오고 나가는 메일

    • 통합 메시징 서버에서 제출한 음성 메시지

  • 클라이언트 액세스 서버는 Exchange의 클라이언트 프로토콜 서버로, Microsoft Outlook Web Access, Exchange ActiveSync, Outlook Anywhere 및 기타 인터넷 프로토콜을 제공합니다.

  • 통합 메시징 서버는 들어오는 팩스 지원과 함께 Outlook 음성 액세스를 제공합니다.

  • Exchange Server의 중심인 사서함 서버는 사용자 사서함과 공용 폴더가 저장되는 위치입니다.

  • 사서함 클러스터링 또는 SCC(단일 복사본 클러스터)는 공유 디스크의 액티브/패시브 구성에서 클러스터 서비스를 사용합니다.

  • 연속적인 복제는 대체 위치에 로그 파일을 만듭니다. 대체 위치는 LCR(로컬 연속 복제)을 사용하는 독립 실행형 서버, CCR(클러스터 연속 복제)을 사용하는 클러스터 또는 SCR(대기 연속 복제)를 사용하는 원격 서버에 있을 수 있습니다.

사서함 서버 역할

Exchange 2007 사서함 서버 역할은 모든 다른 서버 역할이 구축되는 핵심 서버 역할입니다. 초당 사용자 I/O(입/출력)와 용량을 포함하는 메일 사서함 프로필을 결정한 후에 배포 계획을 시작할 수 있습니다. Exchange 서버에 있는 사용자 수는 일반적으로 하드웨어 병목 상태 방지와 SLA(서비스 수준 계약) 내에서 해당 데이터를 백업하고 복원하는 능력 제공 간의 균형에 따라 결정됩니다.

Exchange 2007 배포를 달성하기 위해 균형을 이루어야 하는 세 가지 저장소 요구 사항이 있습니다. 첫 번째 요구 사항은 트랜잭션 I/O 또는 저장소에서 충족될 수 있는 각 I/O에 대해 대기 시간으로 측정된 성능입니다. 두 번째 요구 사항은 백업 및 복원 처리량 또는 백업 매체를 통해 최대한 빠르게 데이터가 이동할 수 있는 속도입니다. 세 번째 요구 사항은 용량 또는 프로덕션 LUN(논리 단위 번호)에 대해 선택한 RAID(Redundant Array of Independent Disks) 구성과 대상 백업 매체에 충분한 공간이 있는지 여부입니다.

사서함 프로필을 사용하여 디스크 I/O 요구 사항의 크기를 조정하는 방법에 대해서는 사서함 서버 저장소 디자인을 참조하십시오. 예를 들어, 초당 0.4 I/O(IOPS) 프로필과 2GB 사서함을 가진 서버에 3,000명의 사용자를 배치할 수 있습니다. 이 경우 성능 요구 사항은 1,200 IOPS입니다. 6TB의 정보를 백업하고 복원할 수 있는지 확인해야 합니다. SLA를 4시간 동안 백업하는 경우 한 시간에 1.5TB의 데이터 또는 초당 417MB를 백업해야 합니다. 백업 솔루션이 초당 300MB만 백업할 수 있으면 사서함 크기 또는 사용자 수를 28%까지 줄여야 합니다.

Exchange 2000 Server에서 가상 메모리 제한의 영향으로 인한 최적의 방법은 다른 저장소 그룹을 만들기 전에 저장소 그룹을 5개의 데이터베이스로 채우는 것입니다. Exchange Server 2003에서 이와 같은 제한은 감소로 간주되었고, 최적의 방법은 최대 수의 저장소 그룹이 만들어질 때까지 각 새 데이터베이스에 추가 저장소 그룹을 추가하는 것입니다. Exchange 2007에서는 Exchange Server가 사용하는 기본 데이터베이스 엔진인 ESE(Extensible Storage Engine)의 향상을 위해 I/O 사용 공간은 감소합니다.

핵심 Extensible Storage Engine 향상

ESE에서 여러 주요 디자인이 변경되어 Exchange 2007은 전반적으로 Exchange Server의 I/O 사용 공간을 줄입니다.

  • 64비트 운영 체제와 64비트 Exchange Server 응용 프로그램에서는 총 시스템 메모리에 따라 900MB부터 잠재적으로 수십 기가바이트까지의 훨씬 큰 데이터베이스 캐시 사용이 가능합니다.

  • 데이터베이스 읽기 작업도 많은 새 캐시 최적화로부터 혜택을 받습니다. 64KB에서 1MB 이상의 I/O 병합 증가는 보다 큰 I/O를 읽고 쓸 수 있는 기회를 늘리므로써 디스크 I/O를 감소시킵니다.

  • 스트리밍 데이터베이스 파일도 없으며 IFS(Installable File System)는 제거되었습니다.

64비트 응용 프로그램인 Exchange 2007에는 32비트 프로세서의 가상 메모리 제한이 없습니다. Exchange 2007 사서함 서버는 최대 50개의 데이터베이스와 50개의 저장소 그룹을 지원하고, 저장소 그룹에는 최대 5개의 데이터베이스를 배치할 수 있습니다. 그러나 각 Exchange 2007 사서함 서버에는 최대 50개의 데이터베이스를 보유할 수 있습니다.

각 저장소 그룹은 별도의 트랜잭션 로그를 만드는 데 이는 백업 및 복원의 기본 단위입니다. Cache Pressure가 없는 경우 ESE가 데이터베이스에 데이터를 쓰기 전에 ESE가 트랜잭션 로그에 쓸 수 있는 최대 데이터 양은 검사점 깊이라고 하는 캐시입니다. 저장소 그룹에서 데이터베이스 하나를 사용하여 전체 검사점 깊이를 해당 데이터베이스로 할당합니다. 이렇게 하면 데이터베이스 페이지에 대한 여러 업데이트가 캐시로 수행될 가능성이 높아지고 마지막 업데이트만이 데이터베이스에 기록되므로 I/O가 줄어듭니다.

Exchange 사서함 데이터 구성 요소

다음 표에서는 사서함 서버 역할 활동과 각 활동이 디스크 I/O에 미치는 영향에 대해 설명합니다.

Exchange 2007에서의 사서함 서버 역할 활동

활동 활동이 디스크 I/O에 영향을 미치는 방식

ESE 데이터베이스(.edb 파일)

사서함 서버는 ESE 데이터베이스에 모든 메일을 저장합니다. I/O 병합으로 I/O가 더 커질 수 있지만, ESE 데이터베이스는 무작위로 액세스되고 8KB 페이지 크기를 사용합니다. 안정성을 위해 그리고 경우에 따라 성능 상의 이유로 데이터베이스는 트랙잭션 로그를 포함하지 않는 디스크에 있어야 합니다.

트랜잭션 로그 파일(.log 파일)

데이터베이스의 모든 변경 내용은 디스크에 순차적으로 쓰여지는 트랜잭션 로그로 먼저 커밋됩니다. 쓰기는 512바이트부터 로그 버퍼 크기까지 크기가 다양합니다.

콘텐츠 인덱싱

콘텐츠 인덱싱은 데이터베이스와 같은 LUN에 있어야 하는 임의의 작업 부하이며 일반적으로 데이터베이스 크기의 약 5%를 차지합니다. 콘텐츠 인덱싱은 도착하는 대로 메시지를 인덱싱하면서 백그라운드로 실행되므로 디스크 I/O의 영향은 미미합니다.

페이징

프로세스가 메모리에 저장된 페이지를 요청하고 해당 시스템이 요청된 위치의 페이지를 찾을 수 없을 때 페이지 오류가 발생합니다. 해당 페이지가 메모리 어딘가에 있다면 이 오류는 소프트 페이지 오류입니다. 페이지가 디스크에서 검색되어야 한다면 이 오류는 하드 페이지 오류입니다. 대부분의 프로세서는 결과 없이 많은 양의 소프트 페이지 오류를 처리할 수 있습니다. 그러나 하드 페이지 오류는 지연을 야기할 수 있습니다. 지속적인 빠른 속도의 디스크 페이징은 메모리가 부족하다는 것을 나타냅니다.

콘텐츠 변환

Exchange에서 데이터를 저장할 때는 기본적으로 TNEF(Transport Neutral Encapsulating Format)로 캡슐화된 MAPI 메시지를 사용합니다. 그러면 SMTP를 통해 MAPI 메시지를 전송할 수 있으며, Microsoft Outlook 같은 MAPI 클라이언트에 MAPI 메시지가 제공됩니다. 비 MAPI 클라이언트에서는 MIME 형식 메시지를 사용해야 합니다. 이 형식에서는 Exchange가 콘텐츠를 TNEF/MAPI에서 MIME 형식으로 변환하는 프로세스를 수행해야 합니다. 대부분의 콘텐츠 변환은 클라이언트 액세스 서버 및 허브 전송 서버에서 수행됩니다.

그러나 Microsoft Entourage 같은 레거시 WebDAV(Web Distributed Authoring and Versioning) 응용 프로그램은 사서함 서버에 직접 액세스합니다. 이러한 시나리오에서는 콘텐츠 변환 프로세스가 Exchange 2007 사서함 서버에서 직접 수행됩니다. 레거시 WebDAV 클라이언트가 클라이언트 액세스 서버에서 변환해야 하는 데이터를 요청하면, /Exchange 가상 디렉터리에 액세스하여 Exchange 2007 사서함 서버에서 데이터에 액세스됩니다. /ExAdmin 가상 디렉터리에 액세스하여 데이터에 액세스하는 도구도 있습니다. 데이터는 사서함 서버의 Tmp 디렉터리에서 변환된 후에 클라이언트 액세스 서버로 전송됩니다.

Tmp 디렉터리는 비 MAPI 클라이언트 사용자를 새 서버로 이동한 후에 종종 가장 많이 사용됩니다. 이는 사용자가 자신의 사서함에 처음 연결할 때 많은 양의 콘텐츠를 변환하기 때문입니다.

성능을 향상시키려면 Tmp 디렉터리는 페이지 파일 또는 운영 체제와 동일한 LUN에 있어서는 안 됩니다.

데이터베이스 유지 관리

Exchange 2007 정보 저장소는 각 데이터베이스에 대해 실행할 수 있도록 정기적인 온라인 유지 관리가 필요합니다. 디스크 I/O에 영향을 주는 두 가지 작업은 구성된 보존 정책보다 오래된 메시지와 사서함의 강제 삭제와 데이터베이스의 온라인 조각 모음입니다. 데이터베이스 백업은 수행 중인 데이터베이스의 온라인 조각 모음을 중단할 수 있으므로 백업 및 데이터베이스 유지 관리에 모두 해당 작업을 완료할 독점적 시간을 제공하도록 주의해야 합니다.

백업 및 복원

데이터 백업 프로세스에서는 데이터가 데이터베이스 및 트랜잭션 로그 파일 볼륨에서 읽혀져야 합니다. 이러한 추가 I/O는 사용자 응답 시간에 영향을 줄 수 있으므로 업무 시간 중에는 피해야 합니다. 소프트 복구 프로세스에서는 ESE가 모든 트랜잭션 로그 파일을 재생해야 합니다. 이로 인해 I/O 프로필은 순차적 읽기 스트림이 됩니다. 그러므로 트랜잭션 로그 파일이 고속 순차 디스크 액세스 기능을 가진 디스크에 있다면 복구 성능이 향상됩니다. VSS (볼륨 섀도 복사본 서비스) 기반 백업을 데이터베이스의 활성 복사본에서 데이터베이스의 수동 복사본으로 오프로드하는 데 사용되는 연속 복제를 사용하면 이 경우를 방지할 수 있습니다.

삭제된 데이터베이스 페이지 소거

삭제된 데이터베이스 페이지는 소거되도록 사서함 서버를 구성하면 데이터베이스의 항목을 삭제할 때마다 여러 페이지가 삭제됩니다. 그런 다음 Exchange에서는 삭제된 페이지를 소거합니다. RTM 버전의 Microsoft Exchange Server 2007에서 이 기능은 온라인 스트리밍 백업 동안에만 실행되므로 백업 시 실제 디스크 I/O가 더 많이 발생됩니다. Exchange Server 2007 SP1(서비스 팩 1)에서는 온라인 유지 관리 창에서 이 기능을 사용할 수 있습니다.

데이터베이스 파일 액세스 이외에도 디스크 I/O를 발생시키는 다른 활동들이 있습니다. 다음 표에는 이러한 활동과 디스크 I/O에 미치는 영향이 나열되어 있습니다.

디스크 I/O에 영향을 주는 기타 활동

활동 활동이 디스크 I/O에 영향을 미치는 방식

폴더 내 항목 수

핵심 사서함 폴더의 항목 수가 늘어날수록 Outlook 온라인 모드 사용자의 작업 수행을 위한 실제 디스크 비용도 늘어납니다. 캐시된 Exchange 모드에서 Outlook을 사용하면 색인 및 검색 작업이 클라이언트에서 수행됩니다. 받은 편지함을 크기별로 처음 정렬하려면 색인을 새로 만들어야 하는데 이 때 많은 디스크 I/O가 발생하게 됩니다. 그 이후에 받은 편지함을 크기별로 정렬하면 비용이 훨씬 줄어듭니다. 정적 색인 수가 사용되므로 종종 여러 가지 방법으로 폴더를 정렬하는 사용자의 경우 이 한계를 초과해 추가 디스크 I/O를 발생시킬 수 있습니다.

BlackBerry

BlackBerry 및 Exchange 2007에 대한 자세한 내용은 RIM(Research In Motion) 웹 사이트에서 BlackBerry Enterprise Server for Microsoft Exchange 웹 페이지의 성능 벤치마킹 지침을 참조하십시오.

참고

UNRESOLVED_TOKEN_VAL(exNote3rdPartyURL)

공용 폴더

서버에 공용 폴더가 있으면 추가 I/O 로드가 발생됩니다. 하지만 폴더 콘텐츠의 복제가 서버에 없는 경우에는 공용 폴더 데이터베이스 소유로 인해 발생되는 I/O가 사용자 사서함 액세스로 인해 발생되는 I/O보다 중요하지 않습니다.

백업

사서함 백업은 신중하게 계획해야 합니다. 다음 섹션에서는 VSS 및 스트리밍 온라인 백업에 대한 일부 고려 사항을 설명합니다. 비용, 시간 및 안정성과 같은 변수에 영향을 주는 모든 솔루션에는 절충 요소가 있습니다. 대부분의 관리자는 온라인 데이터베이스 유지 관리, 조각 모음 및 운영 체제 유지 관리에 시간을 정의하는 데 이러한 활동은 백업 시간과 경쟁 관계에 있습니다. 백업, 유지 관리 및 프로덕션 로드 간의 균형을 유지하려면 특별한 주의가 필요합니다. 사서함이 클수록 SLA 내에서 전체 백업 전략을 매일 이행하는 것이 불가능할 수 있습니다. 야간의 전체 백업으로 발생하는 여파를 줄일 수 있는 일반적인 전략은 전체 백업은 주 단위로 수행하고 차등 백업을 매일 수행하는 것입니다. 이와 같은 전략을 사용하면 전체 백업을 복원하고, 마지막 차등 백업을 복원하는 작업이 필요합니다.

볼륨 섀도 복사본 서비스

Exchange 2003의 VSS 기본 및 VSS 최적의 방법에 대한 자세한 내용은 Exchange Server 2003의 볼륨 섀도 복사본 서비스 사용에 대한 모범 사례을 참조하십시오. 기사에서 다룬 정보 외에 Exchange 2007에서 반드시 고려해야 VSS 관련 사항이 두 가지 있습니다.

  • 대용량 사서함

  • CCR 및 LCR 복사본 백업 능력

VSS 백업은 프로덕션 또는 복사본 데이터 중 어디에서도 가능하지만, 복사본을 백업하고 프로덕션의 실제 디스크에 영향을 주지 않는 것이 좋습니다.

LCR의 경우 Exchange 2007은 동일한 서버에서 별도의 디스크로 트랜잭션 로그를 복제합니다. 복사본에서 VSS 복제본을 사용하면 복사본 저장소는 다른 실제 디스크에 구성되어야 하고 복제 작업과 체크섬 무결성은 프로덕션의 실제 디스크에는 영향을 미치지 않습니다. 복사본의 VSS 스냅샷의 경우 복사본 저장소는 다른 실제 디스크에 구성되어야 하고 테이프에 복사되는 체크섬 무결성과 연속 스트리밍은 프로덕션의 실제 디스크에는 영향을 미치지 않습니다.

CCR의 경우 Exchange 2007은 별도의 서버에 트랜잭션 로그를 복제합니다. 이 서버는 클러스터에 있는 노드이지만 대상 복사본은 공유 저장소에 보관되지 않습니다. VSS 복제본을 사용하면 다른 실제 디스크를 사용하는 수동 노드의 복사본에 체크섬 무결성을 실행함으로써 백업 프로세스를 격리합니다. VSS 스냅샷을 사용하면 테이프에 대한 체크섬 무결성과 연속 스트리밍이 사용자의 프로덕션 서버나 실제 디스크에 영향을 미치지 않습니다.

스트리밍 온라인 백업

하드웨어 기반 VSS 백업과 달리 일반적으로 데이터는 저장소 기기 내에서 이동하며 스트리밍 백업을 사용하면 해당 서버가 데이터 이동을 담당합니다. 모든 페이지는 백업 중에 확인되므로 체크섬 무결성 프로세스의 성능 영향은 문제가 되지 않습니다. 동시 백업의 경우 여러 개의 스트림은 기가바이트 이더넷 또는 파이버 채널에 연결된 테이프이든지 백업 매체의 제한에 영향을 줄 수 있습니다. 대부분의 고객의 경우 스트리밍 백업 매체의 분당 처리량으로 나눠지는 백업 SLA 기간이 저장소 그룹의 허용 가능한 크기를 제한합니다. 예를 들어, 저장소 그룹에 한 시간의 SLA가 있으면 초당 100MB를 백업할 수 있고 최대 저장소 그룹 크기는 360GB가 됩니다.

클라이언트 액세스 서버

클라이언트 액세스 서버는 사서함 서버(다른 실제 서버에 역할이 설치되었다고 가정)에서 상태가 저장되지 않은 많은 작업을 오프로드하고 사서함 서버 종류와 상관없이 사용자가 단일 이름을 가리키기만 하면 되는 통합된 네임스페이스를 제공합니다. IMAP4(Internet Message Access Protocol 4), POP3(Post Office Protocol 3) 및 HTTP 등의 인터넷 프로토콜은 클라이언트 액세스 서버에서 서비스합니다. Outlook Anywhere, ActiveSync, 자동 검색 서비스, 가용 서비스 및 웹 서비스는 클라이언트 액세스 서버에서 서비스하는 기능의 다른 예입니다.

클라이언트 액세스 서버는 CPU, 메모리 및 네트워크 병목 현상의 영향을 받을 수 있지만, 작은 디스크 I/O 사용 공간을 차지합니다. Exchange 2003과 Exchange 2000를 실행하는 프런트 엔드 서버에서 잠재적인 디스크 I/O 고려 사항인 SMTP(Simple Mail Transfer Protocol) 트래픽은 이제 허브 전송 서버와 Edge 전송 서버에서 별도로 담당합니다.

다음 표에서는 클라이언트 액세스 서버 역할 활동과 각 활동이 디스크 I/O에 미치는 영향에 대해 설명합니다.

Exchange 2007에서의 클라이언트 액세스 서버 역할 활동

활동 활동이 디스크 I/O에 영향을 미치는 방식

프로토콜 로깅

프로토콜 로깅은 사용하도록 설정된 경우 성능 문제를 일으키는 순차적 쓰기이며 로그를 저장하기 위해 디스크 공간을 차지합니다. 선택한 프로토콜 기록을 로그에 남기면 해당 프로토콜이 예상대로 작업을 수행하는지 또는 통신 문제를 겪고 있는지 확인할 수 있고 인터넷으로부터 발생하는 공격을 식별할 수 있습니다.

콘텐츠 변환

모든 Exchange 2007 프로토콜의 콘텐츠 변환은 클라이언트 액세스 서버에서 발생합니다. 레거시 Outlook Web Access 클라이언트에 대한 레거시 WebDAV 콘텐츠 변환은 Exchange 2003 사서함 서버에서 발생합니다. 클라이언트가 클라이언트 액세스 서버에서 변환해야 할 데이터를 요청하면 해당 데이터는 Exchange 2003 사서함 서버에서 액세스되어 사서함 서버의 TMP 폴더에서 변환된 후 클라이언트 액세스 서버로 전송됩니다. 성능을 향상시키려면 TMP 폴더는 페이지 파일과 운영 체제와 동일한 LUN에 있어서는 안 됩니다.

페이징

프로세스가 메모리에 저장된 페이지를 요청하고 해당 시스템이 요청된 위치의 페이지를 찾을 수 없을 때 페이지 오류가 발생합니다. 해당 페이지가 메모리 어딘가에 있다면 이 오류는 소프트 페이지 오류입니다. 페이지가 디스크에서 검색되어야 한다면 이 오류는 하드 페이지 오류입니다. 대부분의 프로세서는 결과 없이 많은 양의 소프트 페이지 오류를 처리할 수 있습니다. 그러나 하드 페이지 오류는 지연을 야기할 수 있습니다. 지속적인 빠른 속도의 디스크 페이징은 메모리가 부족하다는 것을 나타냅니다.

클라이언트 액세스 서버에서 디스크 I/O가 문제가 되는 시나리오는 사용자가 인터넷 클라이언트를 사용하여 POP3 또는 IMAP4 프로토콜을 통해 사서함 데이터에 액세스하는 경우입니다. 전송 엔진이 들어오는 메일을 모두 MAPI로 변환하므로 POP3 또는 IMAP4 클라이언트에서는 해당 콘텐츠를 MIME(Multipurpose Internet Mail Extensions) 형식으로 다시 변환해야 클라이언트로 보낼 수 있습니다. 이러한 변환 작업은 클라이언트 액세스 서버에서 수행되며 메시지가 64KB보다 크면 디스크에서 수행됩니다. 대부분의 사용자가 POP3 또는 IMAP4를 사용하는 경우 변환이 수행되는 임시 폴더를 전용 고속 디스크에 배치해야 합니다.

전송 서버

허브 전송 서버와 Edge 전송 서버는 Exchange 2007의 브리지헤드 및 게이트웨이 서버입니다. 두 서버의 주요 임무는 메일을 주고받는 것입니다. 대부분의 비즈니스에서 전송 서버는 다음의 두 그룹으로 배포됩니다.

  • 스팸 방지 및 바이러스 백신 보호(Edge 전송 서버)

  • 라우팅(허브 전송 서버)

Edge 전송 서버가 기본으로 담당하는 작업은 스팸 메일 또는 바이러스를 포함한 들어오는 메일로부터 Exchange 인프라를 보호하는 것입니다. 이를 통해 허브 전송 서버는 안전한 메일을 분류하여 올바른 메일 서버로 배달합니다. 이러한 서버에 저장소가 미치는 영향은 초당 처리하는 메시지 수와 메시지의 평균 크기에 따라 달라집니다.

다음 표에서는 Edge 전송 서버 및 허브 전송 서버 활동을 비롯하여 각 활동이 디스크 I/O에 영향을 미치는 방식에 대해 설명합니다.

Exchange 2007에서의 Edge 전송 및 허브 전송 서버 역할 활동

활동 활동이 디스크 I/O에 영향을 미치는 방식

ESE 데이터베이스(mail.que 파일)

Exchange 2007 Edge 전송 서버와 허브 전송 서버 모두 ESE 데이터베이스에 모든 메일을 저장합니다. ESE 데이터베이스는 무작위로 액세스되고 8KB 페이지 크기를 사용합니다. 안정성을 위해 그리고 경우에 따라 성능 상의 이유로 데이터베이스는 트랙잭션 로그와 다른 별도의 디스크에 있어야 합니다.

트랜잭션 로그 파일(.log 파일)

데이터베이스의 모든 변경 내용은 디스크에 순차적으로 쓰여지는 트랜잭션 로그로 먼저 커밋됩니다. 쓰기는 512바이트부터 로그 버퍼 크기까지 크기가 다양합니다.

프로토콜 로깅 및 메시지 트래킹 로그

메시지 트래킹과 프로토콜 로깅은 사용하도록 설정된 경우 디스크 성능 문제를 일으키는 순차적 쓰기로서 로그를 저장하기 위해 디스크 공간을 차지합니다. 선택한 프로토콜 기록을 로그에 남기면 해당 프로토콜이 예상대로 작업을 수행하는지 또는 통신 문제를 겪고 있는지 확인할 수 있고 인터넷으로부터 발생하는 공격을 식별할 수 있습니다.

콘텐츠 변환

허브 전송 서버에서는 인터넷에서 들어오는 메일은 배달되기 전에 MAPI로 변환됩니다. 콘텐츠 변환 프로세스는 TMP 폴더에서 발생합니다. 성능을 향상시키려면 TMP 폴더는 페이징 파일 및 운영 체제와 동일한 LUN에 있어서는 안 됩니다.

페이징

프로세스가 메모리에 저장된 페이지를 요청하고 해당 시스템이 요청된 위치의 페이지를 찾을 수 없을 때 페이지 오류가 발생합니다. 해당 페이지가 메모리 어딘가에 있다면 이 오류는 소프트 페이지 오류입니다. 페이지가 디스크에서 검색되어야 한다면 이 오류는 하드 페이지 오류입니다. 대부분의 프로세서는 결과 없이 많은 양의 소프트 페이지 오류를 처리할 수 있습니다. 그러나 하드 페이지 오류는 지연을 야기할 수 있습니다. 지속적인 빠른 속도의 디스크 페이징은 메모리가 부족하다는 것을 나타냅니다.

에이전트

전송 서버의 사용자 지정은 공용 언어 런타임 환경에서 실행되고 이벤트에 의해 트리거되는 에이전트라고도 하는 코드를 통해 수행됩니다. 일부 에이전트는 디스크 성능에 적중하여 로그를 저장하기 위해 디스크 공간을 차지하는 데이터를 기록합니다.

통합 메시징 서버

통합 메시징 서버 크기 조정에 대한 자세한 내용은 Determining the Number of Users an Exchange 2007 Unified Messaging Server Can Support를 참조하십시오.

참고

UNRESOLVED_TOKEN_VAL(exBlog)