ZFS 성능 : 풀 또는 파일 시스템에 여유 공간을 유지해야합니까?

ZFS의 성능은 사용 가능한 공간의 양에 크게 좌우된다는 것을 알고 있습니다.

풀 공간을 80 % 미만으로 유지하여 풀 성능을 유지하십시오. 현재 풀이 매우 가득 차서 사용중인 메일 서버와 같이 파일 시스템이 자주 업데이트되면 풀 성능이 저하 될 수 있습니다. 풀이 가득 차면 성능이 저하 될 수 있지만 다른 문제는 없습니다. [...] 95-96 % 범위의 대부분 정적 콘텐츠를 사용하더라도 쓰기, 읽기 및 리 실버 링 성능이 저하 될 수 있습니다. ZFS_Best_Practices_Guide, solarisinternals.com (archive.org)

이제 ZFS 파일 시스템을 호스팅하는 10T의 raidz2 풀이 있다고 가정합니다 volume. 이제 자식 파일 시스템을 만들고 volume/test5T 예약을합니다.

그런 다음 NFS 당 두 파일 시스템을 일부 호스트에 마운트하고 일부 작업을 수행합니다. volume나머지 5T는 (으)로 예약되어 있으므로 5T 이상을 쓸 수 없다는 것을 이해합니다 volume/test.

내 첫 번째 질문은 어떻게 성능 저하, 나는 채우기가 내 의지 경우입니다 volume~ 5T로 마운트 지점? 해당 파일 시스템에 ZFS의 COW (Copy-On-Write) 및 기타 메타 항목을위한 여유 공간이 없기 때문에 삭제됩니까? 또는 ZFS가 예약 된 공간 내 여유 공간을 사용할 수 있으므로 동일하게 유지 volume/test됩니까?

이제 두 번째 질문 입니다. 다음과 같이 설정을 변경하면 차이가 있습니까? volume이제 두 개의 파일 시스템을 가지고 volume/test1와 volume/test2. 둘 다 각각 3T 예약이 주어 지지만 할당량은 없습니다. 이제 7T를로 가정합니다 test1. 두 파일 시스템의 성능이 동일합니까, 모든 파일 시스템마다 다릅니 까? 떨어 뜨리거나 동일하게 유지됩니까?

감사!

예. 수영장에 여유 공간을 유지해야합니다. 주로 COW (Copy-On-Write) 작업 및 스냅 샷에 사용됩니다. 사용률이 약 85 %이면 성능이 저하됩니다. 더 높이 갈 수는 있지만 확실한 영향이 있습니다.

예약을 망설이지 마십시오. 특히 NFS의 경우. 필요하지 않다. NFS가 아닌 zvol 일 수 있습니다.

그래도 혼란은 보이지 않습니다. 10T를 가지고 있다면 85 % 이상 사용하지 마십시오. 할당량 을 사용하여 주식 한도 를 적절하게 조정하고 사용 한도 를 정하십시오. 또는 할당량을 사용하지 않고 전체 풀 사용량을 모니터링하십시오 .

zpool 이 가득 찼거나 조각난 경우 성능이 저하됩니다 . ZFS와 함께 사용되는 자유 블록 검색 메커니즘이 그 이유입니다. NTFS 또는 ext3과 같은 다른 파일 시스템과는 달리 어떤 블록이 사용되는지 그리고 어떤 블록이 사용 가능한지를 나타내는 블록 비트 맵이 없습니다. 대신 ZFS는 zvol을 "metaslabs"라고하는 (대개 200 개) 더 큰 영역으로 나누고 각 메타 슬랩에 사용 가능한 블록 정보 (공간 맵)의 AVL 트리 ¹ 을 저장 합니다. 균형 AVL 트리를 사용하면 요청의 크기에 맞는 블록을 효율적으로 검색 할 수 있습니다.

이 메커니즘은 규모의 이유로 선택되었지만 불행히도 높은 수준의 조각화 및 / 또는 공간 활용이 발생하면 큰 고통으로 판명되었습니다. 모든 메타 슬래브가 많은 양의 데이터를 전달하자마자 풀이 비어있을 때 적은 수의 큰 영역이 아닌 많은 수의 작은 여유 영역이 생깁니다. ZFS가 2MB의 공간을 할당해야하는 경우 모든 메타 슬래브의 공간 맵을 읽고 평가하여 적합한 블록을 찾거나 2MB를 더 작은 블록으로 나누는 방법을 시작합니다. 물론 시간이 좀 걸립니다. 더 나쁜 것은 ZFS가 실제 디스크에서 모든 공간 맵을 실제로 읽을 때 많은 I / O 작업이 필요하다는 사실입니다 . 들어 있는 당신의 쓰기.

성능 저하가 심각 할 수 있습니다. 예쁜 그림을 좋아한다면 Delphix 의 블로그 게시물을 살펴보십시오.이 게시물 은 일부 단순화되었지만 유효한 zfs 풀에서 가져온 숫자가 있습니다. 필자는 그래프 중 하나를 뻔뻔스럽게 훔치고 있습니다.이 그래프에서 파란색, 빨간색, 노란색 및 녹색 선을 보면 쓰기 처리량에 비해 10 %, 50 %, 75 % 및 93 % 용량의 풀을 나타냅니다. 시간이 지남에 따라 조각화되는 KB / s :

이것에 대한 빠르고 더러운 수정은 전통적으로 메타 슬랩 디버깅 모드 였습니다 ( echo metaslab_debug/W1 | mdb -kw설정을 즉시 변경하기 위해 런타임에 문제 만 ). 이 경우 모든 공간 맵은 OS RAM에 유지되므로 각 쓰기 작업에서 지나치게 비싼 I / O가 필요하지 않습니다. 궁극적으로 이는 특히 대용량 풀의 경우 더 많은 메모리가 필요하다는 것을 의미하므로 스토리지 경마를위한 일종의 RAM입니다. 10TB 풀은 아마도 2-4GB의 메모리 ² 비용이 들지만 많은 번거 로움없이 활용률을 95 %까지 높일 수 있습니다.

¹ 좀 더 복잡합니다. 관심이 있으시면 우주지도 에서 Bonwick의 게시물 을 참조하십시오.

² 메모리의 상한을 계산하는 방법이 필요한 경우 각 메타 슬래브에서 현재 사용중인 zdb -mm <pool>수를 검색하고 segments최악의 시나리오를 모델링하기 위해이를 2로 나눕니다 (각 점유 된 세그먼트 뒤에는 하나가 있습니다) )에 AVL 노드의 레코드 크기를 곱하십시오 (zfs의 128 비트 특성 및 64 비트 주소 지정의 경우 두 개의 메모리 포인터 및 값은 최대 32 바이트가되지만 사람들은 일반적으로 64 바이트를 가정하는 것으로 보입니다) 이유).

zdb -mm tank | awk '/segments/ {s+=$2}END {s*=32/2; printf("Space map size sum = %d\n",s)}'

참고 : Markus Kovero가 zfs-discuss 메일 링리스트에 올린이 게시물 에는 기본 개요가 포함되어 있지만 계산에서 실수를했다고 생각합니다.