Com um pouco de experimentação, encontrei quatro soluções possíveis.
Com cada abordagem, você precisa executar as etapas e continuar lendo mais dados para preencher o cache do ZFS ARC e disparar o feed do ARC para o L2ARC. Observe que, se os dados já estiverem armazenados em cache na memória, ou se o tamanho compactado no disco de cada bloco for maior que 32kB, esses métodos geralmente não farão nada.
1. Defina o sinalizador do kernel documentado zfs_prefetch_disable
O L2ARC, por padrão, se recusa a armazenar em cache os dados que foram pré-buscados automaticamente. Podemos ignorar isso desabilitando o recurso de pré-busca do ZFS. Esse sinalizador geralmente é uma boa ideia para cargas de trabalho de banco de dados de qualquer maneira.
echo "zfs_prefetch_disable/W0t1" | mdb -kw
.. ou para defini-lo permanentemente, adicione o seguinte a /etc/system :
set zfs:zfs_prefetch_disable = 1
Agora, quando os arquivos são lidos usando dd , eles ainda estarão qualificados para o L2ARC.
Operacionalmente, essa alteração também melhora o comportamento das leituras em meus testes. Normalmente, quando o ZFS detecta uma leitura sequencial, ele equilibra a taxa de transferência entre os dados vdevs e cache vdevs em vez de apenas ler do cache - mas isso prejudica o desempenho se os dispositivos de cache tiverem latência significativamente menor ou throughput maior do que os dispositivos de dados. / p>
2. Reescreva os dados
Como os dados são gravados em um sistema de arquivos ZFS, eles são armazenados em cache no ARC e (se atenderem aos critérios de tamanho de bloco) são qualificados para serem alimentados no L2ARC. Nem sempre é fácil reescrever dados, mas alguns aplicativos e bancos de dados podem ser executados, por exemplo, através do espelhamento de arquivos no nível do aplicativo ou da movimentação dos arquivos de dados.
Problemas:
- Nem sempre é possível, dependendo do aplicativo.
- Consome espaço extra se houver instantâneos em uso.
- (Mas, do lado bom, os arquivos resultantes são desfragmentados.)
3. Desmarque o sinalizador do kernel não documentado l2arc_noprefetch
Isso se baseia na leitura do código-fonte do OpenSolaris e é, sem dúvida, completamente sem suporte. Use a seu próprio risco.
-
Desative o sinalizador
l2arc_noprefetch:echo "l2arc_noprefetch/W0" | mdb -kwOs dados lidos no ARC enquanto este sinalizador estiver desativado serão elegíveis para o L2ARC, mesmo que seja uma leitura sequencial (desde que os blocos tenham no máximo 32k no disco).
-
Leia o arquivo no disco:
dd if=filename.bin of=/dev/null bs=1024k -
Reabilite o sinalizador
l2arc_noprefetch:echo "l2arc_noprefetch/W1" | mdb -kw
4. Leia os dados aleatoriamente
Eu escrevi um script Perl para ler arquivos em pedaços de 8kB pseudoaleatoriamente (baseado na ordenação de um hash Perl). Pode também funcionar com pedaços maiores, mas ainda não testei isso.
#!/usr/bin/perl -W
my $BLOCK_SIZE = 8*2**10;
my $MAX_ERRS = 5;
foreach my $file (@ARGV) {
print "Reading $file...\n";
my $size;
unless($size = (stat($file))[7]) {print STDERR "Unable to stat file $file.\n"; next; }
unless(open(FILE, "<$file")) {print STDERR "Unable to open file $file.\n"; next; }
my $buf;
my %blocks;
for(my $i=0;$i<$size/$BLOCK_SIZE;$i++) { $blocks{"$i"} = 0; }
my $errs = 0;
foreach my $block (keys %blocks) {
unless(sysseek(FILE, $block*$BLOCK_SIZE, 0) && sysread(FILE, $buf, $BLOCK_SIZE)) {
print STDERR "Error reading $BLOCK_SIZE bytes from offset " . $block * $BLOCK_SIZE . "\n";
if(++$errs == $MAX_ERRS) { print STDERR "Giving up on this file.\n"; last; }
next;
}
}
close(FILE);
}
Problemas:
- Isso leva muito tempo e sobrecarrega o disco.
Problemas restantes
- Os métodos acima colocarão os dados na memória principal, qualificados para alimentar o L2ARC, mas não acionam o feed. A única maneira que sei para acionar a escrita para o L2ARC é continuar lendo dados para pressionar o ARC.
- No Solaris 11.3 com SRU 1.3.9.4.0, apenas raramente o L2ARC aumenta o valor total esperado. O
evict_l2_eligiblekstat aumenta mesmo quando os dispositivos SSD não estão sob pressão, indicando que os dados estão sendo descartados. Esse restante de dados não armazenados em cache tem um efeito desproporcional no desempenho.