SSD의 시스템 드라이브; 자체 드라이브에 페이지 파일?


10

RAM이 16GB 인 Windows Server 2008 R2 서버의 시스템 드라이브에 Intel X25-E SSD를 사용하고 있습니다. 페이지 파일을 자체 드라이브로 옮기는 것이 좋습니까? 그렇다면 페이지 파일 드라이브의 경우 SSD 또는 일반 하드 드라이브를 선호합니까?

스토리지 구성에는 두 개의 데이터 볼륨이 포함되며 각 볼륨은 PERC 5 / i 통합 RAID 컨트롤러에 연결된 4 디스크 RAID 10 어레이에 구현됩니다. 서버는 Dell PowerEdge 2900입니다. 백플레인에는 슬롯 10 개, SSD 용 1 개, RAID 10 어레 이용 8 개, 페이지 파일 드라이브 용 빈 슬롯 1 개가 있습니다.

감사.

답변:


11

일반적인 대답은 페이지 파일을 시스템 드라이브에서 분리하는 것이지만 X-25E의 성능은 일반적으로 특히 서버에서 불필요하게 만들어야합니다. 불필요한 페이징을 피하기 위해 시스템에 충분한 RAM을 넣을 수 없거나 Exchange 2007과 같이 페이징을 많이 사용할 수있는 응용 프로그램이있는 경우 페이지 파일을 전용 디스크 나 디스크에 배치 활용률이 일반적으로 낮은 곳은 좋은 생각입니다.

그러나 시스템 드라이브에 단일 X-25E를 사용하는 것은 조금 이상합니다. 시스템 드라이브에 SSD를 사용하는 것이 좋은지 아닌지는 전적으로 서버를 사용하는 대상에 달려 있지만 대부분의 경우 제대로 구성된 서버의 시스템 드라이브는 가장 중요한 IO 병목 현상이되지 않습니다. 제어.

내가 확실히 말할 수있는 것은 시스템이나 일반 데이터 볼륨에 하나의 드라이브 만 사용하면 안된다는 것입니다. RAID 1에서 비교적 작지만 상당히 빠른 두 개의 드라이브 (2x10K SAS)를 사용하는 표준 방법은 대부분의 서버에 대해 (대부분 정적) 시스템 드라이브 파일을로드하기에 충분한 성능을 제공하지만 어느 정도의 장애 복구 능력을 보장합니다. SSD는 기계적인 것은 아니지만 여전히 실패 할 수 있습니다.

SSD를 사용하여 IOPS가 제한된 것을 제거하는 것이 이상적입니다. RAID 10 어레이는 대부분의 조건에서 X-25E의 전송 속도와 일치 할만큼 충분히 가까울 수 있지만 IOPS에 가깝지는 않습니다 (수백에서 X-25E의 경우 최고 대 수천). 그러나 단일 드라이브이므로 완전히 잃어 버릴 수없는 것을 넣는 것을 꺼려해야합니다. 내 경우 임시 파일 공간 (예 : 인쇄 스풀링, 스크래치 DB 영역)에 사용합니다 보고 등).


2
+1이 특정 구성의 이점에 의문을 제기합니다. 서버의 시스템 디스크는 일반적으로 많은 활동을 보지 못합니다.
Oskar Duveborn

이것은 터미널 서버 a / k / a 원격 데스크톱 세션 호스트입니다.
세종

Windows 설치 중에 Users 폴더가 RAID 10 볼륨 중 하나로 리디렉션됩니다. 1 디스크 시스템 볼륨에 대한 필자의 생각은 필요할 경우 베어 메탈 백업에서 복원 할 수 있다는 것입니다.
세종

이제 계획이 훨씬 더 합리적입니다. 터미널 서비스 서버의 시스템 드라이브를 훨씬 더 많이 사용하고 일반적인 서버보다 더 많은 페이징을 얻을 수 있습니다. 매우 빠른 베어 메탈 프로비저닝 시스템이 있더라도 여전히 두 개의 시스템 디스크를 권장합니다. 이 설명을 감안할 때 가장 좋은 해결책은 다른 X-25E를 가져 와서 첫 번째 RAID 1로 설정 한 다음 해당 팩을 시스템 및 페이징에 사용하는 것입니다.
Helvick

하드웨어 RAID는 TRIM을 지원하지 않으므로 현재 SSD와 결합 된 RAID는 좋지 않습니다. 소프트웨어에서 RAID 1 미러링의 성능 영향은 그다지 크지 않으므로 사용할 수 있습니다.
JamesRyan

5

체크 아웃 http://blogs.msdn.com/e7/archive/2009/05/05/support-and-qa-for-solid-state-drives-and.aspx

그러나 아래는 서버 사용량보다 소비자 사용량에 더 많이 적용될 수 있으므로 소금 한 덩어리로 섭취하십시오.


