Windows 파일 서버 성능 튜닝

Question 1

디스크 하위 시스템: 다음은 Microsoft re: SQL Server 2008의 파티션 정렬에 관한 기사입니다.http://msdn.microsoft.com/en-us/library/dd758814.aspx

기사에 설명된 이론은 제가 링크를 제공하는 이유입니다. 귀하가 SQL Server를 실행할 것이라고 생각하기 때문이 아닙니다. 파일 서버의 워크로드는 SQL Server만큼 파티션 정렬에 까다롭지는 않지만 조금씩 도움이 됩니다.

NTFS:

다음을 사용하여 NTFS에서 마지막 액세스 타임스탬프를 비활성화할 수 있습니다.

fsutil behavior set disablelastaccess 1

다음을 사용하여 짧은 파일 이름 생성을 비활성화할 수 있습니다(필요한 앱이 없는 경우).

fsutil behavior set disable8dot3 1

상자에 넣을 파일 종류에 가장 적합한 NTFS 클러스터 크기를 생각해 보세요. 일반적으로 클러스터 크기를 최대한 크게 유지하여 하위 클러스터 크기 파일에 낭비되는 공간과의 균형을 유지하려고 합니다. 또한 클러스터 크기를 RAID 스트라이프 크기에 맞추고 싶습니다(그리고 위에서 설명한 대로 스트라이프를 클러스터에 맞춰 정렬).

대부분의 읽기는 순차적이라는 이론이 있으므로 스트라이프 크기(일반적으로 RAID 컨트롤러의 최소 읽기)는 클러스터 크기의 배수여야 합니다. 이는 서버의 특정 작업 부하에 따라 달라지며 확실히 알기 위해서는 이를 측정해야 합니다. 나는 그것들을 동일하게 유지하겠습니다.

많은 수의 작은 파일을 보유하려는 경우 향후 MFT 조각화를 방지하기 위해 NTFS MFT(마스터 파일 테이블)에 대한 더 큰 예약으로 시작하는 것이 좋습니다. 위의 fsutil 명령에 대해 설명하는 것 외에도 이 문서에서는 "MFT 영역" 설정에 대해 설명합니다.http://technet.microsoft.com/en-us/library/cc785435(WS.10).aspx 기본적으로 MFT 조각화를 방지하기 위해 볼륨에 있을 것으로 예상되는 파일 수를 기반으로 필요하다고 생각되는 만큼의 MFT용 디스크 공간을 예약하려고 합니다.

NTFS 성능 최적화에 대한 Microsoft의 일반 가이드는 다음에서 확인할 수 있습니다.http://technet.microsoft.com/en-us/library/cc767961.aspx 그것은오래된문서이지만 그럼에도 불구하고 괜찮은 배경을 제공합니다. 반드시 "기술적인 일"을 시도할 필요는 없지만, 그로부터 개념을 얻으십시오.

공들여 나열한 것:

OS와 데이터를 분리하는 것에 대해 사람들과 종교적인 논쟁을 벌이게 될 것입니다. 이 특정 애플리케이션의 경우 아마도 모든 것을 하나의 파티션에 쌓을 것입니다. 누군가 와서 내가 틀렸다고 말할 것입니다. 스스로 결정할 수 있습니다. OS 파티션이 가득 차면 나중에 "작업을 수행"할 논리적 이유가 없습니다. 별도의 RAID 볼륨이 아니기 때문에 OS와 데이터를 파티션으로 분리해도 성능 이점이 없습니다. (다른 스핀들이라면 이야기가 달라지겠지만...)

섀도우 복사본:

섀도 복사본 스냅샷은 동일한 볼륨이나 다른 볼륨에 저장할 수 있습니다. 나는 쉐도우 복사본과 관련된 성능 문제에 대한 배경 지식이 많지 않기 때문에 멍청한 말을 하기 전에 여기서 멈추겠습니다.

Answer

