Como escolher o número de threads nfsd

Question

Eu tenho um servidor baseado em Linux de 8 núcleos dedicado a servir o NFS para 80 clientes linux que executam tarefas em lote. Os clientes têm 400 núcleos no total e, portanto, geralmente executam 400 trabalhos em lote de núcleo único simultaneamente.

Ocasionalmente, muitas tarefas em lote tentam fazer E / S ao mesmo tempo e esgotam o número de threads nfsd no servidor, dos quais existem atualmente 80. A tarefa em lote recebe um erro de E / S (como Permissão negada) e suspensa.

Gostaria de aumentar o número de threads do nfsd, mas quero saber:

• Quais regras existem para definir o número de segmentos nessa situação?
• Quais são as desvantagens de defini-lo muito alto?

Referências

• Este guia de ajuste NFS da Sun sugere algumas regras básicas para o Solaris, mas não dá nenhuma razão para esses números em particular, então não tenho certeza de como eles se aplicam ao meu servidor Linux.
• Esse outro dá uma abordagem a esse tipo de ajuste, mas é altamente subjetivo.

Answer 1

Em um mundo ideal, seus trabalhos em lote teriam alguma lógica de backoff e você usaria 80 threads.

Não sou de forma alguma um especialista em NFSd, mas as regras de threading do Linux que se aplicam a todos os aplicativos Linux devem ser aplicadas. A regra aqui é que cada thread ocupa uma certa quantidade de espaço na memória, realisticamente, essa quantidade de memória é tão pequena em um servidor de produção médio (com dois dígitos de RAM) que é praticamente não-consequencial, a preocupação mais urgente é a maneira em que os threads são implementados em aplicativos como o NFSd - Semaphores. Os semáforos de contagem são uma excelente maneira de garantir que nenhuma condição de bloqueio ocorra em uma situação de encadeamento, o problema é que os semáforos rastreiam os encadeamentos e incrementam e decrementam um contador para refletir encadeamentos 'livres' vs. 'bloqueados', para fazer isso, eles devem indexar encadeamentos disponíveis e verificar isso em encadeamentos bloqueados para provisionar o tempo de execução apropriadamente, isso é feito de uma maneira semi-eficiente que cresce exponencialmente, se o NFSd requer quantidades muito altas de velocidade, você notará um aumento na computação tempo aproximadamente equivalente a duplicar o tempo de execução para registrar um novo thread, por sorte, este é um valor de tempo de pesquisa tão pequeno (uma instrução) para começar (Chamado a base se você lembra Álgebra :), que você pode ter expoentes muito grandes sem quaisquer problemas importantes.

O Demasiado Longo; Não Read summation - Se eu fosse você, limitaria o número de threads ao seu número esperado de hosts simultâneos no máximo, mas também faria alguns testes para garantir que o tempo de execução seja são com seus valores esperados. Estou ciente de que provavelmente não é muito útil para você, mas é muito difícil analisar a configuração apropriada sem os cenários de uso esperado.

Além disso, se você extrapolar os números da Sun, um processador de 2,2 GHZ deve ser capaz de rodar em algum lugar nos reinos de 800 encadeamentos sem problemas, mesmo se esses números forem essencialmente arbitrários, isso me dá a sentindo que você vai ficar bem com a minha sugestão anterior

    

Answer 2

Não use o NFS. O NFS é ótimo para acesso a arquivos menores, mas desmorona sob qualquer tipo de carga. Você já investigou algumas das outras tecnologias, como o AFS ou o Hadoop?