私はグラフでいくつかのアルゴリズムを実行するためにnetworkxパッケージを使用するPythonスクリプトを実行しています。
スクリプトは
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)
時間がかかり、CPU使用量(99%)が高いため、CPU使用量を制限したいと思います。
このプロセスでは、cpulimitを使用してCPU使用率を60%に制限します。
cpulimit -p 29780 -l 60
ちなみに使用すると、以下のようにプロセスが停止します。
[lily@geland academic]$ python run.py
the number of nodes in the graph is: 16264
[1]+ Stopped python run.py
何が間違っていて、この状況をどのように処理するのですか?ありがとうございます!
追加情報: cpulimitを実行しないと、プロセスは長時間実行されてから終了します。理由はわかりません。おそらくリソースが枯渇しているからです。
[lily@geland academic]$ python run.py
the number of nodes in the graph is: 16264
[1]+ Terminated python run.py
Killed
答え1
これは予想される動作です。
cpulimit は CPU リソースが多すぎるとプロセスを一時停止し、一定時間が経過するとプロセスを再開します。
また、スクリプトが入力を待っていることを確認してください。その場合、スクリプトも停止した状態になります。
stdinをリダイレクトしてcpulimitを再実行してみてください。例:python run.py < /dev/null &
答え2
あなたはもっと良いかもしれません。いいねこれはcpulimit
少しハッキングされており、シェルの操作制御や他のメカニズムではうまく機能しない可能性があるためです。
nice
これはスケジューリング優先順位を変更するオペレーティングシステムの機能であるため、cpulimit
プロセスが特定の割合を超えるまで所望の速度で実行し、SIGSTOP信号を受信して省電力モードに切り替えるよりもはるかにスムーズです。 、信号制御。
簡単な例として、「どこにもゼロをコピーしない」シェルスクリプトを考えてみましょう。
$ 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
今すぐ実行します。
$ time ./waster 5 & time ./waster 10 &
CPUを置いて競うため、7.1秒、11.1秒かかります。しかし、私が付け加えるとnice
$ time ./waster 5 & time nice -n 19 ./waster 10 &
その後、最初は約4.0秒かかり、「nice」は12.9秒かかります。これは、「nice」ができるだけ低い優先順位を持ち、最初のものができるだけ多くのCPUリソースを占有できるためです。そしてプロセスは停止しません。
答え3
マンページから:
cpulimitは常にSIGSTOPおよびSIGCONT信号をプロセスに送信し、プロセスを制御および消費する平均CPU量を制限できることを確認します。これにより、ジョブが停止したことを示す誤った(迷惑な)ジョブ制御メッセージが表示されることがあります(実際には停止しましたがすぐに再開されます)。これにより、SIGSTOP / SIGCONTに依存する検出または対話型シェルに問題が発生する可能性があります。たとえば、ジョブをフォアグラウンドに配置し、そのジョブが直ちに停止してバックグラウンドで再開することがわかります。
源泉:http://manpages.ubuntu.com/manpages/xenial/man1/cpulimit.1.html
→これはシェルに問題があることを意味します。プロセスはバックグラウンドで実行され続けますが、シェルは接続されません。
達成する目的に応じて、出力をファイルにリダイレクトしたり、対話型セッションが必要な場合はシェルを再接続することができます。