데이터베이스와 로그 성능 요소 이해

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2016-11-28

이 항목에서는 Microsoft Exchange Server 2010의 데이터베이스 및 로그 I/O 성능 요소에 대해 설명합니다. 이러한 요소를 이해하는 것은 사서함 서버 저장소 디자인 솔루션에 중요합니다. 디자인 프로세스의 다른 주요 요소에 대한 자세한 내용은 사서함 서버 저장소 디자인을 참조하십시오.

목차

트랜잭션 I/O

IOPS 이해

비트랜잭션 I/O

트랜잭션 I/O

트랜잭션 I/O는 일반적으로 사용자 작업에 의해 생성되는 I/O로 정의됩니다. 사용자 작업의 예에는 항목 받기, 보내기 및 삭제, Windows Mobile 클라이언트 동기화 및 Microsoft Office Outlook Web App을 통한 로그온이 포함됩니다.

I/O 대기 시간(I/O 작업을 실행하는 데 걸리는 시간)이 Microsoft Outlook 온라인 모드 및 Outlook Web App와 같은 온라인 클라이언트의 사용자 경험에 직접 영향을 줄 수 있으므로 트랜잭션 I/O는 Exchange 2010 저장소 설계에 있어 중요한 부분입니다. Outlook의 캐시된 Exchange 모드도 또한 대리인 액세스 및 규칙 구성 등의 작업에 사용될 경우 긴 I/O 대기 시간에 의해 영향을 받을 수 있습니다. 모든 클라이언트는 긴 대기 시간 I/O로 인한 전자 메일 배달 지연에 의해 영향을 받을 수 있습니다. 트랜잭션 I/O는 데이터베이스 볼륨 I/O 및 로그 볼륨 I/O로 나눌 수 있습니다.

Exchange 2010의 트랜잭션 I/O 요구 사항은 Exchange Server 2007의 요구 사항보다 줄어들었습니다. 사서함 데이터베이스 및 로그 볼륨에 대해 발생하는 I/O 중 일부는 트랜잭션으로 간주되지 않습니다. 자세한 내용은 Exchange 2010 저장소 이해를 참조하십시오.

맨 위로 이동

IOPS 이해

Exchange의 모든 버전에서 각 사용자가 사용하는 초당 데이터베이스 I/O(IOPS)의 크기를 이해하는 것이 중요합니다. 왜냐 하면 저장소 크기를 적절히 지정하는 데 필요한 주요 트랜잭션 I/O 메트릭 중 하나이기 때문입니다. 다음 섹션에서는 사서함 서버 역할 저장소를 설계할 때 IOPS에 영향을 주는 요소에 대해 설명합니다.

데이터베이스 캐시

64비트 버전의 Exchange 2010을 실행하는 64비트 버전의 Windows Server 운영 체제에서는 가상 주소 공간이 크게 증가하며 Exchange에서는 해당 데이터베이스 캐시를 늘리고 데이터베이스 읽기 I/O를 줄이고 서버당 데이터베이스를 최대 100개까지 사용할 수 있습니다.

데이터베이스 읽기 작업 감소는 서버에서 사용할 수 있는 데이터베이스 캐시의 양과 사용자 메시지 프로필에 따라 달라집니다. 메모리 및 데이터베이스에 대한 자세한 내용은 사서함 데이터베이스 캐시 이해를 참조하십시오. 해당 항목의 지침을 따르면 Exchange Server 2003에 비해 트랜잭션 I/O를 최대 90%까지 줄일 수 있습니다. 사용자당 데이터베이스 캐시 양은 실제 I/O를 줄이는 데 있어서 핵심적인 요소입니다.

다음 표에서는 하루 100개의 메시지를 사용하는 사용자 수에 대해 Exchange 2003의 사서함당 기본 900MB의 데이터베이스 캐시와 Exchange 2010의 사서함당 6MB의 데이터베이스 캐시를 비교할 때 사서함당 실제 데이터베이스 캐시가 증가했음을 보여줍니다. 이와 같은 Exchange 2010의 추가 데이터베이스 캐시로 인해 캐시의 읽기 횟수가 많아지므로 디스크 수준의 데이터베이스 읽기 작업이 줄어듭니다.

