Processos no Mac OSX ficando 'presos' e uso estranho da CPU

Question

Eu trabalho em uma instituição científica e uma das tarefas em que estou trabalhando atualmente envolve a execução de simulações e a saída dos dados que ela produz on-the-fly para o disco rígido. Quando digo 'on-the-fly', quero dizer que o próprio programa envia dados para o disco a cada segundo ou mais. Estas simulações são escritas apenas em um único thread C ++ e são executadas em um Mac Pro. As especificações relevantes deste Mac são as seguintes:

OSX Version: 10.6.8
Model Name: Mac Pro
Model Identifier: MacPro4,1
Processor Name: Quad-Core Intel Xeon
Processor Speed: 2.66 GHz
Number Of Processors: 2
Total Number Of Cores: 8

Os Intel Xeon são hyperthreaded para até 8 núcleos virtuais

Eu executo minhas simulações em um arquivo .sh simples, usando a seguinte sintaxe:

nohup simulation1.o configfile 2> /dev/null > /dev/null &
nohup simulation2.o configfile 2> /dev/null > /dev/null &

e assim por diante ...

Usar nohup significa que não preciso me preocupar com desconexões aleatórias quando trabalho remotamente.

Quando olho para ps depois de executar, digamos 10, simulações usando meu arquivo bash, descubro que na coluna STATE, os processos mudam regularmente de 'em execução' para 'emperrado'. Além disso, eu esperaria que o uso da CPU fosse 100% para cada processo, mas cada processo tem uma média de 28% cada. (Minha expectativa de que o uso da CPU seja 100% para cada processo é que quando eu executo apenas uma dessas simulações, a coluna da CPU está no máximo em 100%, adicionada ao fato de os núcleos terem hyperthreading. .)

Alguém sabe o que está acontecendo? Especificamente:

• O que significa "preso", em relação a ps
• Por que a CPU não está maximizada para cada processo?

Eu apreciaria muito a ajuda.

    

Answer 1

Eu consertei meu problema. Acabou sendo bastante sutil, mas graças a Ozair - ele acertou na cabeça. Minha simulação específica não lê muitos dados (apenas os parâmetros de inicialização), mas gasta muito tempo cuspindo dados calculados. O caminho bruto que eu implementei originalmente, envolvendo o padrão c ++ file.open("tobewritten.dat") é muito lento, até mesmo por conta própria, mas quando várias instâncias são executadas, as instâncias individuais gastam idades esperando por 'write time' no disco rígido.

Há algumas lições específicas que aprendi:

1. cout << std::endl libera o buffer em uso; se o buffer não estiver cheio, então há menos que o uso ideal da operação mais rápida de gravação na RAM. Use "\n" e feche o arquivo no final. O c ++ manipula a liberação do buffer para o disco quando ele está cheio.

2. Ao escrever vários arquivos de dados massivos (eu estou falando GBs) ao mesmo tempo, é melhor especificar manualmente o buffer. No momento, eu configurei o buffer para 50MB. Usar grandes buffers significa que seu sistema gasta mais tempo entre a RAM e a CPU e apenas despeja no disco (o bit lento) em intervalos de 50MB

3. Nem use cout para gravar no arquivo. É mais lento que sprintf e suas variantes.

Usando os métodos que descrevi acima, passei de 28% de uso da CPU para cada processo para 100% de uso da CPU. O STADO 'preso' não aparece mais.