Considerações sobre desempenho

Esta página fornece orientações sobre como configurar o ambiente do Parallelstore para obter a melhor performance.

Recomendações gerais

• Remova todos os aliases de ls para melhorar a performance padrão. Em muitos sistemas, ele tem o alias ls -color=auto, que é muito mais lento com a configuração padrão do Parallelstore.

• Se a performance das operações de lista for lenta, ative o armazenamento em cache para a montagem dfuse.

Biblioteca de interceptação

A biblioteca libioil pode ser usada para melhorar o desempenho das operações de leitura e gravação no DFuse de aplicativos que usam libc. A biblioteca ignora o kernel interceptando chamadas de leitura e gravação POSIX do aplicativo para atendê-las diretamente no espaço do usuário. Consulte a biblioteca de intercepção para mais detalhes.

Na maioria dos casos, recomendamos usar a biblioteca de intercepção em uma invocação por processo ou por aplicativo.

As situações em que você não quer ou não precisa usar a biblioteca de intercepção incluem as seguintes:

• Somente aplicativos criados com libc podem usar a biblioteca de interceptação.
• Se você tiver uma carga de trabalho que se beneficia do armazenamento em cache, como acessar os mesmos arquivos repetidamente, recomendamos não usar a biblioteca de interceptação.
• Se a carga de trabalho for intensiva em metadados, como trabalhar com muitos arquivos pequenos ou uma lista de diretórios muito grande, a biblioteca de interceptação provavelmente não vai melhorar o desempenho.

A invocação LD_PRELOAD pode ser definida como uma variável de ambiente no ambiente de shell, mas isso pode causar problemas. Recomendamos especificar o comando com cada comando.

Como alternativa, é possível vincular a biblioteca de intercepção ao app no momento da compilação com a flag -lioil.

Armazenamento em cache de dfuse

O armazenamento em cache é ativado em dfuse por padrão.

Há duas flags relacionadas ao cache usadas por dfuse ao montar uma instância do Parallelstore:

• --disable-wb-cache usa o armazenamento em cache de gravação em vez de gravação de retorno.
• --disable-caching desativa todo o armazenamento em cache.

As sugestões a seguir se aplicam ao armazenamento em cache e à performance:

• Se você estiver usando a biblioteca de intercepção, o armazenamento em cache de gravação de retorno será ignorado. Recomendamos especificar --disable-wb-cache ao usar a biblioteca de intercepção.
• Se a carga de trabalho envolver a leitura de muitos arquivos de uma só vez, desative o armazenamento em cache.
• Para cargas de trabalho que envolvem muitos clientes modificando arquivos e as atualizações precisam estar disponíveis imediatamente para outros clientes, desative o armazenamento em cache.
• Se a carga de trabalho estiver lendo os mesmos arquivos repetidamente, o armazenamento em cache pode melhorar o desempenho. Isso é especialmente verdadeiro se os arquivos se encaixarem na memória dos clientes. O dfuse usa o cache de página do Linux para armazenamento em cache.

• Para cargas de trabalho que consistem em pequenas E/Ss para arquivos grandes, além de ativar o cache, aumentar a leitura antecipada difusa pode ser benéfico. Para aumentar a leitura antecipada difusa, depois que dfuse for montado, execute os seguintes comandos:

  echo 4096 > /sys/class/bdi/\$(mountpoint -d /mnt)/read_ahead_kb
  echo 100 > /sys/class/bdi/\$(mountpoint -d /mnt)/max_ratio
  

Se as cargas de trabalho envolverem uma mistura dos cenários anteriores, será possível montar a mesma instância do Parallelstore em vários pontos de montagem com diferentes configurações de armazenamento em cache.

Contagem de threads e de filas de eventos

Ao montar a instância do Parallelstore, recomendamos os seguintes valores para --thread-count e --eq-count:

• O valor da contagem de linhas não pode exceder o número de núcleos de vCPU.
• O valor máximo recomendado de contagem de linhas é entre 16 e 20. Além desse número, há pouco ou nenhum benefício de desempenho, independentemente do número de cores disponíveis.
• O valor da fila de eventos precisa ser metade do valor da contagem de linhas.

Se a carga de trabalho envolver um número muito alto de operações de arquivos pequenos e acesso intensivo a metadados, tente aumentar os números além dessas recomendações.

Configuração de remoção de arquivos