사서함 수를 기준으로 한 데이터베이스 캐시 크기

사서함 수 사서함당 Exchange 2003 데이터베이스 캐시(MB) 사서함당 Exchange 2010 데이터베이스 캐시(MB) Exchange 2003과 비교한 데이터베이스 캐시 증가량

4000

0.225

6

27배

2000

0.45

6

13배

1000

0.9

6

7배

500

1.8

6

5배

맨 위로 이동

Exchange 2010 사서함 IOPS 프로필 결정

Exchange 2010 데이터베이스 IOPS를 예측하는 데 사용할 수 있는 가장 중요한 두 가지 요소는 각 사용자가 매일 주고받는 사용자당 데이터베이스 캐시 크기와 메시지 수입니다. 다음 표는 캐시된 Exchange 모드에서 Outlook 2010을 사용하는 표준 작업자를 기반으로 합니다. 플러스 또는 마이너스 20% 내에서 정보의 정확성이 테스트되었습니다. 다른 클라이언트 유형과 사용 시나리오에서는 부정확한 결과가 산출될 수 있습니다. 예상치는 3MB와 30MB 사이 사용자 데이터베이스 캐시 크기에 대해서만 유효합니다. 이 정보는 사용자가 매일 500개 이상의 메시지를 주고받는 시나리오에서는 유효성이 검증되지 않았습니다. 유효성 검사를 위한 평균 메시지 크기는 75KB이었지만 메시지 크기는 IOPS의 기본 요소는 아닙니다.

다음 표에서는 기본 Exchange 2010 IOPS 요구 사항을 예측하는 데 사용할 수 있는 사용자당 IOPS의 예상 값을 제공하며 모든 데이터베이스 I/O(데이터베이스, 콘텐츠 인덱싱 및 NTFS 메타데이터)가 포함되어 있습니다. 로그 볼륨 I/O는 포함되어 있지 않습니다.

메시지 활동에 기반한 사서함당 데이터베이스 캐시 및 예상 IOPS

하루에 사서함당 주고받는 메시지 수 사서함당 데이터베이스 캐시(MB) 단일 데이터베이스 복사본(독립 실행형): 사서함당 예상 IOPS 여러 데이터베이스 복사본(사서함 복구): 사서함당 예상 IOPS

50

3

0.06

0.05

100

6

0.120

0.100

150

9

0.18

0.150

200

12

0.240

0.200

250

15

0.300

0.250

300

18

0.360

0.300

350

21

0.420

0.350

400

24

0.480

0.400

450

27

0.540

0.450

500

30

0.600

0.500

사서함 복구는 Exchange 2010에 있는 통합된 고가용성 및 사이트 복구 솔루션을 나타냅니다. 자세한 내용은 고가용성 및 사이트 복구 이해를 참조하십시오.

맨 위로 이동

데이터베이스 볼륨 I/O

데이터베이스 볼륨 I/O는 데이터베이스 파일(.edb) 읽기/쓰기 작업, 콘텐츠 인덱싱 읽기/쓰기 작업 및 NTFS 메타데이터 읽기/쓰기 작업과 연결된 I/O입니다.

Exchange 2003에서 데이터베이스 읽기/쓰기 비율은 보통 2:1(읽기 66%)입니다. Exchange 2010에서 데이터베이스 캐시가 커지면 디스크의 데이터베이스에 대한 읽기 횟수가 감소하여 읽기가 전체 I/O의 비율로 줄어듭니다.

