Supondo que o conselho de espaço livre paraZEVOnão será diferente dos conselhos para outras implementações modernas do ZFS…
Pergunta
Por favor, o queporcentagensouvaloresde espaço livre é aconselhável para unidades de disco rígido dos seguintes tamanhos?
- 640GB
- 2 TB
Pensamentos
Uma resposta padrão para implementações modernas do ZFS pode ser "não mais que 96% cheia". No entanto, se aplicar isso a (digamos) um conjunto de dados de disco único de 640 GB, onde alguns dos arquivos mais comumente usados (pelo VirtualBox) sãomaiores que 15 GB cada, então acho que os blocos para esses arquivos se tornarãodistribuição subótimaatravés das travessas com cerca26GB grátis.
Li que na maioria dos casos a fragmentação e a desfragmentação não devem ser uma preocupação do ZFS. Ainda assim, gosto da imagem mental da maioria dos fragmentos de um grande .vdi razoavelmente próximos uns dos outros. (Os recursos do ZFS tornam esse desejo de proximidade muito antiquado?)
Nota lateral: pode surgir a questão de como otimizar o desempenho (para arquivos enormes em um conjunto de dados com relativamente pouco espaço livre)depoisum limite é 'quebrado'. Se surgir, vou mantê-lo separado.
Fundo
Em um StoreJet Transcend de 640 GB (ID do produto 0x2329) no passado provavelmente ultrapassei um limite aconselhável. Atualmente o maior arquivo tem cerca de 17 GB –
– e duvido que qualquer .vdi ou outro arquivo neste disco ultrapasse 40 GB. (Ignore as massas roxas, são pacotes de 8 MBbandaarquivos.)
Sem HFS Plus: os limites devinte, dez e cinco por cento que associo ao sistema de arquivos Mobile Time Machine não precisam ser aplicados.
Atualmente uso o ZEVO Community Edition 1.1.1 com Mountain Lion, OS X 10.8.2, mas gostaria que as respostas não fossem muito específicas da versão.
Referências, ordem cronológica
Alocação de blocos ZFS (Blog de Jeff Bonwick)(04-11-2006)
Mapas espaciais (blog de Jeff Bonwick)(13/09/2007)
Dobrando o desempenho do Exchange (Bizarro! Você já disse Bizarro?)(11/03/2010)
… Portanto, para resolver este problema, o que aconteceu no lançamento do software 2010/Q1 é multifacetado. O mais importante é: aumentamos o limite no qual passamos de 'primeiro ajuste' (ir rápido) para 'melhor ajuste' (pacote apertado), de 70% cheio para 96% cheio. Com unidades TB, cada placa tem pelo menos 5 GB e 4% ainda é 200 MB de espaço suficiente e não há necessidade de fazer nada radical antes disso. Isso nos deu o maior estrondo. Segundo, em vez de tentar reutilizar as mesmas placas primárias até que uma alocação falhasse, decidimos parar de dar à placa primária essa ameaça preferencial assim que a maior alocação que poderia ser satisfeita por uma placa caísse para 128K (
metaslab_df_alloc_threshold). Nesse ponto estávamos prontos para mudar para outra laje que tivesse mais espaço livre. Também decidimos reduzir o bônus SMO. Antes, preferia-se uma laje 50% vazia a lajes que nunca haviam sido utilizadas. Para promover mais agregação de gravação, reduzimos o limite para 33% vazio. Isso significa que uma carga de trabalho de gravação aleatória agora se espalha para mais blocos, onde cada um terá maior quantidade de espaço livre, levando a mais agregação de gravação. Por fim, também vimos que o carregamento da laje estava contribuindo para um desempenho inferior e implementamos um mecanismo de pré-busca da laje para reduzir o tempo de inatividade associado a essa operação.A conjunção de todas essas mudanças leva a uma melhoria de 50% no OLTP e a uma redução de 70% na variabilidade de execução para execução…
Melhorias de OLTP no Sun Storage 7000 2010.Q1 (perfis de desempenho)(11/03/2010)
Alasdair em tudo » ZFS é executadorealmentelentamente quando o uso do disco livre ultrapassa 80% (18/07/2010) onde os comentários incluem:
…O OpenSolaris mudou isso na revisão onnv 11146…
[CFT] Código metaslab ZFS aprimorado (velocidade de gravação mais rápida)(22/08/2010)
Responder1
Oitenta por cento cheio (vinte por cento grátis)
http://www.ustream.tv/recorded/25859777audível por volta das 33h na linha do tempo, em resposta aO caso de Eric Sproul:
… o produto Delphix … para o usuário foi de oitenta por cento. Então, quero dizer, muito disso depende da carga de trabalho, mas nós definitivamente... Acho que quatro por cento seriamextremopara qualquer …
… Eo desempenho seria péssimo.
- soa comoMatt Ahrens(moderando) no Illumos 2012Dia ZFS.
Mais: recentemente redescoberto por mim, há dois anos:
Sob#8 Deixe espaço livre suficiente:
… Como regra geral, não deixe sua piscina ficar mais cheia do que cerca de 80% de sua capacidade. Quando chegar a esse ponto, você deverá começar a adicionar mais discos para que o ZFS tenha blocos livres suficientes para escolher na ordem de gravação sequencial.
Responder2
Cerca de oitenta e cinco por cento cheio (quinze por cento grátis)
http://www.ustream.tv/recorded/25859777por volta das 32h20 na linha do tempo:
… quatro por cento grátis? … Isso parece… um pouco perto do limite. Tentamos atingir cerca de oitenta e cinco por cento da capacidade antes de começarmos a pensar em expandir a capacidade ou fazer algo para aliviar essa pressão... somos bastante conservadores...
Então, por volta das 33h20, em resposta aocomentário de oitenta por cento:
Sim, se você tentou fazeresseem um sistema noventa e seis por cento cheio, você provavelmente ficaria sem espaço antes de terminar o que quer que estivesse fazendo... porque o espaço se acumularia; e ter esse instantâneo presente manteria dados que, de outra forma, seriam liberados da atividade normal para o pool...
… Eo desempenho seria péssimo. Como o ZFS funciona em um alocador de placas... se você ficar muito cheio, começará a gastar mais tempo procurando lugares para acomodar diferentes tamanhos de coisas, e isso fica muito lento.
–Eric Sproulno Illumos 2012Dia ZFS.