나는 이 질문을 읽었 으며 많은 정보가 있습니다.
그러나 충분한 RAM이 있다고 가정하면 SSD에서 페이지 파일을 비활성화하여 수명을 연장해야한다고 생각합니다. 충돌시 코어 덤프를 잃을 것이라는 것을 알고 있지만 많은 사람들이 그 정보를 필요로하지 않습니다.
RAM의 한계에 도달하면 페이지 파일없이 디스크에서 스 래싱을 유발할 수 있습니다. 그러나 SSD의 경우 스 래싱 개념이 없으며 읽기 속도가 빠릅니다.
너희들은 어떻게 생각하니?
답변
그러나 충분한 RAM이 있다고 가정하면 SSD에서 페이지 파일을 비활성화하여 수명을 연장해야한다고 생각합니다. 충돌시 코어 덤프를 잃을 것임을 알고 있지만 많은 사람들이 그 정보를 필요로하지는 않습니다.
이것은 조기 최적화와 비슷합니다. 어떤 SSD를 사용하려고했는지에 대해 이야기하지 않았으며 실제로 서버 워크로드와 계획된 SSD 데이터 시트를 보지 않으면 페이지 파일이 SSD의 수명에 어떤 영향을 미치는지 알 수 없습니다.
또한 수명이 오래 걸리는 SSD에 대한 더 큰 인터넷과 서버 결함 모두에 대해 많은 양의 잘못된 정보가 있습니다. 초기 모델 SSD에는 문제가 있었지만 USB 플래시 드라이브는 확실히 성능이 저하되기 시작했지만 엔터프라이즈 급 SSD는 훨씬 더 우수한웨어 레벨링 알고리즘을 갖추고 있으며 일부는 예비 플래시를 사용하여 성능과 마모를 개선합니다.
예를 들어, Intel X25-E 드라이브 는 32GB 드라이브에 대해 1 페타 바이트의 랜덤 쓰기 쓰기 지속 시간을 요구합니다. 덮어 쓰기를 사용하여 쓰기 인터페이스 (200MB / 초)를 중단없이 채울 경우 약 58 일 동안 지속될 것으로 예상됩니다. 그러나 그것은 그 드라이브에 하루 17TB의 데이터를 쓰고 있습니다.
페이지 파일이 있더라도 OS 드라이브의 일반적인 서버 워크로드는 훨씬 줄어 듭니다. 하루에 50GB라고합니다. 1 PB 수치가 정확하고 (나중에 평균 수치로 간주 될 수 있음을 알고 나중에 더 논의 할 수 있음), 이는 여전히 50 년 북쪽에 있습니다.
물론이 수치는 엄청나게 높아 보인다 . 예상되는 드라이브 수명에 대해 인텔이 인용 한 실제 수치를 살펴 보자 . 인텔은 5 년 동안 매일 100GB의 데이터를 쓸 수있는 MLC (비 엔터프라이즈) 드라이브 자격을 갖추게되어 기뻤습니다. SLC와 MLC 플래시의 표준 이해에 따르면 SLC 플래시는 MLC보다 약 10 배 더 오래 지속됩니다 (위의 링크는 그래프에도 표시됨).
물론 진실은 시간이 지남에 따라 드러날 것입니다. 드라이브가 일찍 실패하거나 시작하지 않는 것을 보게 될 것입니다. 그러나 드라이브 뒤의 숫자는 양질의 SSD 에 전혀 문제가되지 않고 수명을 연장 시킵니다 .
MLC SSD를 사용하고 있다면 걱정할 것입니다. 그러나 인텔이 5 년 동안 100GB / 일 속도로 드라이브를 평가하면 10 년 동안 여전히 50GB / 일과 동일하다는 점을 명심하십시오. 그리고 원래 요점으로 돌아가서 드라이브에서 어떤 종류의 실제 워크로드를 수행해야하는지 알아야합니다.
개인적으로 프로덕션 서버 환경에서 MLC SSD를 사용하지 말 것을 강력히 권합니다. 괜찮은 SLC SSD가 너무 비싸다면 지금은 회전하는 디스크를 고수하십시오.
(SLC가 MLC보다 10 배 더 오래 지속됨) 등급 인 50 년 동안 하루에 100GB로 말하면, 인텔은 32GB 드라이브가 실제로 총 쓰기 수명을 갖는 것으로 보입니다. 제품 사양에 인용 된 1 PB가 아니라 2 PB의 데이터에 더 가깝습니다.이 두 값 중 작은 값만 신뢰하더라도 X25-E 드라이브는 10 년이 지난 후에도 계속 지속될 수 있습니다.)
답변
Daniel Lawson이 언급했듯이 MS 팀 자체의 피드백 (아래)과 같이 수명은 문제가되지 않을 것입니다.
- 페이지 파일은 어쨌든 필요할 때만 사용됩니다
- 페이지 파일이있는 경우 되어 사용되는, 회전하는 하드 드라이브 대 SSD에있는 것은 엄청난 차이를 만들 것
페이지 파일을 SSD에 배치해야합니까?
예. 대부분의 페이지 파일 작업은 작은 임의 읽기 또는 더 큰 순차적 쓰기이며, 둘 다 SSD가 잘 처리하는 작업 유형입니다.
수천 개의 트레이스에서 원격 측정 데이터를보고 페이지 파일 읽기 및 쓰기에 중점을두면
- Pagefile.sys가 페이지 수보다 많은 수를 읽습니다.
- Pagefile.sys 읽기 크기는 일반적으로 매우 작으며 67 %는 4KB 이하이고 88 %는 16KB 이하입니다.
- Pagefile.sys 쓰기는 상대적으로 커서 128 % 이상이고 62 %가 정확히 1MB입니다. 실제로, 전형적인 페이지 파일 참조 패턴과 SSD가 이러한 패턴에 대해 유리한 성능 특성을 고려할 때 SSD 에 배치 할 페이지 파일보다 더 나은 파일은 거의 없습니다.
답변
페이지 파일을 모두 비활성화하는 대신 OS에서이를 사용하지 않도록 지시하는 것이 좋습니다 (예 🙂 sysctl vm.swappiness=0
.
OS는 필요한 경우를 제외하고는 사용을 피하여 SSD 불필요한 쓰기를 저장합니다.
답변
페이지 파일을 항상 활성화 상태로 둡니다. 당신의 OS 나 앱의 특정 부분에 기록 될 수 있습니다 기대 하나가 될, 하나가없는 경우와 같은 무례한 행동을 할 수있다.
과거에는 페이지 파일없이 Windows (XP)를 실행했으며 내가 던진 모든 것에 완전히 만족했습니다. 마음에 들지 않는 무언가가 나올 것이지만 항상 의문의 여지가있었습니다.
옵션은 정말로 작게 설정하는 것입니다.
답변
이것은 OP에 직접 응답하지 않지만 Ronald와 Daniel의 위의 답변 / 의견에서 잘못된 인상을 수정하고 싶었습니다. (나는 새로운 사람이므로 의견을 말할 충분한 점이 없습니다.)
TRIM 은 실제로 SSD 수명을 연장하기 위해 할 수 있는 가장 큰 일입니다. 이유는 다음과 같습니다. SSD는 주기적으로 “가비지 수집”-부분적으로 비어있는 지우개 블록에서 (조각화 된) 데이터를 복사하여 새로 지운 블록에 연속적으로 씁니다.
호스트가이를 알 필요가 없도록 주소가 재 맵핑됩니다. 호스트 쓰기와 직접 연결되지 않은이 추가 쓰기 작업을 “쓰기 증폭”이라고합니다. 소량의 오버 프로비저닝 된 (숨겨진 스페어) 공간이있는 완전 완전 SSD의 최악의 경우 쓰기 증폭은 호스트 쓰기 속도의 500 %-700 % 범위에 있습니다.
가비지 콜렉션 중에 SSD는 무효화 (덮어 쓰기 또는 TRIMmed) 된 페이지를 복사하고 다시 쓰지 않아도되므로 잠재적으로 많은 작업과 쓰기 활동을 줄일 수 있습니다. 파일 시스템이 큰 파일을 지우지 만 TRIM을 통해 드라이브에 알리지 않으면 드라이브는 지워진 데이터를 계속 복사하여 쓰기를 낭비하거나 무기한으로 (또는 해당 블록 주소가 다른 파일에 할당 될 때까지) 오랜 시간이 걸릴 수 있습니다).
요약하면 TRIM은 수명과 성능 모두에 매우 중요합니다.
답변
나는 당신이 링크 한 다른 게시물에 이것을 언급했지만 우리는 페이지 파일없이 매우 메인 라인 서버를 운영하며 여기의 모든 것이 잘 보입니다. 실제로 그것은 그것없이 더 빠르다. 우리는 8GB의 RAM을 가지고 있으며 하드 드라이브가 SSD인지 아닌지 여부에 따라 많은 RAM이 있는지 여부에 따라 결정해야한다고 말하고 싶습니다. 불필요한 글을 쓰지 않으면 서 생명을 구하고 싶다는 것을 이해할 수 있습니다.
답변
가상 메모리 용으로 두 번째 하드 드라이브를 사용하십시오.