권장되는 메모리 지침을 따르면 활성 데이터베이스 복사본에 대한 다음 I/O 비율이 나오는 것으로 예상할 수 있습니다. 메모리 지침에 대한 자세한 내용은 메모리 구성 및 Exchange 성능 이해를 참조하십시오. 이 측정에는 모든 데이터베이스 볼륨 I/O(데이터베이스, 콘텐츠 인덱싱 및 NTFS 메타데이터)가 포함되며 로그 볼륨 I/O는 포함되지 않습니다.

사서함 데이터베이스 I/O 읽기/쓰기 비율

하루에 사서함당 주고받는 메시지 수 독립 실행형 데이터베이스 사서함 복구에 참여하는 데이터베이스

50

1:1

3:2

100

1:1

3:2

150

1:1

3:2

200

1:1

3:2

250

1:1

3:2

300

2:3

1:1

350

2:3

1:1

400

2:3

1:1

450

2:3

1:1

500

2:3

1:1

예를 들어, 3개의 데이터베이스 복사본을 유지 관리하는 DAG(데이터베이스 가용성 그룹) 내의 사서함 서버에서 24,000개의 사서함을 배포하는 경우 각 데이터베이스의 읽기 대 쓰기 비율은 3:2입니다. 즉, 데이터베이스를 호스트하는 LUN(논리 단위 번호)에 대한 모든 I/O의 60%는 읽기 I/O입니다.

전체 I/O 비율에서 쓰기 값이 더 크면 RAID(Redundant Array of Independent Disks)를 선택할 때 쓰기와 관련한 비용이 많이 드는 RAID5나 RAID6 등의 RAID 형식을 선택하는 경우 문제가 될 수 있습니다. 서버에 사용할 적절한 RAID 솔루션을 선택하는 방법에 대한 자세한 내용은 저장소 구성 이해를 참조하십시오.

사서함 서버당 IOPS 계산

Exchange 2010에서 사서함 서버당 IOPS를 계산하려면 다음과 같은 이유로 인해 이전 버전의 Exchange보다 더 많은 단계가 필요합니다.

  • 이제 동일한 볼륨에서 데이터베이스와 로그를 결합할 수 있습니다.

  • 동일한 서버에서 활성 및 수동 데이터베이스 복사본을 모두 호스트할 수 있습니다.

  • 순차 I/O 백그라운드 작업(예: 백그라운드 데이터베이스 유지 관리)의 추가

저장소 하위 시스템은 임의 I/O보다 훨씬 더 효율적으로 순차 I/O를 처리할 수 있기 때문에 단순 순차 I/O 작업이 사서함 서버당 IOPS 계산에서 고려되지 않습니다. 이러한 작업에는 백그라운드 데이터베이스 유지 관리, 로그 트랜잭션 I/O 및 로그 복제 I/O가 포함됩니다.

사서함 서버당 IOPS는 저장소가 설계된 방식에 따라 약간 다르게 계산됩니다.

  • 데이터베이스 파일과 로그 파일이 단일 볼륨 공유

  • 데이터베이스 파일이 트랜잭션 로그 파일과 다른 디스크 볼륨에 저장됨

두 가지 저장소 설계에서 모두 성능 모니터(perfmon.exe)를 사용하여 5초 샘플링 간격으로 사용량이 가장 많은 두 시간을 측정합니다. 이 시간은 시스템에서 클라이언트 작업에 의해 가장 많은 로드가 생성되는 시간입니다(예: 오전 10시 - 오후 12시). 이 시간의 사용률은 10시간인 하루 근무 시간 평균 사용률의 두 배에 달하기도 합니다(최대:평균 비율 = 2:1).

사서함 서버당 IOPS: 데이터베이스 파일과 로그 파일이 단일 볼륨 공유

이 구성에서 데이터베이스 파일 및 로그 파일은 동일한 디스크 볼륨에 저장됩니다. 이 예에서는 각 데이터베이스가 전용 디스크로 지원되는 다른 볼륨에 있다고 가정합니다. 이전 섹션에서 설명한 수집된 성능 모니터 로그의 모든 데이터베이스에 대해 다음 표를 채우십시오.

