SSD 풀의 여유 공간이 15% 미만으로 줄어들면 속도가 느려지는 원인은 무엇인가요?

에바 왕기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

SSD 풀이 거의 가득 차면 컨트롤러와 파일 시스템에서 쓰기, 데이터 재배치, 메타데이터, 스냅샷을 처리할 수 있는 정리된 작업 공간이 줄어들기 때문에 속도가 느려지는 경우가 많습니다.

15%라는 지점이 모든 환경에 적용되는 절대적인 한계는 아니지만, 많은 홈 서버 워크로드에서 유용한 경고 기준입니다. 스냅샷, 씬 프로비저닝, 파일 시스템 메타데이터, 삭제되었지만 여전히 열려 있는 파일, discard 지원 부재로 인해 풀에 논리적으로 여유 공간이 남아 있어도 SSD 컨트롤러와 스토리지 소프트웨어가 실제로 재사용할 수 있는 공간은 줄어들 수 있습니다. 대시보드의 단일 백분율에 의존하기보다 실제로 쓸 수 있는 여유 공간과 쓰기 지연 시간을 진단하세요.

어떤 여유 공간 수치가 15%에 도달했는지 확인하세요

원시 SSD 용량, 풀 용량, 파일 시스템 여유 공간, 씬 프로비저닝 할당량, 스냅샷 사용량, 할당량, 예약 블록, 그리고 느리다고 느껴지는 애플리케이션 볼륨을 비교하세요. 이 값들은 서로 다른 질문에 답합니다.

GNU Coreutils는 파일 시스템 사용 가능 공간이 마운트된 파일 시스템의 회계 정보를 기준으로 보고된다고 설명합니다. 이 정보에는 쓰기에 영향을 주는 모든 풀, 스냅샷, 씬 볼륨 또는 컨트롤러 수준의 예약 공간이 포함되지 않을 수 있습니다.

특정 데이터 세트나 씬 볼륨 하나만 거의 가득 찼다면 모든 SSD가 느려졌다고 판단하지 말고 해당 계층을 해결하세요. 풀 전체에 할당되지 않은 용량이 거의 없다면 컨트롤러 작업 공간, discard, 스냅샷을 계속 점검하세요.

NAND 쓰기에 정리된 작업 공간이 필요한 이유를 이해하세요

풀이 기준점을 넘기기 전과 후에 지속 쓰기 및 소규모 무작위 쓰기의 지연 시간을 측정하세요. 읽기 속도는 여전히 양호한데 쓰기가 일시 중지되거나 일관성이 떨어질 수 있습니다.

Crucial은 SSD 오버 프로비저닝을 가비지 컬렉션, 웨어 레벨링, 교체 블록에 사용되는 예약 용량으로 설명합니다. 따라서 쓸 수 있는 여유 공간이 줄어들면 새 데이터를 쓸 때 백그라운드 데이터 재배치가 늘어날 수 있습니다.

모든 성능 저하가 플래시 메모리의 수명 소진을 의미한다고 단정하지 마세요. 정상적인 SSD도 새 쓰기마다 유효한 데이터를 더 많이 지우고, 이동하고, 다시 기록해야 할 때 일시적으로 느려질 수 있습니다.

Discard 또는 TRIM이 SSD에 전달되는지 확인하세요

삭제된 파일 시스템 블록이 지속적으로, 주기적으로 또는 전혀 discard되지 않는지 확인하세요. 파일 시스템과 SSD 사이의 모든 계층을 포함해야 합니다. 암호화, RAID, 씬 프로비저닝, HBA, 가상 디스크, 인클로저도 점검하세요.

Microsoft의 Optimize-Volume retrim 작업은 장치가 해당 영역을 재사용할 수 있도록 삭제된 블록 정보가 스토리지 스택을 통해 전달되어야 한다는 점을 보여줍니다.

파일 시스템 계층에서 명령이 성공했다고 해서 SSD가 discard를 수신했다는 뜻은 아닙니다. 지원되는 trim 작업 전후의 장치 카운터 또는 통제된 쓰기 동작을 비교하고, discard를 안전하게 보존하지 못하는 계층에서는 discard를 활성화하지 마세요.

