por que o cpulimit faz o processo PARADO?

Question

Estou executando um script python que usa o pacote networkx para executar alguns algoritmos em gráficos.

o script é

import networkx as nx
from networkx.algorithms.approximation import clique

G = nx.read_adjlist("newman_one_mode.adj")
print "the number of nodes in the graph is: " + str(G.number_of_nodes())
max_clique_nodes = clique.max_clique(G)
print "the clique nodes are: " + str(max_clique_nodes)

Demora muito tempo e tem alto uso da CPU (99%), por isso quero limitar o uso da CPU.

Eu usei o cpulimit nesse processo para limitar o uso da cpu a 60%

cpulimit -p 29780 -l 60

no entanto, quando eu uso, o processo ficou STOPPED, como abaixo

[lily@geland academic]$ python run.py
the number of nodes in the graph is: 16264

[1]+  Stopped                 python run.py

o que está errado e como lidar com tais situações? obrigado!

informações secundárias: se eu não executar o cpulimit, o processo é executado por um longo tempo e depois é morto, não sei por que, talvez seja devido ao uso do recurso.

[lily@geland academic]$ python run.py
the number of nodes in the graph is: 16264
[1]+  Terminated              python run.py
Killed

    

Answer 1

Esse é o comportamento esperado.

O cpulimit suspende o processo quando consome muitos recursos da CPU e retoma o processo após um determinado período de tempo.

Verifique também se o seu script está aguardando entrada. Em caso afirmativo, seu script também entrará em um estado interrompido.

Tente redirecionar o stdin e execute o cpulimit novamente, por exemplo, python run.py < /dev/null &

    

Answer 2

Você provavelmente estaria melhor com legal como a forma cpulimit é um pouco invasiva e pode jogar mal com o controle do trabalho de shell e outros mecanismos.

Como nice é um recurso do sistema operacional que altera as prioridades de agendamento, isso é muito mais fácil do que o cpulimit , que permite que um processo seja executado com a rapidez que deseja até ter excedido um percentual após o qual obtém um SIGSTOP, seguido por um sono e um SIGCONT.

Como um exemplo simples, considere este script de shell "copiar um monte de zeros para lugar nenhum":

$ cat waster
#!/bin/sh
dd if=/dev/zero of=/dev/null count=${1}000000

$ time ./waster 5     # takes about 3.7 seconds on my machine
$ time ./waster 10    # takes about 7.4 seconds, no surprise

agora execute-os ao mesmo tempo:

$ time ./waster 5 & time ./waster 10 &

estes levam 7,1 segundos e 11,1 segundos porque estão lutando pela CPU. Mas se eu adicionar nice

$ time ./waster 5 & time nice -n 19 ./waster 10 &

então o primeiro leva cerca de 4,0 segundos e o bom leva 12,9 segundos porque o bom toma a prioridade mais baixa possível, permitindo que o primeiro pegue a maior parte do processador possível. E nenhum processo é interrompido a qualquer momento.

    

Answer 3

Na página de manual:

cpulimit always sends the SIGSTOP and SIGCONT signals to a process, both to verify that it can control it and to limit the average amount of CPU it consumes. This can result in misleading (annoying) job control messages that indicate that the job has been stopped (when actually it was, but immediately restarted). This can also cause issues with interactive shells that detect or otherwise depend on SIGSTOP/SIGCONT. For example, you may place a job in the foreground, only to see it immediately stopped and restarted in the background.

Fonte: link

→ isso significa que é um problema com o shell, que o processo continua rodando em segundo plano, mas seu shell não está conectado.

Dependendo do que você deseja alcançar, você pode redirecionar a saída para um arquivo, se depender da saída ou reconectar o seu shell se precisar de uma sessão interativa.