데이터베이스 이름 논리 디스크 -> 디스크 읽기 수/초 논리 디스크 -> 디스크 쓰기 수/초 MSExchange DatabaseInstances ->데이터베이스 유지 관리 IO 읽기 수/초 MSExchange DatabaseInstances ->I/O 데이터베이스 읽기 수(복구)/초 MSExchange DatabaseInstances ->I/O 데이터베이스 쓰기 수(복구)/초 MSExchange DatabaseInstances ->IO 로그 쓰기 수/초

데이터베이스 1

            

데이터베이스 2

            

데이터베이스 3

            

데이터베이스 4

            

추가 데이터베이스

            

전체

            

각 열의 합계를 더하고 다음 계산을 수행하여 사서함 서버당 IOPS를 결정합니다.

계산 요약: 논리 디스크 IO의 합계 - (데이터베이스 유지 관리 IO + 복구 (로그 재생) IO + 로그 IO의 합계)/성능 모니터 로그 측정 동안 서버당 호스트된 사서함 수

계산 세부 정보: ((논리 디스크 -> 디스크 읽기 수/초 + 논리 디스크 ->디스크 쓰기 수/초) - (MSExchange 데이터베이스 ==> 인스턴스 -> 데이터베이스 유지 관리 I/O 읽기 수/초 + MSExchange 데이터베이스 ==> 인스턴스 -> I/O 데이터베이스 읽기 수(복구)/초 + MSExchange 데이터베이스 ==> 인스턴스 -> I/O 데이터베이스 쓰기 수(복구)/초+ MSExchange 데이터베이스 ==> 인스턴스 -> I/O 로그 쓰기 수/초))/ 성능 모니터 로그 측정 동안 서버당 호스트된 사서함 수 = 사서함 서버당 IOPS

맨 위로 이동

IOPS/사서함: 전용 데이터베이스 파일 볼륨

이 구성에서 데이터베이스 파일은 트랜잭션 로그 파일과 다른 디스크 볼륨에 저장됩니다. 이 예에서는 각 데이터베이스가 전용 디스크로 지원되는 다른 볼륨에 있다고 가정합니다. 이전 섹션에서 설명한 수집된 Perfmon 로그의 모든 데이터베이스에 대해 다음 표를 채우십시오.

데이터베이스 이름 논리 디스크 -> 디스크 읽기 수/초 논리 디스크 -> 디스크 쓰기 수/초 MSExchange 데이터베이스 ==> 인스턴스 ->데이터베이스 유지 관리 IO 읽기 수/초 MSExchange 데이터베이스 ==> 인스턴스 ->I/O 데이터베이스 읽기 수(복구)/초 MSExchange 데이터베이스 ==> 인스턴스 ->I/O 데이터베이스 쓰기 수(복구)/초

데이터베이스 1

          

데이터베이스 2

          

데이터베이스 3

          

데이터베이스 4

          

추가 데이터베이스

          

전체

          

참고

기본적으로 MSExchange 데이터베이스 ==> 인스턴스 ->데이터베이스 유지 관리 IO 읽기/초 성능 카운터는 Exchange 2010에서 보이지 않습니다. 이 카운터를 보려면 사용하도록 설정해야 합니다. 이 성능 카운터를 사용하도록 설정하는 방법에 대한 자세한 내용은 확장된 ESE 성능 카운터 사용 설정 방법을 참조하십시오.

사서함 서버당 IOPS를 결정하려면 각 열의 합계를 더하고 다음 계산을 수행합니다.

계산 요약: 논리 디스크 IO의 합계 - (데이터베이스 유지 관리 IO + 복구 (로그 재생) IO의 합계)/Perfmon 로그 측정 동안 서버당 호스트된 사서함 수

