SSD로 페이지 파일을 비활성화해야합니까?


26

나는 이 질문을 읽었 으며 많은 정보가 있습니다.

그러나 충분한 RAM이 있다고 가정하면 SSD에서 페이지 파일을 비활성화하여 수명을 연장해야한다고 생각합니다. 충돌시 코어 덤프를 잃을 것이라는 것을 알고 있지만 많은 사람들이 그 정보를 필요로하지 않습니다.

RAM의 한계에 도달하면 페이지 파일없이 디스크에서 스 래싱을 유발할 수 있습니다. 그러나 SSD의 경우 스 래싱 개념이 없으며 읽기 속도가 빠릅니다.

너희들은 어떻게 생각하니?


그대로 두겠습니다. 현대 SSD는 거리를 유지해야합니다. storagesearch.com/ssdmyths-endurance.html을 참조하십시오 .
Matt

1
또한 워크로드를 서버에 제공하는 것은 어쨌든 디스크로 페이징하는 것이 좋습니다 (잘 알려진 경우에만 페이징). 지난 달에만 평균적으로 내 서버는 한 달 동안 약 100 페이지의 인 / 아웃을했습니다.
Matthew Ife

답변:


22

그러나 충분한 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 년이 지난 후에도 계속 지속될 수 있습니다.)


MLC SSD 사용에 대한 진술을 수정하겠다고 생각합니다. 기업용으로는 충분할 것 같습니다. SLC SSD를 사용하는 주요 공급 업체 중 하나가 SLC 범위를 MLC 플래시 및 스마트 컨트롤러로 대체하고 있다고 들었습니다.
Daniel Lawson

15

Daniel Lawson이 언급했듯이 MS 팀 자체의 피드백 (아래)과 같이 수명은 문제가되지 않을 것입니다.

  1. 페이지 파일은 어쨌든 필요할 때만 사용됩니다
  2. 페이지 파일이있는 경우 되어 사용되는, 회전하는 하드 드라이브 대 SSD에있는 것은 엄청난 차이를 만들 것

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

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

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

  • Pagefile.sys가 페이지 수보다 많은 수를 읽습니다.
  • Pagefile.sys 읽기 크기는 일반적으로 매우 작으며 67 %는 4KB 이하이고 88 %는 16KB 이하입니다.
  • Pagefile.sys 쓰기는 상대적으로 커서 128 % 이상이고 62 %가 정확히 1MB입니다. 실제로, 전형적인 페이지 파일 참조 패턴과 SSD가 이러한 패턴에 대해 유리한 성능 특성을 고려할 때 SSD 에 배치 할 페이지 파일보다 더 나은 파일은 거의 없습니다.

솔리드 스테이트 드라이브 (MSDN)에 대한 지원 및 Q & A


9

페이지 파일을 모두 비활성화하는 대신 OS에서이를 사용하지 않도록 지시하는 것이 좋습니다 (예 :) sysctl vm.swappiness=0.

OS는 필요한 경우를 제외하고는 사용을 피하여 SSD 불필요한 쓰기를 저장합니다.


4
훌륭합니다. 창문에 대한 조정이 있습니까?
Pyrolistical 2016 년

확실하지 않지만 페이지 파일 크기를 최소 (2MB)로 설정하고 크기를 늘려서이를 모방 할 수 있습니다.
MikeyB 2016 년

5

페이지 파일을 항상 활성화 상태로 둡니다. 당신의 OS 나 앱의 특정 부분에 기록 될 수 있습니다 기대 하나가 될, 하나가없는 경우와 같은 무례한 행동을 할 수있다.

과거에는 페이지 파일없이 Windows (XP)를 실행했으며 내가 던진 모든 것에 완전히 만족했습니다. 마음에 들지 않는 무언가가 나올 것이지만 항상 의문의 여지가있었습니다.

옵션은 정말로 작게 설정하는 것입니다.


앱이 램 또는 스왑을 사용하고 있는지 감지 할 수 없다고 생각합니다. 어떻게 그 문제가 될 수 있습니까?
Pyrolistical 2016 년

OS는 실제로 가상 메모리를 활성화하도록 조정되었습니다. SSD에 대한 요점이 있거나 당신이 옳다고 생각합니다. 반복적 인 쓰기 문제가 있음을 많이 읽었으며 가상 메모리는 확실히 그렇게합니다. 적절한 디스크에 페이지 파일 / 스왑을 배치 할 수 없습니까? (물론 반 직관적으로 보입니다 ...)
Kyle Hodgson

