O que poderia ser a causa para ir ao estado de sono profundo uniterunciável para este processo de fabricação específico?

1

Estou tentando entender o estado 'D' corretamente.

No meu caso, o processo a seguir foi para 'D' state:

make -f freac/CMakeFiles/freac_objs.dir/build.make freac/CMakeFiles/freac_objs.dir/build

Ele está usando o compartilhamento NFS.

Além disso, a carga continua aumentando. load_avg está agora em 1600 (40 CPUs). Eu acho que 40 é um limite aceitável para 40 processadores.

Ok, deixando isso, três coisas que quero saber:

  1. Por que a carga aumenta quando um processo está em 'D' state?
  2. Por que um processo vai para 'D' state se o acesso a um compartilhamento NFS for problemático, em vez de o processo ser completamente eliminado?
  3. O que poderia causar um problema súbito ao acessar o compartilhamento NFS (poderia ser devido à rede na maioria dos casos?)

Obrigado!

    
por GP92 21.06.2016 / 14:25

1 resposta

3

Um processo no estado 'D' é normalmente (mas não sempre) "bloqueado na espera de E / S". Isso pode acontecer se um disco estiver ocupado e sofrendo tempos de serviço altos, por exemplo. O processo em D indica a média de carga, mesmo que não esteja usando recursos reais da CPU.

No caso do NFS, um processo pode passar muito tempo no estado 'D' aguardando o servidor NFS responder.

O comportamento padrão de um cliente NFS é tentar novamente por até 60 segundos (consulte a opção timeo de man nfs ) antes de tentar novamente. Isso significará que um processo pode estar na espera de E / S por pelo menos 60 segundos se houver um problema.

O que acontece, então, dependerá da configuração retrans e das configurações hard/soft .

Se o sistema de arquivos estiver montado hard , as tentativas ocorrerão indefinidamente; se montado soft , a solicitação de E / S finalmente falhará. Mas podemos ver que isso não é imediato por causa das opções timeo e retrans .

Os clientes podem ver problemas de NFS por vários motivos; uma comum é a largura de banda da rede (especialmente se você estiver em uma rede WiFi). Outro é o volume de pedidos (se você executar coisas em paralelo, você pode estar causando um gargalo). O servidor, por si só, pode estar sofrendo com um desempenho ruim do disco e, portanto, respondendo lentamente a solicitações NFS, ou o servidor pode não estar executando threads daemon suficientes para lidar com o volume de solicitações.

    
por 21.06.2016 / 14:47