계산 세부 정보: ((논리 디스크 -> 디스크 읽기 수/초 + 논리 디스크 ->디스크 쓰기 수/초) - (MSExchange 데이터베이스 ==> 인스턴스 -> 데이터베이스 유지 관리 IO 읽기 수/초 + MSExchange 데이터베이스 ==> 인스턴스 -> I/O 데이터베이스 읽기 수(복구)/초 + MSExchange 데이터베이스 ==> 인스턴스 -> I/O 데이터베이스 쓰기 수(복구)/초))/ 성능 모니터 로그 측정 동안 서버당 호스트된 사서함 수 = 사서함 서버당 IOPS

기본 IOPS 측정

이전 버전의 Exchange를 사용 중인 경우 기본 IOPS를 계산했다면 Exchange 2010에서 기본 IOPS가 다음과 같은 방식으로 영향을 받는다는 점에도 주의해야 합니다.

  • 서버의 사용자 수는 사용자당 전체 데이터베이스 캐시에 영향을 줍니다.

  • RAM 크기는 데이터베이스 캐시가 커질 수 있는 크기에 영향을 주며 데이터베이스 캐시가 커지면 캐시 읽기 횟수가 많아지므로 데이터베이스 읽기 I/O가 즐어듭니다.

이 프로세스의 요점은 특정 서버의 IOPS가 엔터프라이즈 전체를 계획하기에 부족한 정보라는 것입니다. 이는 RAM 크기, 사용자 수, 데이터베이스 수가 서버마다 다르기 때문입니다. 실제 IOPS 수치가 나오면 항상 계산된 값에 20%의 I/O 오버헤드 요소를 적용하여 예약 용량을 추가해야 합니다. 이전보다 작업이 많아졌다고 해서 사용자 환경 전체의 성능이 저하되어서는 안 되기 때문입니다.

데스크톱 검색 엔진 및 Outlook 온라인 모드 클라이언트

캐시된 Exchange 모드 클라이언트와 달리 모든 온라인 모드 클라이언트 작업은 데이터베이스에 대해 발생합니다. 저장소 스키마 및 ESE(Extensible Storage Engine)가 변경됨에 따라 Outlook 온라인 모드 클라이언트는 이제 Outlook 캐시된 Exchange 모드 클라이언트와 동일한 I/O 프로필을 생성합니다.

사서함 검색 기능과 관련하여 최종 사용자는 다음과 같은 두 가지 옵션이 있습니다.

  • 사서함 서버에서 사용 가능한 기본 제공 콘텐츠 인덱스를 사용할 수 있습니다.

  • 데스크톱 검색 엔진 클라이언트를 설치할 수 있으며, 로컬 인덱스가 사서함 데이터의 클라이언트에 생성되도록 하고, 로컬 검색을 수행할 수 있습니다.

Outlook 온라인 모드로 데스크톱 검색 엔진 클라이언트를 사용하는 최종 사용자에게 데이터베이스에 대한 추가 읽기 I/O 작업이 발생할 수 있습니다. 현재 추가 읽기 I/O를 발생시키지 않는 것으로 알려진 유일한 데스크톱 검색 엔진은 Windows 데스크톱 검색 4.0입니다. Windows 데스크톱 검색 4.0은 Outlook 캐시된 Exchange 모드 동기화 프로토콜이 사서함 콘텐츠를 인덱싱하는 방법과 유사한 동기화 프로토콜을 사용합니다.

따라서 Windows 데스크톱 검색 4.0이 아닌 데스크톱 검색 엔진을 사용하여 Outlook 온라인 모드 클라이언트를 배포하려는 경우 다음 지침을 따르십시오.

  • 256MB 온라인 모드 클라이언트는 캐시된 Exchange 모드 클라이언트와 비교했을 때 데이터베이스 읽기 작업을 1.5배 증가시킵니다. 256MB 미만인 경우 거의 영향을 주지 않습니다.

  • 사서함 크기가 두 배가 되면 데이터베이스 읽기 IOPS도 두 배가 됩니다(주요 폴더 간의 동등 항목 배포가 동일하게 유지된다고 가정).