디스크 하위 시스템: 다음은 Microsoft re: SQL Server 2008의 파티션 정렬에 관한 기사입니다.http://msdn.microsoft.com/en-us/library/dd758814.aspx

기사에 설명된 이론은 제가 링크를 제공하는 이유입니다. 귀하가 SQL Server를 실행할 것이라고 생각하기 때문이 아닙니다. 파일 서버의 워크로드는 SQL Server만큼 파티션 정렬에 까다롭지는 않지만 조금씩 도움이 됩니다.

NTFS:

다음을 사용하여 NTFS에서 마지막 액세스 타임스탬프를 비활성화할 수 있습니다.

fsutil behavior set disablelastaccess 1

다음을 사용하여 짧은 파일 이름 생성을 비활성화할 수 있습니다(필요한 앱이 없는 경우).

fsutil behavior set disable8dot3 1

상자에 넣을 파일 종류에 가장 적합한 NTFS 클러스터 크기를 생각해 보세요. 일반적으로 클러스터 크기를 최대한 크게 유지하여 하위 클러스터 크기 파일에 낭비되는 공간과의 균형을 유지하려고 합니다. 또한 클러스터 크기를 RAID 스트라이프 크기에 맞추고 싶습니다(그리고 위에서 설명한 대로 스트라이프를 클러스터에 맞춰 정렬).

대부분의 읽기는 순차적이라는 이론이 있으므로 스트라이프 크기(일반적으로 RAID 컨트롤러의 최소 읽기)는 클러스터 크기의 배수여야 합니다. 이는 서버의 특정 작업 부하에 따라 달라지며 확실히 알기 위해서는 이를 측정해야 합니다. 나는 그것들을 동일하게 유지하겠습니다.

많은 수의 작은 파일을 보유하려는 경우 향후 MFT 조각화를 방지하기 위해 NTFS MFT(마스터 파일 테이블)에 대한 더 큰 예약으로 시작하는 것이 좋습니다. 위의 fsutil 명령에 대해 설명하는 것 외에도 이 문서에서는 "MFT 영역" 설정에 대해 설명합니다.http://technet.microsoft.com/en-us/library/cc785435(WS.10).aspx 기본적으로 MFT 조각화를 방지하기 위해 볼륨에 있을 것으로 예상되는 파일 수를 기반으로 필요하다고 생각되는 만큼의 MFT용 디스크 공간을 예약하려고 합니다.

NTFS 성능 최적화에 대한 Microsoft의 일반 가이드는 다음에서 확인할 수 있습니다.http://technet.microsoft.com/en-us/library/cc767961.aspx 그것은오래된문서이지만 그럼에도 불구하고 괜찮은 배경을 제공합니다. 반드시 "기술적인 일"을 시도할 필요는 없지만, 그로부터 개념을 얻으십시오.

공들여 나열한 것:

OS와 데이터를 분리하는 것에 대해 사람들과 종교적인 논쟁을 벌이게 될 것입니다. 이 특정 애플리케이션의 경우 아마도 모든 것을 하나의 파티션에 쌓을 것입니다. 누군가 와서 내가 틀렸다고 말할 것입니다. 스스로 결정할 수 있습니다. OS 파티션이 가득 차면 나중에 "작업을 수행"할 논리적 이유가 없습니다. 별도의 RAID 볼륨이 아니기 때문에 OS와 데이터를 파티션으로 분리해도 성능 이점이 없습니다. (다른 스핀들이라면 이야기가 달라지겠지만...)

섀도우 복사본:

섀도 복사본 스냅샷은 동일한 볼륨이나 다른 볼륨에 저장할 수 있습니다. 나는 쉐도우 복사본과 관련된 성능 문제에 대한 배경 지식이 많지 않기 때문에 멍청한 말을 하기 전에 여기서 멈추겠습니다.

Question 2

WSS는 이미 기본적으로 제안된 여러 가지 작업을 수행합니다.Windows 스토리지 서버 블로그