왜 OS가 페이지 파일이 있다고 가정합니까? 리눅스는 확실히 그렇지 않다. 그리고 나는 Windows도 그렇게 믿을만한 어떤 이유도 본 적이 없다.
Mikeage

2
Windows가 믿어야 할 이유는 다음과 같습니다. blogs.msdn.com/ericlippert/archive/2009/06/08/…
dmo

3

이것은 OP에 직접 응답하지 않지만 Ronald와 Daniel의 위의 답변 / 의견에서 잘못된 인상을 수정하고 싶었습니다. (나는 새로운 사람이므로 의견을 말할 충분한 점이 없습니다.)

TRIM 은 실제로 SSD 수명을 연장하기 위해 할 수 있는 가장 큰 일입니다. 이유는 다음과 같습니다. SSD는 주기적으로 "가비지 수집"-부분적으로 비어있는 지우개 블록에서 (조각화 된) 데이터를 복사하여 새로 지운 블록에 연속적으로 씁니다.

호스트가이를 알 필요가 없도록 주소가 재 맵핑됩니다. 호스트 쓰기와 직접 연결되지 않은이 추가 쓰기 작업을 "쓰기 증폭"이라고합니다. 소량의 오버 프로비저닝 된 (숨겨진 스페어) 공간이있는 완전 완전 SSD의 최악의 경우 쓰기 증폭은 호스트 쓰기 속도의 500 %-700 % 범위에 있습니다.

가비지 콜렉션 중에 SSD는 무효화 (덮어 쓰기 또는 TRIMmed) 된 페이지를 복사하고 다시 쓰지 않아도되므로 잠재적으로 많은 작업과 쓰기 활동을 줄일 수 있습니다. 파일 시스템이 큰 파일을 지우지 만 TRIM을 통해 드라이브에 알리지 않으면 드라이브는 지워진 데이터를 계속 복사하여 쓰기를 낭비하거나 무기한으로 (또는 해당 블록 주소가 다른 파일에 할당 될 때까지) 오랜 시간이 걸릴 수 있습니다).

요약하면 TRIM은 수명과 성능 모두에 매우 중요합니다.


2

나는 당신이 링크 한 다른 게시물에 이것을 언급했지만 우리는 페이지 파일없이 매우 메인 라인 서버를 운영하며 여기의 모든 것이 잘 보입니다. 실제로 그것은 그것없이 더 빠르다. 우리는 8GB의 RAM을 가지고 있으며 하드 드라이브가 SSD인지 아닌지 여부에 따라 많은 RAM이 있는지 여부에 따라 결정해야한다고 말하고 싶습니다. 불필요한 글을 쓰지 않으면 서 생명을 구하고 싶다는 것을 이해할 수 있습니다.


2

가상 메모리 용으로 두 번째 하드 드라이브를 사용하십시오.


1
요점은 페이지 파일을 SSD에 쓰는 것이 드라이브 사용 가능한 쓰기를 통해 구울 수 없다면 SSD를 사용하여 스왑 성능을 향상시키는 것이라고 생각합니다. 일반 하드 드라이브를 사용한다고해서 SSD의 성능 이점은 제공되지 않습니다.
jrista

대부분의 랩톱에서는 불가능합니다.
Brian Knoblauch

0

나는 1 년 이상 8 GB RAM, SSD 단일 드라이브 및 페이지 파일이없는 랩톱을 현재 1 년 이상 운영하고 있습니다. 페이지 파일이 필요한 게임 하나를 실행하고 소프트웨어 웹 사이트로 이동하여 실행 명령을 사용 중지하여 문제를 해결했습니다.

내 노트북은 4 년입니다. 오래되었지만 최신 데스크톱보다 더 빠르게 실행됩니다. SWAP 파일이라고하는 메모리 누수 는이 기술을 만든 이후 Windows OS 에서 문제 가되었습니다 . 불행히도 리눅스 개발자들은 발자취를 따라 갔다. 백그라운드에서 실행중인 소프트웨어가 적을수록 (특히 Microsoft의 경우) 더 좋습니다.


-1

스왑을 사용하지 않으면 스왑을 사용하지 말라고 말하고 싶습니다. 아니면 스왑 피스를 줄이십시오. 필요하지 않은 경우 하나를 닳 기가 어렵지만 (최대 대역폭에서 전체 드라이브에 10 만 번 쓰는 데 시간이 얼마나 걸립니까?)

그런 다음 다시 일종의 스왑이 없으면 최대 절전 모드 (디스크 일시 중단)가 작동하지 않습니다.