이 데이터의 결과에 따라 다음과 같은 두 가지 권장 사항이 있습니다.

  • 캐시된 Exchange 모드 클라이언트를 배포합니다(해당되는 경우). 자세한 내용은 이 항목 뒷부분의 "폴더당 항목 수" 섹션을 참조하십시오. 그렇지 않으면 데스크톱 검색 엔진을 Windows 데스크톱 검색 4.0으로 바꿉니다.

  • 데이터베이스 저장소를 설계할 때 I/O 요구 사항을 고려합니다.

타사 클라이언트와 같은 추가 IOPS 요소에 대한 자세한 내용은 Exchange Server 2003의 저장소 최적화를 참조하십시오.

맨 위로 이동

로그 볼륨 I/O

로그 볼륨 I/O는 데이터베이스 로깅 읽기/쓰기 작업 및 NTFS 메타데이터 읽기/쓰기 작업과 연결된 I/O입니다. 로그 볼륨 I/O는 순차적이며 배터리 지원 쓰기 캐싱 배열 컨트롤러 사용 시 로그 볼륨 I/O의 I/O 오버헤드가 최소한으로 유지되며 Exchange 저장소 크기 조정에 중요한 요소가 아닙니다.

Exchange 2010에서는 데이터베이스 읽기 수가 감소할 뿐 아니라 로그 파일 크기가 작아지고 더 많은 데이터베이스를 사용할 수 있으므로 로그 대 데이터베이스 쓰기가 독립 실행형 데이터베이스의 40%이며 사서함 복구에 참여하는 데이터베이스의 50%입니다. 예를 들어, 사서함 복구에 참여하는 데이터베이스가 12개의 쓰기 I/O를 사용하는 경우 로그 LUN은 약 6개의 쓰기 I/O를 사용합니다.

사서함 복구에 참여하는 데이터베이스를 호스트하는 사서함 서버에는 연속 복제 사용과 관련된 오버헤드가 있습니다. 닫힌 트랜잭션 로그를 읽고 대상 데이터베이스 복사본으로 보내야 합니다. 이 오버헤드로 인해 사서함 서버에서 호스트되는 각 활성 데이터베이스 복사본에 대한 로그 읽기에 10%의 공간이 더 추가됩니다. 예를 들어, 사서함 서버가 10개의 활성 데이터베이스 복사본을 호스트하고 각 트랜잭션 로그 스트림이 6개의 쓰기 I/O를 생성하고 있는 경우 이러한 10개의 활성 데이터베이스 복사본(또는 총 6개의 읽기 I/O) 각각에 대해 추가적인 0.6개의 읽기 I/O를 예상할 수 있습니다.

트랜잭션 로그 I/O를 측정 또는 예측한 후에는 정상적인 경우보다 사용량이 많은 시기에 대해 적절한 공간을 제공할 수 있도록 20%의 오버헤드 요소를 적용합니다.

폴더당 항목 수

서버 I/O를 줄일 수 있는 한 가지 방법은 캐시된 Exchange 모드로 Outlook을 사용하는 것입니다. 초기 사서함 동기화에는 디스크 사용량이 많지만 시간이 지나면서 사서함 크기가 커지면 디스크 하위 시스템의 작업이 Exchange 서버에서 Outlook 클라이언트로 이동하게 됩니다. 캐시된 Exchange 모드를 사용하면 사용자의 받은 편지함에 항목 수가 많거나 사용자가 사서함을 검색하고 있어도 서버의 성능에는 거의 영향이 없습니다. 또한 이 접근 방식에서는 적절한 성능에 대한 개별 사용자의 임계값에 따라, 캐시된 Exchange 모드를 사용하며 대규모 사서함을 보유한 사용자의 경우 사서함 크기가 작은 사용자에 비해 속도가 빠른 컴퓨터가 필요할 수 있습니다.