-15% OFF

스냅샷, 휴지통, 삭제되었지만 열려 있는 파일을 확인하세요

스냅샷, 클론, 보존 폴더, 휴지통, 데이터베이스 로그, 그리고 디렉터리 항목은 삭제되었지만 여전히 열려 있는 파일이 차지하는 공간을 측정하세요. 사용자가 데이터가 삭제되었다고 생각한 뒤에도 이러한 항목이 블록을 계속 할당된 상태로 유지할 수 있습니다.

Oracle의 ZFS 문서는 스냅샷이 참조된 블록을 보존한다고 설명합니다. 따라서 오래된 스냅샷이 해당 블록을 계속 참조하는 동안에는 큰 라이브 파일을 삭제해도 저장 공간이 반환되지 않을 수 있습니다.

정책상 보존 기간을 초과한 보존 지점만 삭제하고, 해당 스냅샷이 어떤 블록을 참조하는지 확인하세요. 큰 스냅샷이라고 해서 자동으로 불필요한 것은 아니며, 긴급하게 삭제하면 최근 변경 사항을 복구할 유일한 경로를 잃을 수 있습니다.

컨트롤러 오버 프로비저닝과 파일 시스템 여유 공간을 구분하세요

각 SSD에 파티션되지 않은 예약 공간, 제조업체가 정의한 예비 영역 또는 호스트 관리 오버 프로비저닝이 있는지 확인하세요. 파일 시스템 여유 공간과 컨트롤러 예약 공간은 서로 관련되어 있지만 목적은 다릅니다.

Kingston은 호스트 오버 프로비저닝이 용량을 할당하지 않은 상태로 남긴다고 설명합니다. 이를 통해 SSD 컨트롤러는 파일 시스템에 표시되는 여유 블록 외에 추가 작업 공간을 확보합니다.

검증된 백업과 지원되는 축소 경로 없이 실행 중인 풀의 크기를 줄이지 마세요. 오버 프로비저닝은 배포 전에 계획하거나 통제된 마이그레이션 중에 도입할 때 가장 안전합니다.

지원되는 Trim을 실행하고 복구 상태를 측정하세요

불필요한 데이터와 스냅샷을 제거한 뒤 부하가 낮은 시간대에 플랫폼에서 지원하는 discard 작업을 실행하세요. 얼마나 많은 바이트가 discard되었는지 기록하고, SSD가 백그라운드 정리를 완료한 후 쓰기 지연 시간이 변하는지 확인하세요.

fstrim 매뉴얼은 discard가 사용하지 않는 파일 시스템 블록에 적용되며, 동일한 영역을 반복해서 trim해도 추가적인 이점이 없을 수 있다고 설명합니다.

Trim 결과가 0바이트로 표시되었다고 해서 자동으로 실패한 것은 아닙니다. 파일 시스템이 이미 trim되었거나 중간 계층에서 discard를 차단하고 있을 수 있습니다. 마운트 옵션을 변경하기 전에 스토리지 스택 자체의 근거를 확인하세요.

여유 공간을 확보하고 실제 병목을 확인하세요

임시 데이터를 이동하고, 정책상 허용되는 스냅샷만 만료 처리하고, 지원되는 경우 데이터베이스를 정리한 뒤 계획된 여유 공간을 확보하세요. 그런 다음 지연 시간, 큐 깊이, CPU 대기 시간, SSD 온도를 측정하면서 동일한 쓰기 워크로드를 반복하세요.

SSD 캐시의 경고 신호에 관한 ZimaSpace 문서는 되돌릴 수 있는 공간 부족 압박과 장치 자체의 고장을 의심할 만한 증거를 구분하는 데 도움이 됩니다.

검증된 여유 공간 또는 discard 복구 후 쓰기 지연 시간이 개선되고, 스냅샷과 메타데이터가 정책 범위 내에 유지되며, 선택한 예약 공간 이상에서 동일한 워크로드가 안정적으로 유지된다면 진단이 완료된 것입니다. 충분한 공간이 있는데도 성능이 좋지 않다면 열 스로틀링, 마모, 컨트롤러 오류, RAID 동작 또는 애플리케이션 I/O를 조사하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.