페이지 파일을 SSD에 배치해야합니까?

예. 대부분의 페이지 파일 작업은 작은 임의 읽기 또는 큰 순차적 쓰기이며, 둘 다 SSD가 잘 처리하는 작업 유형입니다.

수천 개의 트레이스에서 원격 측정 데이터를보고 페이지 파일 읽기 및 쓰기에 중점을두면

Pagefile.sys가 pagefile.sys의 수를 약 40 대 1로 읽습니다.

Pagefile.sys 읽기 크기는 일반적으로 매우 작으며 67 %는 4KB 이하이고 88 %는 16KB 이하입니다.

Pagefile.sys 쓰기는 비교적 크며, 이는 128 % 이상이고 62 %가 정확히 1MB입니다.

실제로, 전형적인 페이지 파일 참조 패턴과 SSD가 이러한 패턴에서 갖는 유리한 성능 특성을 고려할 때 SSD에 배치 할 페이지 파일보다 더 나은 파일은 거의 없습니다.


Windows Engineering Team 블로그 링크에 감사드립니다.
세종

-1

나는 여기에서 인기있는 의견에 반대한다는 것을 알고 있지만 몇 년 동안 아무런 영향을 미치지 않고 페이지 파일이없는 여러 시스템에서 WinXP를 실행했습니다. 방금 X-25를 직접 구매하고 페이지 파일없이 XP를 설치했습니다. 나는 SSD의 낡은 Window의 오래된 페이지 파일의 요점을 보지 못했습니다.

XP가 1GB의 RAM과 1.5GB의 최대 페이지 파일로 제대로 실행되면 2.5GB의 RAM으로 페이지 파일이 제대로 실행되지 않는 이유를 알 수 없습니다. 매우 드문 조건에서 (수 많은 열린 창과 많은 Firefox 창 및 다른 메모리 호그가 실행되는 Photoshop 실행) 메모리 부족 경고가 표시됩니다 . 내 페이지 파일이 최대 한도 인 경우 어쨌든, 내가하는 일은 내 작업을 저장하고 메모리 호깅 응용 프로그램 중 일부를 종료하는 것입니다.

// Rant on // 마지막으로, 만약 우리가 "pagefiles를 가지고 있다면", 나는 2009 년에 pagefile을위한 friggin RAM 디스크를 만들 수 없다고 믿을 수 없다! 진심으로, 1986 년 Amiga 에서 재부팅 후에도 고정 크기의 RAM 드라이브 만들 수 있습니다 (VD0 : ASDG 복구 가능한 RAM 디스크)! 어떻게 그것이 세기의 후반이 될 수 있고 우리는 여전히 Amiga에 당연한 기능을 가지고 있지 않습니까? // 랜트 오프 //


1
나는 수년 동안 페이지 파일이없는 창을 실행했는데 최근에 나쁘게 물었습니다. 8GB comp의 Photoshop에서 큰 그림을 편집하고 있었고 편집하는 동안 메모리가 부족했습니다. 글쎄, 나는 모든 것을 닫고 그림을 저장하려고했습니다. 문제는 포토샵이 그림을 저장하기 위해 더 많은 메모리가 필요하다는 것입니다. 페이지 파일없이 더 많은 것을 얻을 수있는 방법이 없었기 때문에 결국에는 매우 큰 그림에서 편집 내용을 잃었습니다. 시스템이 더 이상 메모리를 제공 할 수 없습니다.
Sam

정말 고통 스럽습니다. 그러나 문제는 메모리가 부족하다는 것입니다. 더 많은 파일을 사용하여 동일한 조건을 만들고 페이지 파일로도 충돌을 일으킬 수 있다고 확신합니다. 그리고 더 많은 RAM이 있다면 페이지 파일이 없으면 충돌하지 않았을 것입니다. Photoshop에는 자체 temp / scratch 디렉토리도 있습니다. 비활성화하지 않는 것이 좋습니다 ... 시스템에서 활성화 되었습니까?
프레드 해밀턴

램 디스크의 페이지 파일? 왜 여분의 레이어를 제거하고 더 많은 무료 램을 가지지 않겠습니까?
surfasb

나는 원칙적으로 완전히 동의합니다 .A) 32 비트 WinXP가 액세스 할 수있는 것보다 많은 RAM이 있고 램 디스크는 여분의 RAM에 들어가므로 여유 메모리와 같고 B) 어떤 사람들은 페이징 파일이 없으면 Windows (또는 일부 Windows 프로그램)가 만족스럽지 않다고 생각합니다 (어느 방법으로도 입증되지 않았다고 생각합니다). RAM 디스크가 빠르며 OS에서 사용 가능한 RAM에 영향을 미치지 않으며 페이징 파일이 있기 때문에 OS가 행복합니다.
Fred Hamilton
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.