Outlook 2007을 실행하는 클라이언트 컴퓨터를 캐시된 Exchange 모드에서 배포할 때는 사서함/.ost 크기와 관련하여 다음 지침을 고려하십시오.

  • 최대 5GB   대부분의 하드웨어에서 사용자 환경에 이 크기를 지정하는 것이 좋습니다.

  • 5GB와 10GB 사이   이 크기는 일반적으로 하드웨어에 따라 다릅니다. 따라서 하드 디스크 속도가 빠르고 RAM이 많은 경우에는 환경 성능이 훨씬 좋아집니다. 그러나 대부분의 랩톱 드라이브 또는 이전 세대의 SSD(반도체 드라이브) 등과 같은 속도가 느린 하드 드라이브의 경우에는 드라이브 응답 시 일부 응용 프로그램이 일시 중지됩니다.

  • 10GB 이상   대부분의 하드웨어에서 응용 프로그램이 잠깐 동안 일시 중지됩니다.

  • 매우 큰 크기(25GB 이상)   짧은 시간 동안 발생하는 일시 중지 빈도가 늘어납니다. 특히 새 전자 메일 메시지를 다운로드할 때 자주 일시 중지됩니다. 보내기/받기 그룹을 사용하여 메일을 수동으로 동기화할 수도 있습니다.

이 지침은 Outlook 2007 서비스 팩 1 이상용 누적 업데이트 설치를 기준으로 합니다. 이 누적 업데이트에 대한 설명은 Microsoft 기술 자료 문서 961752, Outlook 2007 핫픽스 패키지(Outlook.msp)에 대한 설명: 2009년 2월 24일에 나와 있습니다.

캐시된 Exchange 모드 배포에서 Outlook 2007에 성능 관련 문제가 발생하는 경우에는 기술 자료 문서 940226, Outlook 2007에서 성능 문제를 해결하는 방법을 참조하십시오. 제공되고 있는 향상된 기능에 대한 자세한 내용은 기술 자료 문서 968009, 2009년 2월 누적 업데이트의 Outlook 2007 향상된 기능(영문)를 참조하십시오.

문제가 될 수 있는 시나리오는 사용자가 Exchange에서 저장할 수 있는 인덱스 수를 초과하여 저장한 경우입니다. Exchange 2010에서 이 인덱스 수는 11개입니다. 이 경우 사용자가 새로운 방식으로 보기를 정렬하도록 선택하여 12번째 인덱스를 만들면 디스크 I/O 작업이 추가로 생성됩니다. 해당 인덱스는 저장되지 않으므로 이 정렬을 수행할 때마다 추가 디스크 작업 비용이 발생합니다. 이 시나리오에서는 많은 I/O 작업이 생성될 수 있기 때문에 받은 편지함 및 보낸 편지함 폴더 등의 주요 폴더에 100,000개가 넘는 항목을 저장하거나 일정 및 연락처 폴더에 10,000개가 넘는 항목을 저장하지 않는 것이 좋습니다. 상위 수준 이상의 폴더를 만들거나 받은 편지함 및 보낸 편지함 폴더 아래에 하위 폴더를 만들면 이러한 인덱스 작성 작업과 관련된 비용이 크게 줄어듭니다. 그렇지만 이 경우 한 폴더에 포함된 항목 수가 100,000개를 넘지 않아야 합니다.

맨 위로 이동

콘텐츠 인덱스 I/O

Exchange 2010에서는 메시지를 받으면 인덱싱되므로 데이터베이스 디스크 I/O 오버헤드를 거의 발생시키지 않습니다. 인덱싱을 위해 검색 시 메시지가 계속 데이터베이스 캐시에 있기 때문입니다. 그러나 쓰기 I/O는 검색 카탈로그 저장소 업데이트와 연결되어 있습니다. Exchange 2010의 전체 데이터베이스 I/O 감소로 인해 검색 카탈로그 I/O의 비율이 이제 프로필에 따라 데이터베이스 파일 I/O의 10~15%입니다. 클라이언트가 검색 쿼리를 실행하면 검색 카탈로그 읽기 I/O가 발생하며, 이는 드물게 발생하므로 Exchange 2010 저장소 설계와 관련이 없습니다.

