이것은 나를 당혹스럽게 만들고 ZFS가 실제로 수행하는 작업을 자세히 알아볼 수 있는 방법을 모릅니다.
나는 테스트를 위해 빠른 ZFS 풀(빠른 7200에서 가져온 미러)과 단독 UFS SSD가 포함된 FreeNAS 11.1을 새로 설치하고 있습니다. 구성은 거의 "즉시 사용 가능"합니다.
SSD에는 콘솔을 사용하여 풀에 복사된 16~120GB 크기의 파일 4개가 포함되어 있습니다. 풀은 중복 제거되었으며(가치: 4배 절약, 디스크 크기 12TB) 시스템에는 넉넉한 RAM(128GB ECC)과 빠른 Xeon이 있습니다. 메모리는 충분합니다. zdb풀에 총 121M 블록(디스크에 각각 544바이트, RAM에 각각 175바이트)이 있으므로 전체 DDT는 약 20.3GB(데이터 TB당 약 1.7GB)에 불과합니다.
하지만 파일을 풀에 복사하면 다음과 같이 표시됩니다 zpool iostat.
1분 정도의 낮은 수준 읽기와 짧은 쓰기 버스트 주기를 수행합니다. 읽은 부분이 그림에 표시되어 있습니다. 작업의 전체 쓰기 속도도 좋지 않습니다. 풀은 45%/10TB가 비어 있고 기본적으로 약 300 - 500MB/s로 쓸 수 있습니다.
확인 방법을 모르면 낮은 수준의 읽기가 DDT 및 기타 메타데이터를 읽는 것에서 비롯된 것이라고 의심됩니다. ARC에 미리 로드되지 않았거나 파일 데이터가 기록되면서 ARC에서 지속적으로 밀려나기 때문입니다. 아마도.
어쩌면 중복 제거 항목을 찾는 것이 적중하여 글을 많이 쓰지 않을 수도 있습니다. 단지 이 파일의 dup 버전을 기억하지 못하고 제가 기억하는 한 /dev/random에서 동일한 작업을 수행합니다(이 내용을 확인하고 곧 업데이트하겠습니다). 아마도. 진짜 모르겠어요.
최적화를 위해 현재 상황을 보다 정확하게 조사하려면 어떻게 해야 합니까?
RAM 및 중복 제거 업데이트:
초기 의견에 따라 DDT 크기를 표시하도록 Q를 업데이트했습니다. 중복 제거 RAM은 종종 TB당 5GB x 4로 인용되지만 이는 실제로 중복 제거에 적합하지 않은 예를 기반으로 한 것입니다. 블록 수에 항목당 바이트를 곱하여 계산해야 합니다. 자주 인용되는 "x 4"는 단지 "소프트" 기본 제한일 뿐입니다. 기본적으로 ZFS는 더 많이 사용하라는 지시가 없는 한 메타데이터를 ARC의 25%로 제한합니다. 이 시스템은 중복 제거용으로 지정되었으며 저는 64GB를 추가했습니다.모두메타데이터 캐싱 속도를 높이는 데 사용할 수 있습니다).
따라서 이 풀에서는 zdb전체 DDT에 TB당 5GB(총 20G)가 아닌 TB당 1.7GB만 필요하다는 것을 확인하고 메타데이터에 25%(123G 중 80G)가 아닌 ARC의 70%를 제공하게 되어 기쁩니다.
그 크기에서는 배출할 필요가 없습니다.아무것ARC의 '죽은' 파일 콘텐츠가 아닌 경우. 그래서 실제로 ZFS를 조사하여 무슨 일이 일어나고 있는지 알아보고 변경 사항의 효과를 확인할 수 있습니다. 엄청난 "낮은 수준 읽기" 양에 정말 놀랐기 때문입니다. 자신이 하고 있다고 생각하는 일의 현실을 조사하고 확인하는 방법입니다.