Exchange 2003 메일 저장소의 실제 디스크 큐가 높음

Exchange 2003 메일 저장소의 실제 디스크 큐가 높음

7200 SATA rpm 디스크 10개가 포함된 RAID 10 어레이가 있습니다. 업무 시간 동안 내 디스크 대기열 길이는 평균 약 100입니다. 설정은 다음과 같습니다.

  1. 어레이에는 95개의 활성 사서함이 있는 하나의 메일 저장소가 있습니다. (로그나 시스템 파일이 없는 유일한 것입니다.)
  2. 평균 사서함 크기 ~ 400MB
  3. 어레이는 RAID 스트라이프에 정렬된 하나의 대형 1.3TB 파티션입니다.
  4. 메일 저장소는 ~ 48GB입니다(etm 및 stm 파일 모두).
  5. 메일 저장소가 조각 모음되었습니다.
  6. 트랜잭션 로그가 평균 디스크 대기열이 1개 미만인 다른 어레이에 있습니다.

이게 높은 것 같나요? 그렇다면 이 설정에 문제가 있는 것 같나요? 다른 카운터도 살펴봐야 할까요?

댓글 후 업데이트:

  1. 어레이 자체는 괜찮은 것 같습니다. 지난 몇 주 동안 며칠 간의 jetstress 테스트에서 좋은 결과를 얻었습니다.
  2. 배열에 페이지 파일이 없습니다 :-)
  3. 시만텍 AV 소프트웨어가 있습니다. 작업 관리자를 살펴보면 IO 읽기 및 IO 쓰기 중 가장 높은 두 가지는 conduit.exe(symantec 안티 스팸/바이러스) 및 store.exe입니다. Conduit의 읽기 횟수는 1,800만 회, 쓰기 횟수는 2,500만 회, 저장소의 읽기 횟수는 1억 4,400만 회, 쓰기 횟수는 900만 회입니다. 현재는 게이트웨이 서버가 있어서 백엔드 서버에서 AV를 떼어내는 방안을 검토하고 있습니다.

답변1

그것은 "다소 높은" 수준을 넘어서는 수준입니다.엄청나게, 엄청나게높은. 디스크 대기열이 훨씬 적은 오래된 7,200RPM Ultra160 SCSI 드라이브의 RAID-5에서 실행되는 사서함 수가 두 배 이상인 상자가 있습니다.

Exchange 외에 다른 것이 디스크를 스래싱하고 있습니다. Perfmon을 열고 각 개별 프로세스에 대한 "프로세스" 개체의 "IO 데이터 작업/초"를 그래프로 표시하고 어떤 프로세스가 너무 많은 IO를 유발하는지 확인합니다.

편집하다:

Jim B에 대한 귀하의 의견에 링크된 기사에는 살펴볼 매우 좋은 성능 카운터가 있습니다. 또한 해당 디스크에 가상 메모리 페이지 파일을 넣었는데 과도한 페이징이 발생하는지 궁금합니다.

기사와 링크된 기사(Entourage)를 읽은 후 귀하가 해당 고객과 관련된 몇 가지 문제를 겪고 있을 수 있다는 의심이 들었습니다. Outlook Anywhere(HTTP를 통한 RPC라고도 함)는 Entourage와 동일한 문제를 일으키지 않습니다. 이는 완전히 다른 것입니다(HTTP를 통한 MAPI와 Entourage 클라이언트가 사용하는 WebDAV).

묻지 않고 진행되지만 이벤트 로그에 이상한 점이 있습니까?

업데이트 후 편집:

총 읽기/쓰기 횟수는 실제로 원하는 것이 아닙니다. 실제로 간격별로 읽기/쓰기의 델타를 찾고 있습니다. Perfmon을 열고 기본 카운터를 지우고 다음에 대한 카운터를 추가하십시오.

  • 물체:프로세스 -카운터:데이터 작업/초 -사례:도관.exe
  • 물체:프로세스 -카운터:데이터 작업/초 -사례:store.exe

다음을 살펴보실 수도 있습니다.Microsoft Exchange 사용자 모니터(사용법에 대한 좋은 기사는 다음에서 확인할 수 있습니다.http://www.msexchange.org/tutorials/Microsoft-Exchange-Server-User-Monitor.html). 여기에는 WebDAV 세션이 표시되지 않지만 기존 MAPI 기반 사용자가 수행하는 작업에 대한 통찰력을 제공할 수 있습니다.

답변2

와! 매우 높습니다. 평균 대기열 길이는 물리적 디스크 스핀들의 수와 같거나 작아야 하므로 컴퓨터는 원래 있어야 할 크기보다 훨씬 더 큰 속도로 작동합니다.이 링크디스크 I/O를 유발하는 모든 Exchange 작업 목록이 있으므로 Sam & Evan의 제안과 함께 메일 루프와 같은 활동이 비정상적으로 많이 발생하지 않는지 확인해야 합니다.

답변3

꽤 높은 편인데, AV 소프트웨어 같은 게 있나요? 또한 \process*\io 데이터 작업/초를 살펴보세요. IO를 일으키는 원인이 store.exe인지 아니면 다른 것인지 알려줄 것입니다. store.exe라면 사서함을 통해 무언가를 검색하고 있는 것 같습니다.

답변4

다음을 살펴보실 수도 있습니다.프로세스 모니터, 디스크에 대한 각 액세스를 개별적으로 기록합니다. Exchange가 아닌 다른 것이 디스크를 사용하고 있는 경우 ProcMon에서 디스크 액세스 목록이 매우 빠르게 채워지는 것을 볼 수 있습니다.

귀하가 언급한 사양을 보면 RAM 용량이 어느 정도인지는 언급하지 않았지만 RAM 용량은 언급하지 않았습니다. 2GB 미만을 실행하는 경우 페이지 파일을 실행하는 컴퓨터에서 이러한 종류의 동작을 볼 수 있습니다. 작업 관리자에서 사용되는 RAM의 양이 서버에 설치된 실제 메모리의 양보다 적은지 확인하십시오.

관련 정보