스왑이없는 이상한 동작이 있었지만 (스왑 할 50MB RAM 디스크에서 승리 할 수 ​​있음), 지난 여름에 패치되었으므로 (또는 2007 년입니까?) 현재 OS에 문제가 없습니다.

이제 우리가 필요로하는 것은 지우기 명령을 지원하는 하드웨어 (Linux는 몇 달 동안 지원 했음)이며 SSD의 수명은 단조로울 것입니다.


TRIM 명령은 SSD의 수명을 연장하기 위해 아무 작업도하지 않습니다. 블록 지우기를 실행하여 더러운 블록을 대역 외에서 정리합니다. 정상적인 동작은 SSD가 블록을 다시 쓸 때 지우기를 실행하는 것입니다. 결과적으로 TRIM을 사용하면 잠재적으로 더 나은 성능을 얻을 수 있지만 SSD는 여전히 같은 수의 지우기 및 쓰기 명령을 실행합니다.
Daniel Lawson

사실, 그것은 단지 그들이 더 잘 수행하게 할 것입니다.
로널드 포톨

Daniel (및 Ronald) : SSD가 TRIM 덕분에 "디스크"섹션이 비워 지거나 0으로 설정되었음을 알고 있으면 쓰기 레벨링을 수행하거나 소규모 쓰기를 관리 할 때이를 복사하지 않을 것입니다. 쓰기가 적고 수명이 길다는 것을 의미합니까? 고체 보인다 나와 함께 동의 일부 소스 : atpinc.com/Memory-insider/... superuser.com/questions/1063744/... wiki.archlinux.org/index.php/Solid_state_drive#TRIM - 에지의 경우 등 훌륭한 자원
Matthew Elvey

-2

2 개의 엔터프라이즈 급 SSD가 매우 조기에 (즉, 보증 기간 내에) 소진되었습니다 . 스 래싱으로 인해 그 이유가 크게 바뀌 었다고 생각합니다. 나는 종종 메모리 누수로 데몬을 실행 / 버기하는 불필요한 프로세스가 필요하다는 것을 깨달았습니다. 나는 iostat -n9 -w 10때때로 백그라운드에서 실행 하며 종종 지속적으로 많은 디스크 활동이 있음을 알 수 있습니다. 또한 커널 프로세스 (스왑) 활동이 대부분의 I / O 소스로 기록되었습니다. 몇 달 동안 메모리 누수가 발생하여 주기적으로 종료해야하는 데몬이 하나 있습니다. 시스템이 느리게 진행되지 않는 한 종종 문제를 해결하지 않으므로 데몬을 다시 시작하는 데 시간이 걸리기 전에 오랫동안 스 래싱이 발생했습니다. 누출이 해결되기까지 더 이상.

스와핑을 비활성화하면 스 래싱에주의를 기울일 수 있지만 SSD의 주요 마모가 발생하기 전에 문제가 해결 될 수 있지만 이러한 손상을 방지하는 가장 좋은 방법은 아닙니다. 적절한 모니터링 / 경고 도구가 더 좋습니다.

많은 답변이 인정하지 못하는주의 사항은 서버 가 SSD를 지속적으로 스 래싱 하는 경우이 상황 에서 1 년 이내에 꽤 빨리 소손 될 것 입니다. 클래식 스 래싱은 일반적으로 가상 메모리 스와핑이 (스왑) 드라이브를 거의 사용 중으로 유지할 수있을 정도로 무겁고 최대 I / O 대역폭의 크기 내에서 스왑 관련 I /를 기다리는 프로세스가 하나 이상있을 때 발생합니다. 시스템이 해당 상태에있는 대부분의 시간을 완료하려면 O를 누르십시오. 다른 답변 은 시스템 이 그렇지 않다고 가정 합니다.적어도 고전적인 방식으로 스레 싱; 또는 스 래싱이 무엇인지에 대한 오해에 의존합니다. 그리고 다른 정확한 데이터에도 불구하고 잘못된 가정은 SSD가 스왑 파일의 유일한 가능한 위치 인 경우에도 WHY 페이징에 대한 잘못된 답변으로 이어집니다.


-3

사용하지 않는 메모리가 많은 경우 디스크에서 페이지 파일을 비활성화하십시오. 일부 오래된 프로그램은 페이지 파일 기능이 필요하며 이러한 Windows의 경우 메모리에 작은 페이지 파일 기능을 만듭니다.


2
더 이상 당신과 동의하지 않았습니다. 이 포스터가 연결되는 질문에 대해 허용 된 답변을 살펴보십시오.
Chopper3

2
Windows가 메모리에 페이지 파일을 생성합니까? 어떻게한다는거야?
Mark Sowul
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.