"파일 서버 성능 최적화 Windows Server 2003에는 파일 시스템 별칭 제거, 8.3 이름 생성 끄기, 네트워크 프레임 크기 및 자세한 내용은 성능 조정 백서를 참조하세요. OEM은 NIC 카드의 인터럽트 선호도를 설정하고 RAID 어레이를 설정할 때 적절한 디스크 정렬을 고려하여 성능을 향상시킬 수도 있습니다. 이 주제들 중 "

디스크 정렬은 공장에서 수행되어야 합니다.

Answer

WSS는 이미 기본적으로 제안된 여러 가지 작업을 수행합니다.Windows 스토리지 서버 블로그

"파일 서버 성능 최적화 Windows Server 2003에는 파일 시스템 별칭 제거, 8.3 이름 생성 끄기, 네트워크 프레임 크기 및 자세한 내용은 성능 조정 백서를 참조하세요. OEM은 NIC 카드의 인터럽트 선호도를 설정하고 RAID 어레이를 설정할 때 적절한 디스크 정렬을 고려하여 성능을 향상시킬 수도 있습니다. 이 주제들 중 "

디스크 정렬은 공장에서 수행되어야 합니다.

Question 3

RAID 6은 이 설정의 다른 RAID 옵션에 비해 읽기 IO를 상당히 저하시키며 쓰기 IO 측면에서 매우 가혹합니다. 모든 공간을 확보해야 하는 경우가 아니라면 RAID 10을 고려하는 것이 좋습니다. 시스템의 RAID 6에 비해 750GB가 손실되지만 성능 차이로 인해 시도하는 다른 모든 성능 조정은 무의미해질 것입니다. 파티션 정렬, 파일 시스템 블록 크기에 스트라이프 크기 일치, Evan이 제안한 마지막 액세스 시간 등 변경 등은 처리량을 총 30% 이상 향상시킬 수 있는 훌륭한 제안입니다. RAID 10은 읽기 및 쓰기에 대해 전반적으로 최소 100% 더 빠르며 재구축 시간은 RAID 5 또는 6의 일부에 불과합니다.

RAID 10 - 핫 스페어 2개가 포함된 드라이브 4개. 유효 용량 1500GB. 이에 대한 지속적인 무작위 읽기는 기본 드라이브 IOPS의 약 4배입니다. 지속 무작위 쓰기는 기본 드라이브 장치 쓰기 IOPS의 최대 2배입니다. 재구축 시간 - 귀하와 같은 시스템에서 유휴 상태일 때 4~6시간이 소요되며, 평균 부하가 있는 경우에는 그 두 배가 될 수 있습니다.

RAID 5 - 핫 스페어 1개가 포함된 드라이브 5개. 유효 용량 3000GB. 지속적인 무작위 읽기는 기본 드라이브 IOPS의 약 4배입니다. 지속 무작위 쓰기는 단일 기본 드라이브의 쓰기 IOPS의 약 1배입니다(각 쓰기 IO에 2개의 읽기와 2개의 쓰기가 필요하다고 가정). 재구축 시간 - 유휴 상태에서는 하루 이상, 일반적인 로드 상태에서는 며칠입니다.

RAID 6 - 핫 스페어 1개가 포함된 드라이브 5개. 유효 용량 2250GB. 지속적인 무작위 읽기는 기본 드라이브의 약 3배입니다. 지속 무작위 쓰기는 단일 기본 드라이브 쓰기 IOPS의 약 66%입니다(각 쓰기 IO에 읽기 3회와 쓰기 3회 필요). 재구축 시간 - 시스템이 상대적으로 유휴 상태인 날, 일반적인 부하가 있는 경우 일주일이 소요됩니다.

물론 마일리지는 다를 수 있습니다. 지속적인 임의 IO가 많지 않으면 대부분이 캐시에 의해 숨겨지지만 RAID 6의 지속적인 성능 적중은 특히 어레이에서 상대적으로 적은 수의 드라이브로 구현될 때 매우 가혹합니다.

Answer