O striping de arquivos é uma técnica de armazenamento de dados em que um arquivo é dividido em blocos, ou faixas, e distribuído em vários destinos de armazenamento. O striping de arquivos pode aumentar a performance, permitindo leituras e gravações paralelas em mais de um destino de armazenamento que dá suporte à instância.

Ao criar a instância do Parallelstore, você pode especificar uma das três configurações de remoção de arquivos:

• Mínimo
• Equilibrada
• Máximo

Essas configurações podem ter uma importação significativa na performance do Parallelstore. Para a maioria das cargas de trabalho, recomendamos a configuração equilibrada, que é um compromisso razoável para a maioria das cargas de trabalho. Se a performance com a configuração equilibrada não for aceitável:

• A configuração mínima pode melhorar o desempenho de cargas de trabalho com muitos arquivos pequenos, principalmente quando o tamanho médio do arquivo é menor que 256 KB.

• A configuração máxima pode melhorar o desempenho de cargas de trabalho com arquivos muito grandes, geralmente maiores que 8 GB, especialmente quando muitos clientes compartilham o acesso aos mesmos arquivos.

Para ajustes avançados, a ferramenta daos fornece configurações por arquivo ou diretório. Experimentar a otimização avançada traz riscos relacionados ao desempenho e geralmente não é recomendado. Consulte Como entender a redundância de dados e o fragmentação em DAOS para mais detalhes.

Configuração de remoção de diretórios

Ao criar a instância do Parallelstore, é possível especificar uma das três configurações de remoção de diretório:

• Mínimo
• Equilibrada
• Máximo

Para a maioria das cargas de trabalho, recomendamos a configuração máxima.

Para cargas de trabalho que envolvem muitas listagens de diretórios grandes, as configurações equilibradas ou mínimas podem resultar em uma melhor performance de lista. No entanto, o desempenho de outras operações, principalmente a criação de arquivos, pode ser afetado.

multiusuário

Ao usar a ferramenta dfuse para montar a instância do Parallelstore, recomendamos especificar a flag --multi-user. Essa flag informa ao kernel para disponibilizar o sistema de arquivos a todos os usuários em um cliente, em vez de apenas o usuário que executa o processo DFuse. O DFuse aparece como um sistema de arquivos genérico para vários usuários, e as chamadas chown e chgrp padrão são ativadas. Todas as entradas do sistema de arquivos são de propriedade do usuário que as criou, como é normal em um sistema de arquivos POSIX.

Ao especificar a flag --multi-user, você também precisa atualizar /etc/fuse.conf como raiz adicionando a seguinte linha:

user_allow_other

Não parece haver uma implicação de desempenho ao montar sua instância como multiusuário.

Configuração de codificação de exclusão

A codificação de apagamento está definida como 2+1. Não é possível alterar essa configuração. Qualquer E/S que não use EC2+1 é rejeitada.

Alocação de recursos de contêiner sidecar do Google Kubernetes Engine

Na maioria dos casos, a performance insatisfatória com o Google Kubernetes Engine e o Parallelstore é causada por CPU ou memória insuficiente alocada para o contêiner sidecar do Parallelstore. Para alocar recursos corretamente, considere as seguintes sugestões:

• Leia as considerações destacadas em Configurar recursos para o contêiner de arquivo secundário. Você vai aprender por que pode ser necessário aumentar a alocação de recursos e como configurar a alocação de recursos do contêiner sidecar usando anotações de pods.

• É possível usar o valor 0 para desativar todos os limites ou solicitações de recursos em clusters padrão. Por exemplo, ao definir gke-parallelstore/cpu-limit: 0 e gke-parallelstore/memory-limit: 0, os limites de CPU e memória do contêiner do sidecar vão ficar vazios, e as solicitações padrão serão usadas. Essa configuração é útil quando você não sabe quantos recursos o dfuse precisa para as cargas de trabalho e quer que ele use todos os recursos disponíveis em um nó. Depois de descobrir quantos recursos o dfuse precisa com base nas métricas da carga de trabalho, é possível definir os limites apropriados.

• Em clusters do Autopilot, não é possível usar o valor 0 para cancelar a definição dos limites e das solicitações de recursos do contêiner sidecar. É necessário definir explicitamente um limite de recursos maior para o contêiner de sidecar em clusters do Autopilot e usar métricas Google Cloud para decidir se é necessário aumentar o limite de recursos.