맨 위로 이동

비트랜잭션 I/O

트랜잭션 I/O는 직접적인 사용자 작업에 대한 응답으로 발생하며 보통 우선 순위가 가장 높으므로 저장소 설계를 중심으로 합니다. 비트랜잭션 I/O는 백그라운드에서 발생하고 성능에 거의 영향을 미치지 않도록 조정되거나, 정의된 유지 관리 기간 동안 발생합니다.

다음 섹션에서는 백그라운드에서 발생하는 일부 비트랜잭션 I/O에 대해 설명합니다. 비트랜잭션 I/O는 저장소 설계의 핵심은 아니지만 저장소 설계에 영향을 줄 수 있습니다. 자세한 내용은 새 Exchange 핵심 저장소 기능을 참조하십시오.

백그라운드 데이터베이스 유지 관리(체크섬)

백그라운드 데이터베이스 유지 관리 I/O는 활성 및 수동 데이터베이스 복사본 모두의 체크섬과 관련된 순차적 데이터베이스 파일 I/O입니다. 백그라운드 데이터베이스 유지 관리의 특징은 다음과 같습니다.

  • 활성 데이터베이스에서는 24 × 7 또는 온라인 유지 관리 기간 동안 실행되도록 구성할 수 있습니다. 백그라운드 데이터베이스 유지 관리(체크섬)는 수동 데이터베이스 복사본에 대해 24 × 7 동안 실행됩니다. 자세한 내용은 새 Exchange 핵심 저장소 기능 항목의 "온라인 데이터베이스 검색"을 참조하십시오.

  • 각 검색 데이터베이스에 대해 초당 약 5MB를 읽습니다(활성 및 수동 복사본 모두). I/O는 100% 순차적이므로 저장소 하위 시스템이 I/O를 효율적으로 처리할 수 있습니다.

  • 체크섬 통과가 24시간 이내에 완료되면 데이터베이스 검색이 중지됩니다.

  • 검색이 3일 내에 완료되지 않는 경우 경고 이벤트가 발생합니다(구성할 수 없음).

메시징 레코드 관리

MRM(메시징 레코드 관리)은 조직들이 전자 메일과 관련된 법적 위험을 줄일 수 있는 Exchange 2010의 레코드 관리 기술입니다. MRM을 사용하면 회사 정책, 정부 규정 또는 법률적 요구 사항을 준수하고 법적 또는 비즈니스적 가치가 없는 콘텐츠를 제거하는 데 필요한 메시지를 손쉽게 보유할 수 있습니다.

이러한 작업은 보존 정책 또는 관리되는 폴더를 사용하여 수행됩니다. 관리되는 폴더 도우미는 보존 정책 또는 관리되는 폴더 사서함 정책에 구성된 메시지 보존 설정을 적용하는 Microsoft Exchange 사서함 도우미입니다. 도우미에 필요한 디스크 I/O는 처리되는 사서함 항목 수에 따라 달라집니다. 도우미는 백업 또는 온라인 유지 관리와 동시에 실행하지 않는 것이 좋습니다. 자세한 내용은 관리되는 폴더 도우미 예약을 참조하십시오.

온라인 유지 관리

Exchange 관리 도구를 사용하여 데이터베이스에 대한 유지 관리 일정을 설정하거나 24 × 7 데이터베이스 유지 관리를 허용합니다. 온라인 조각 모음은 이전 버전의 Exchange에서 작동했지만 Exchange 2010에서는 더 이상 작동하지 않습니다. 온라인 조각 모음은 데이터베이스를 읽고 쓰는 동안 계속 수행됩니다. 자세한 내용은 새 Exchange 핵심 저장소 기능의 "온라인 데이터베이스 검색"을 참조하십시오.

맨 위로 이동

 © 2010 Microsoft Corporation. 모든 권리 보유.