Escrevendo por debaixo dos panos | Duda
janeiro 3, 2014 dezembro 30, 2014 Duda
No JFS, as páginas que sofrem alteração ficam armazenadas na memória cache até que a quantidade de clusters de 16 KB atinja o valor igual ao parâmetro numclust. Ao acumular esta quantidade, os dados destes clusters são descarregados da memória cache para o disco logo que uma operação de escrita ocorrer no próximo cluster sequencial.
Os dados da operação de escrita que ativa o Write-Behind não são imediatamente descarregados para o disco, mas terão que esperar que a quantidade de páginas modificadas atinja novamente o valor de numclust.
No JFS2, o conceito é similar, exceto que o número de páginas por cluster é um parâmetro que pode ser ajustado: j2_nPagesPerWriteBehindCluster.
Este mecanismo distribui a carga de I/O de maneira mais eficiente do que fazer gravações síncronas, ou esperar a execução do processo syncd – que a cada 60 segundos descarrega as dirty pages para o disco. Sem o Write-Behind, as páginas modificadas ficariam na memória cache até que o processo do syncd seja executado. Isso poderia causar gargalos de I/O e, possivelmente, aumentar a fragmentação dos arquivos.
Os limites que disparam o Write-Behind são baseados em arquivos e, portanto, os dados são descarregados para o disco antes do processo syncd entrar em operação, distribuindo a carga de I/O de maneira mais uniforme e executando as operações de escrita de um único arquivo sequencialmente.
O ajuste do Write-Behind sequencial depende do sistema de arquivos. No JFS, o tamanho do cluster é 16 KB, equivalente a 4 páginas. O número de clusters que o gerenciador de memória virtual usa como limite é um valor ajustável, cujo padrão é 1.
Portanto, no JFS é possível atrasar o Write-Behind aumentando o valor do parâmetro numclust. Isto irá permitir que pequenas operações de escrita sejam agrupadas em grandes lotes e, dessa maneira, conseguir melhor desempenho de escrita sequencial.
O seguinte comando pode ser usado para aumentar o valor do parâmetro numclust para sistemas de arquivos JFS:
# ioo -o numclust
No JFS2, o número de páginas por cluster é um valor ajustável (ao invés do número de clusters como no JFS). O padrão é 32 páginas (128 KB). Isto pode ser alterado com o comando:
# ioo -o j2_nPagesPerWriteBehindCluster
Para desabilitar o Write-Behind, modifique o valor de numclust (JFS) ou j2_nPagesPerWriteBehindCluster (JFS2) para 0.
Já vimos como funciona o Write-Behind para operações de escrita sequenciais, porém, o que acontece quando a carga de trabalho é predominantemente de operações randômicas?
Neste cenário, o padrão de I/O não atende aos requisitos do algoritmo do Write-Behind sequencial, acumulando várias dirty pages na memória antes que o processo do syncd execute a sincronização. Caso a aplicação modifique muitas páginas na memória de modo randômico, uma grande quantidade de dados será descarregada para o disco quando o syncd entrar em operação.
O Write-Behind randômico provê um mecanismo para tratar essa situação. Quando o número de dirty pages modificadas de maneira randômica para um arquivo excede um determinado limite, estas páginas são automaticamente descarregadas para o disco.
No JFS, o parâmetro maxrandwrt especifica o limite (em páginas de 4 KB) para as operações de escrita randômicas acumuladas na memória RAM antes das páginas subsequentes dispararem o processo de escrita no disco. O valor padrão é 0, indicando que ele está desabilitado.
Aumentando este valor para 128 significa que, uma vez que 128 operações de escrita randômicas ocorrerem, qualquer operação de escrita subsequente irá descarregar as dirty pages equivalentes no disco – tanto o primeiro conjunto de páginas, como a última página modificada.
Este limite poderá ser ajustado através do comando:
# ioo -o maxrandwrt
No JFS2, o algoritmo do Write-Behind considera as operações de escrita como randômicas apenas quando a distância entre duas operações consecutivas estiverem separadas por um valor ajustável, que define o número de clusters.
Existem dois limites para o sistema de arquivos JFS2.
O parâmetro, j2_nRandomCluster, especifica a distância em clusters que as operações de escrita tem que exceder para que elas sejam consideradas randômicas pelo algoritmo. O tamanho do cluster, neste contexto, é fixo em 16 KB. O padrão é 0, o que significa que qualquer operação de escrita não-sequencial para diferentes clusters será considerada randômica. Este limite pode ser ajustado pelo comando:
# ioo -o j2_nRandomCluster
O parâmetro, j2_maxRandomWrite, especifica o limite para operações de escrita randômicas que serão acumuladas na memória RAM antes que a operação de escrita subsequente descarregue os dados para o disco. Assim como no Write-Behind sequencial, este limite é baseado em arquivo. O valor padrão é 0, indicando que o algoritmo de Write-Behind randômico é desabilitado para qualquer sistema de arquivos JFS2.
Este parâmetro pode ser ajustado com o comando:
# ioo -o j2_maxRandomWrite
"Longo é o caminho ensinado pela teoria, curto e eficaz o do exemplo." – Sêneca
Quem sou eu para duvidar desse cara? Então, vamos a um exemplo de Write-Behind randômico:
j2_nRandomCluster é igual a 4.
j2_maxRandomWrite é igual a 1.
Portanto, duas operações de escrita consecutivas devem estar pelo menos 16 páginas de distância para serem consideradas randômicas.
Estas 16 páginas de separação são obtidas através do seguinte cálculo:
j2_nRandomCluster * 16 KB; no qual é 4 * 16 KB = 64 KB = 16 páginas.
As primeiras duas operações de escrita consecutivas, uma na página de número 4 e outra na página 12, não são consideradas randômicas pois a distância que as separa é de apenas 8 páginas (12 – 4), o que não excede os requerimentos do parâmetro j2_nRandomCluster.
As próximas operações de escrita consecutivas, uma na página 7 e outra na páginas 28, são consideradas randômicas pois a distância que as separa é de 21 páginas (28 -7), o que é maior que as 16 páginas definidas pelo parâmetro j2_nRandomCluster. Neste caso, a página de número 7 será descarregada para o disco.
O ajuste do parâmetro j2_maxRandomWrite permite acumular uma quantidade de páginas randômicas na memória para serem descarregadas antes mesmo do processo syncd. Cabe ao administrador realizar a análise da carga de I/O para determinar se há benefícios em habilitar o algoritmo do Write-Behind randômico e qual o melhor valor para este parâmetro.
Brown, Martin (26-10-2010).Optimizing AIX 7 performance: Part 3, Tune with ioo, filemon, fileplace, JFS and JFS2. developerWorks. Acessado em 10-12-2013.