여유 공간에 대한 조언을 가정하면제보다른 최신 ZFS 구현에 대한 조언과 다르지 않습니다.
질문
제발, 뭐백분율또는금액다음 크기의 하드 디스크 드라이브에 여유 공간이 권장됩니까?
- 640GB
- 2TB
생각
ZFS의 최신 구현에 대한 표준 대답은 "96% 이하"일 수 있습니다. 그러나 이를 VirtualBox에서 가장 일반적으로 사용되는 일부 파일이 있는 단일 디스크 640GB 데이터 세트에 적용하면각각 15GB보다 큼, 그러면 해당 파일에 대한 블록은 다음과 같이 될 것 같습니다.하위 최적으로 확산주위와 함께 접시를 가로 질러26GB 무료.
대부분의 경우 조각화 및 조각 모음은 ZFS에서 문제가 되지 않아야 한다는 내용을 읽었습니다. 저는 대형 .vdi의 조각 대부분이 서로 상당히 근접해 있다는 마음의 그림을 좋아합니다. (ZFS의 기능으로 인해 근접성을 원하는 것이 너무 구식입니까?)
참고 사항: 성능을 최적화하는 방법에 대한 질문이 발생할 수 있습니다(여유 공간이 상대적으로 적은 데이터 세트의 대용량 파일의 경우).~ 후에임계값이 '깨졌습니다'. 그런 일이 생기면 따로 보관하겠습니다.
배경
과거 640GB StoreJet Transcend(제품 ID 0x2329)에서는 아마도 권장되는 임계값을 넘어섰을 것입니다. 현재 가장 큰 파일은 약 17GB입니다.
– 그리고 이 디스크의 .vdi 또는 기타 파일이 40GB를 초과할지는 의문입니다. (보라색 덩어리는 무시하십시오. 이는 8MB 묶음입니다.밴드파일.)
HFS Plus가 없는 경우: 임계값이십, 모바일 타임머신 파일 시스템과 관련된 10%와 5%는 적용할 필요가 없습니다.
현재 Mountain Lion, OS X 10.8.2와 함께 ZEVO Community Edition 1.1.1을 사용하고 있지만 답변이 버전별로 너무 다르지 않기를 바랍니다.
참고문헌, 연대순
ZFS 블록 할당(Jeff Bonwick의 블로그)(2006-11-04)
우주 지도(Jeff Bonwick의 블로그)(2007-09-13)
두 배의 교환 성능(Bizarre ! Vous avez dit Bizarre ?)(2010-03-11)
… 따라서 이 문제를 해결하기 위해 2010/Q1 소프트웨어 릴리스에는 여러 가지 작업이 이루어졌습니다. 가장 중요한 것은 '첫 번째 맞춤'(빠르게 진행)에서 '최적 맞춤'(밀봉)으로 전환하는 임계값을 70%에서 96%로 늘렸다는 것입니다. TB 드라이브의 경우 각 슬래브는 최소 5GB이고 4%는 여전히 200MB의 충분한 공간이므로 그 전에 급진적인 작업을 수행할 필요가 없습니다. 이것이 우리에게 가장 큰 충격을 안겨주었습니다. 둘째, 할당에 실패할 때까지 동일한 기본 슬래브를 재사용하는 대신 슬래브로 충족할 수 있는 최대 할당이 128K(
metaslab_df_alloc_threshold)로 떨어지자마자 기본 슬래브에 이러한 우선적 위협 제공을 중단하기로 결정했습니다. 그 시점에서 우리는 여유 공간이 더 많은 다른 슬래브로 전환할 준비가 되었습니다. 우리는 또한 SMO 보너스를 줄이기로 결정했습니다. 이전에는 한 번도 사용되지 않은 슬래브보다 50%가 비어 있는 슬래브를 선호했습니다. 더 많은 쓰기 집계를 촉진하기 위해 임계값을 33% 비어 있음으로 줄였습니다. 이는 이제 무작위 쓰기 작업 부하가 더 많은 슬랩으로 확산되어 각 슬랩이 더 많은 여유 공간을 갖게 되어 더 많은 쓰기 집계가 가능함을 의미합니다. 마지막으로 우리는 슬래브 로딩이 성능 저하에 기여한다는 사실을 확인하고 해당 작업과 관련된 가동 중지 시간을 줄이기 위해 슬래브 프리페치 메커니즘을 구현했습니다.이러한 모든 변경 사항을 결합하면 OLTP가 50% 향상되고 실행 간 변동성이 70% 감소합니다.
Sun Storage 7000 2010.Q1의 OLTP 개선 사항(성능 프로필)(2010-03-11)
Alasdair on Everything » ZFS 실행정말여유 디스크 사용량이 80%를 초과하면 속도가 느려집니다. (2010-07-18) 해설에는 다음이 포함됩니다.
… OpenSolaris는 onnv 개정 11146에서 이를 변경했습니다 …
[CFT] ZFS Metaslab 코드 개선(쓰기 속도 향상)(2010-08-22)
답변1
80% 가득 참(20% 무료)
http://www.ustream.tv/recorded/25859777타임라인에서 33:00쯤에 들을 수 있습니다.에릭 스프로울의 사례:
... Delphix 제품은 ... 사용자에게 80%였습니다. 즉, 많은 부분이 작업량에 따라 달라지지만 우리는 분명히… 4%는 될 것이라고 생각합니다.극심한어떠한 것도 …
… 그리고성능이 형편없을 것이다.
- 처럼 들리다매트 아렌스(조정) 2012 Illumos에서ZFS 데이.
게다가: 2년 전 제가 최근에 재발견한 것입니다:
- Oracle Solaris ZFS 성능: 10가지 쉬운 팁(2010-04-28)
… 경험적으로 풀이 용량의 약 80% 이상 채워지지 않도록 하십시오. 해당 지점에 도달하면 ZFS가 순차적 쓰기 순서로 선택할 수 있는 충분한 여유 블록을 갖도록 더 많은 디스크를 추가하기 시작해야 합니다.
답변2
약 85% 찼음(15% 무료)
http://www.ustream.tv/recorded/25859777타임라인에서 약 32:20:
... 4% 무료인가요? … 그건… 조금 가장자리에 가까운 것 같습니다. 우리는 용량 확장이나 그 압박감을 완화하기 위한 조치에 대해 생각하기 전에 약 85% 정도를 채우는 것을 목표로 삼습니다. 우리는 상당히 보수적입니다.
그러다가 33시 20분경에80퍼센트 해설:
응, 네가 그러려고 했다면이것96%가 채워진 시스템에서는 작업을 완료하기도 전에 공간이 부족해질 수 있습니다. 왜냐하면 공간이 축적되기 때문입니다. 해당 스냅샷이 있으면 일반 활동에서 풀로 다시 해제될 데이터가 유지됩니다.
… 그리고성능이 형편없을 것이다. ZFS는 슬랩 할당자에서 작동하기 때문에… 공간이 가득 차면 다양한 크기의 물건에 맞는 장소를 찾는 데 추가 시간을 소비해야 하며 속도가 매우 느려집니다.