Antes de mudar os parâmetros de XFS, você precisará entender porque os parâmetros de XFS padrão estão causando problemas de desempenho. Isto envolve compreensão do que seu aplicativo está fazendo, e como o sistema de arquivo está reagindo àquelas operações.
Os problemas de desempenho observáveis que podem ser corrigidos ou reduzidos através do ajuste são geralmente causados pela fragmentação de arquivo ou contenção de recursos no sistema de arquivo. Existem formas diferentes de endereçar estes problemas e em alguns casos reparar o problema irá requerer que o aplicativo, ao invés da configuração de sistema de arquivo, seja modificado.
Se você não passou por este processo anteriormente, recomenda-se que você entre em contato com o engenheiro de suporte da Red Hat para obter assistência.
Otimização para um número grande de arquivos.
O XFS impõe um limite arbitrário para o número de arquivos que um sistema de arquivos pode conter. Em geral, esse limite é alto o suficiente para que ele nunca seja atingido. Se você sabe que o limite padrão será insuficiente antes do tempo, você pode aumentar a percentagem de espaço do sistema de arquivo permitido para inodes com os mkfs.xfs. Se você encontrar o limite do arquivo após a criação do sistema de arquivos (normalmente indicado por erros ENOSPC ao tentar criar um arquivo ou pasta, apesar de espaço livre disponível), você poderá ajustar o limite com os xfs_growfs .
Otimização para um grande número de arquivos em um diretório único
O tamanho do bloco do diretório é fixado para a vida de um sistema de arquivos, e não pode ser alterado, salvo mediante a formatação inicial com mkfs. O bloco mínimo de diretório é o tamanho do bloco do sistema de arquivos, o qual tem como padrão MAX (4 KB, o tamanho do arquivo de bloco do sistema). De um modo geral, não há nenhuma razão para reduzir o tamanho do bloco de diretório.
Como a estrutura de diretório é baseado b-tree, mudar o tamanho do bloco afeta a quantidade de informações de diretório que podem ser recuperadas ou modificados por E/S física. Quanto maior o diretório se torna, mais E/S cada operação irá requerer em um determinado tamanho do bloco.
No entanto, quando maiores tamanhos de bloco de diretório estão em uso, mais CPU é consumida por cada operação de modificação em relação à mesma operação em um sistema de arquivos com um diretório de menor tamanho do bloco. Isto significa que para tamanhos pequenos de diretório, blocos grandes de diretórios irão resultar em menor desempenho modificação. Quando o diretório atinge um tamanho onde E/S é o fator limitante do desempenho, tamanhos grandes de diretórios de bloco possuem um melhor desempenho.
A configuração padrão de um tamanho de bloco de sistema de aquivo de 4 KB e um tamanho de bloco de diretório de 4 KB é o melhor para diretórios com até 1-2 milhões de entradas com um comprimento de nome de bytes 20-40 por entrada. Se o seu sistema de arquivos requer mais entradas, maiores tamanhos de bloco de diretório tendem a ter um melhor desempenho - um tamanho de bloco 16 KB é melhor para sistemas de arquivos com 1-10.000.000 entradas de diretório e um tamanho de bloco 64 KB é melhor para sistemas de arquivos com mais de 10 milhões de entradas de diretório.
Se a carga de trabalho usa pesquisas de diretório aleatórias mais do que modificações (ou seja, as leituras de diretório são muito mais comuns e importantes do que as gravações de diretório), então os limiares acima para aumentar o tamanho do bloco é de aproximadamente uma ordem de magnitude menor.
Otimização para simultaneidade
Ao contrário de outros sistemas de arquivos, o XFS pode realizar vários tipos de operações de alocação e desalocação simultaneamente, desde que as operações estejam ocorrendo em objetos não-compartilhados. Alocação ou desalocação de extensões podem ocorrer simultaneamente, desde que as operações simultâneas ocorram em diferentes grupos de alocação. Da mesma forma, a alocação ou desalocação de inodes podem ocorrer simultaneamente, desde que as operações simultâneas afetem diferentes grupos de alocação.
O número de grupos de alocação torna-se importante quando a utilização de máquinas com uma elevada contagem de CPU e aplicativos multi-threaded que tentam executar operações simultaneamente. Se existir apenas quatro grupos de atribuição, então operações de metadados paralelas e sustentadas serão dimensionadas somente até aquelas quatro CPUs (o limite de simultaneidade fornecida pelo sistema). Para os sistemas de arquivos pequenos, assegure que o número de grupos de atribuição é suportado pela simultaneidade fornecida pelo sistema. Para sistemas de arquivos grandes (dezenas de terabytes e maiores) as opções de formatação padrão geralmente criam grupos de alocação suficientes para não limitar a simultaneidade.
Os aplicativos devem estar cientes de pontos únicos de contenção, a fim de usar o paralelismo inerente à estrutura do sistema de arquivos XFS. Não é possível modificar um diretório ao mesmo tempo, portanto os aplicativos que criam e removem grandes quantidades de arquivos devem evitar o armazenamento de todos os arquivos em um único diretório. Cada diretório criado é colocado em um grupo de alocação diferente, portanto, técnicas, tais como arquivos de hash sobre múltiplos sub-diretórios fornecem um padrão de armazenamento escalável em relação ao uso de um único diretório grande.
Otimização para aplicativos que utilizam atributos estendidos.
XFS pode armazenar pequenos atributos diretamente no inode se houver espaço disponível. Se o atributo encaixa no inodo, então ele pode ser recuperado e modificado sem a necessidade de E/S adicionais para recuperar blocos de atributos distintos. O diferencial de desempenho entre os in-line e atributos out-of-line podem facilmente ser uma ordem de magnitude mais lenta para os atributos de out-of-line.
Para o tamanho do inode padrão de 256 bytes, cerca de 100 bytes de atributo de espaço está disponível, dependendo do número de apontadores de extensão de dados também armazenados no inode. O tamanho de inodo padrão é realmente útil apenas para armazenar um número pequeno de pequenas atributos.
Aumentando o tamanho do inode em tempo mkfs pode aumentar a quantia de espaço disponível para armazenar atributos in-line. Um tamanho de inode de 512 bytes aumenta o espaço disponível para cerca de 350 bytes. Um inode de 2 KB possui cerca de 1900 bytes de espaço disponível.
Existe, no entanto, um limite para o tamanho dos atributos individuais que podem ser armazenados in-line - existe um limite máximo de tamanho de 254 bytes para o nome de atributo e o valor (isto é, um atributo com um comprimento de nome de 254 bytes e um comprimento de 254 bytes valor ficará in-line). Exceder esses limites de tamanho obriga os atributos de linha, mesmo que não tenha espaço suficiente para armazenar todos os atributos do inode.
Otimização para modificações de metadados sustentados.
O tamanho do log é o principal fator na determinação do nível possível de modificação de metadados sustentados. O dispositivo de log é circular, portanto, antes da parte final poder ser sobrescrita, todas as modificações no registro devem ser gravadas no local real no disco. Isto pode envolver uma quantidade significativa de procura para reproduzir todos os metadados sujos. A configuração padrão escala o tamanho do log em relação ao tamanho do sistema de arquivos em geral, assim, na maioria dos casos o tamanho do log não vai precisar de ajuste.
Um dispositivo de log pequeno irá resultar em write-back de metadados muito freqüente - o registro será constantemente empurrado em sua parte final para liberar espaço e assim metadados freqüentemente modificados serão freqüentemente gravados no disco, fazendo com que as operações sejam lentas.
Aumentar o tamanho do log aumenta o período de tempo entre eventos que empurram sua parte final. Isso permite uma melhor agregação de metadados sujos, resultando em melhores padrões de write-back de metadados, e menos de write-back de metadados frequentemente alterados. O compromisso é que os logs maiores requeiram mais memória para acompanhar todas as mudanças pendentes na memória.
Se você tem uma máquina com memória limitada, então logs grandes não são benéficos porque restrições de memória causarão write-back de metadados muito antes de obter benefícios de um grande log. Nestes casos, os registros menores, em vez de maiores, muitas vezes, fornecem um melhor desempenho porque write-back de metadados a partir do registro a falta de espaço é mais eficiente que o write-back impulsionado pela recuperação da memória.
Você deveria tentar sempre alinhar o log com a unidade de faixa adjacente que contenha o sistema de arquivo. O mkfs faz isto por padrão para os dispositivos MD e DM, mas para o hardware RAID é possível que precise ser especificado. Configurá-lo corretamente evita todas as possibilidades do log de E/S causar uma E/S desalinhada e operações subsequentes de leitura-modificar-gravação ao gravar as modificações em disco.
Operação de log pode ser melhorada através da edição de opções de montagem. Aumentar o tamanho dos buffers de log na memória (ogbsize) aumenta a velocidade com que as mudanças podem ser gravadas no log. O tamanho do buffer de log padrão é MAX (32 KB, unidade de faixa de log), e o tamanho máximo é de 256 KB. Em geral, um maior valor resulta em desempenho mais rápido. No entanto, sob cargas de trabalho fsync-pesadas, buffers de log pequenos podem ser visivelmente mais rápidos do que os grandes buffers grandes com um grande alinhamento da unidade de faixa.
A opção de montagem delaylog também melhora o desempenho de modificação de metadados sustentados, reduzindo o número de alterações no log. Ela consegue isso através da agregação de mudanças individuais na memória antes de gravá-los no log: metadados modificados freqüentemente é gravado no log periodicamente em vez de em cada modificação. Essa opção aumenta o uso de memória de rastreamento de metadados sujos e aumenta as operações de perdas potenciais quando ocorre um travamento, mas pode melhorar a velocidade de modificação de metadados e escalabilidade por uma ordem de magnitude ou mais. O uso desta opção não reduz a dados ou a integridade de metadados quando fsync, fdatasync ou sync são usados para garantir que os dados e metadados sejam gravados no disco.
