[問題] 監控程序結束

看板Linux作者 (choc.)時間10年前 (2013/10/19 18:17), 編輯推噓16(16推 0噓 99→)
留言115則, 9人參與, 最新討論串1/1
不知道用什麼關鍵字，找了一陣子了， 才上來問...如果這問題太蠢了請鞭小力點 Orz 我想要監控程序結束執行與否，來決定要不要繼續執行下一批資料 舉個例子： $ matlab (程序) & 我用 for + if 控制開超過十個就暫停 (sleep) 但程式執行的時間很難抓，如果暫停的時間太短會大當機。 而程序每次都是自動開的，不會先知道 PID 我也沒辦法靠查詢 ps 去看有沒有結束（是嗎）？ 請各位指教我該怎麼監督他是否執行完畢？ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.112.121.113
→
10/19 18:17, , 1F
我是 CentOS
10/19 18:17, 1F
推
10/19 18:27, , 2F
ps -A|grep matlab|wc -l 抓數量?
10/19 18:27, 2F
→
10/19 19:41, , 3F
寫過類似功能的 script，就是用樓上那樣抓數量
10/19 19:41, 3F
→
10/19 19:42, , 4F
然後每幾秒就抓一次數量，小於某值才繼續開
10/19 19:42, 4F
→
10/19 19:44, , 5F
會寫C嗎? 用C寫個小的主程式負責run需要數量的matlab,然後
10/19 19:44, 5F
→
10/19 19:45, , 6F
處理 SIGCHLD 就知道有matlab跑完了,再決定後續動作
10/19 19:45, 6F
→
10/19 20:03, , 7F
sorry I don't know C, I'll try 2nd & 3rd floor's
10/19 20:03, 7F
→
10/19 20:04, , 8F
way ! thank for all of you !
10/19 20:04, 8F
→
10/20 00:00, , 9F
shell(ex.bash)也可以trap signal啊
10/20 00:00, 9F
→
10/20 00:31, , 10F
bash的 $! 可以抓前一個丟到背景的pid
10/20 00:31, 10F
→
10/20 09:29, , 11F
要處理多個child process結束SIGCHLD需要精確的signal
10/20 09:29, 11F
→
10/20 09:30, , 12F
handling(例如signal block), 才不會signal lost,我不確定
10/20 09:30, 12F
→
10/20 09:31, , 13F
bash有沒有sigblock(.)對應的相關功能,還要bitwise or 來
10/20 09:31, 13F
→
10/20 09:32, , 14F
產生sigmask等,還是用c比較簡單
10/20 09:32, 14F
推
10/20 10:57, , 15F
需不需要考慮別人也跑 matlab, 或 matlab 再 fork 出 matlab?
10/20 10:57, 15F
→
10/20 10:58, , 16F
如果答案為是, 那就應使用 ps 算數量的方式. 如果答案為否,
10/20 10:58, 16F
→
10/20 11:00, , 17F
那就用 for 產生十個背景的 while sub-shell, matlab 直接跑:
10/20 11:00, 17F
→
10/20 11:02, , 18F
for ...; do (while true; do matlab; done) & done
10/20 11:02, 18F
→
10/20 11:05, , 19F
這樣應該就沒有 SIGCHLD 或抓背景 pid 的問題.
10/20 11:05, 19F
→
10/20 11:12, , 20F
如果別人也需要跑,大家的總和是N,更需要用c,用ps之類方式,
10/20 11:12, 20F
→
10/20 11:13, , 21F
會有race condition,用c的話可以用semaphore來確保總數量
10/20 11:13, 21F
→
10/20 11:14, , 22F
我因為以前常處理這類race condition問題,所以習慣使用一
10/20 11:14, 22F
→
10/20 11:15, , 23F
開始看來似乎overkill的方式,但其實是最安全正確的方式
10/20 11:15, 23F
推
10/20 13:20, , 24F
想一想樓上說的方式還是最仔細，不過如果因為 racing
10/20 13:20, 24F
→
10/20 13:21, , 25F
而多開一兩個或許倒也無妨，那就還是用 shell 比較
10/20 13:21, 25F
→
10/20 13:21, , 26F
簡單
10/20 13:21, 26F
→
10/20 13:27, , 27F
我昨天實測遇到更白爛的狀況:開FSL (我做影像的)
10/20 13:27, 27F
→
10/20 13:27, , 28F
結果他某個指令在不同階段會叫出不同程式
10/20 13:27, 28F
→
10/20 13:27, , 29F
所以會 被偵測到 => 不見了 !
10/20 13:27, 29F
→
10/20 13:28, , 30F
於是 ps -A|grep 法讓我的程序瞬間暴增破百 Orz
10/20 13:28, 30F
→
10/20 13:29, , 31F
感謝樓上各位詳細解釋 我其實看不太懂 試著寫看看:)
10/20 13:29, 31F
→
10/20 13:48, , 32F
jobs可以看現在還有多少活著的child
10/20 13:48, 32F
→
10/20 13:51, , 33F
jobs還是會有race condition,你剛看完說不定又多死了n個
10/20 13:51, 33F
推
10/20 14:24, , 34F
用semaphore控制總量,那就要確保大家都這麼跑,不然還是沒用.
10/20 14:24, 34F
推
10/20 14:59, , 35F
另外,以原po的問題,避免多生n個才是重點,多死了n個無關當機.
10/20 14:59, 35F
→
10/20 15:02, , 36F
原po的 "瞬間暴增破百",如果不會造成什麼問題,也不用太care.
10/20 15:02, 36F
→
10/20 15:51, , 37F
多user又要控制數量,本來就要follow統一架構,其實最好的架
10/20 15:51, 37F
→
10/20 15:52, , 38F
構是priority queue+單一負責執行的主程式,大家把job命令
10/20 15:52, 38F
→
10/20 15:53, , 39F
丟進queue.不過這是題外話,回到多生少生問題,會少生當然也
10/20 15:53, 39F
還有 36 則推文
→
10/21 13:46, , 76F
(而且往往是當機幾次後,才知道跑幾個會當機XD)
10/21 13:46, 76F
→
10/21 14:20, , 77F
是公用電腦，很多人有跑Matlab，我自己也是admin，
10/21 14:20, 77F
→
10/21 14:21, , 78F
我們都不是EECS，所以都是靠講好誰要開始跑大程式協
10/21 14:21, 78F
→
10/21 14:21, , 79F
調的，感謝各位推文，我覺得這是我們未來(有助理)之
10/21 14:21, 79F
→
10/21 14:22, , 80F
後可以努力的方向Orz
10/21 14:22, 80F
推
10/21 15:29, , 81F
其實這類情況, 靠人工協調後, 自行用簡單的方式進行控管,
10/21 15:29, 81F
→
10/21 15:32, , 82F
也就夠了. 弄成複雜的樣子再用程式處理, 還不見得管用.
10/21 15:32, 82F
→
10/21 16:47, , 83F
前面有說,最佳solution是大家把job命令列丟到queue,由單一
10/21 16:47, 83F
→
10/21 16:48, , 84F
程式做類似scheduler工作才是最佳solution.甚至可以考慮
10/21 16:48, 84F
→
10/21 16:48, , 85F
priority/loading 等條件
10/21 16:48, 85F
→
10/21 16:49, , 86F
以前台大的cray超級電腦就是這樣,我早上丟job進去,傍晚去
10/21 16:49, 86F
→
10/21 16:50, , 87F
看,沒任何動靜(發現是day SRU用完),後來半夜被執行,沒幾下
10/21 16:50, 87F
→
10/21 16:50, , 88F
就跑完了(在sun工作站要跑好幾天)
10/21 16:50, 88F
推
10/21 17:59, , 89F
有沒有考慮在執行的程序最後加入寫入文字檔?
10/21 17:59, 89F
→
10/21 17:59, , 90F
監控這個檔案就知道跑完沒
10/21 17:59, 90F
推
10/21 18:17, , 91F
b大, 您上述的 "單一程式" 在 Linux 其實就是 kernel.
10/21 18:17, 91F
→
10/21 18:18, , 92F
原po的 "大當機", 我認為是系統記憶體不足,而大量進行swap,
10/21 18:18, 92F
→
10/21 18:21, , 93F
慢到令人無法忍受地慢; 但超級電腦,一方面有極大量的記憶體
10/21 18:21, 93F
→
10/21 18:23, , 94F
(可能十T或百T以上等級),另一方面也做記憶體的資源控管,
10/21 18:23, 94F
→
10/21 18:25, , 95F
當然沒機會遇到記憶體不足的 "當機".
10/21 18:25, 95F
→
10/21 18:34, , 96F
當然相比之下, 一般機器資源少, Linux 的 kernel 也很陽春.
10/21 18:34, 96F
→
10/21 18:36, , 97F
就算控制 job 數量, 還是無法保證記憶體使用量.
10/21 18:36, 97F
→
10/21 19:08, , 98F
Kernel的schedule和AP層級考量的重點不同. AP人可以決定哪
10/21 19:08, 98F
→
10/21 19:09, , 99F
些白天run,哪天夜晚run,哪些第一優先run其它先suspend掉等
10/21 19:09, 99F
→
10/21 19:10, , 100F
等.這些在以前迷你電腦年代確實做在OS,但在Unix時又簡化掉
10/21 19:10, 100F
→
10/21 19:10, , 101F
了.原因就是把這種事交還給AP team
10/21 19:10, 101F
→
10/21 19:11, , 102F
當然以上可以用指令去控制,但那還是需要人去操作指令,所以
10/21 19:11, 102F
→
10/21 19:11, , 103F
一旦有這樣子的需求,自然又會寫成AP層級的管理系統
10/21 19:11, 103F
→
10/21 19:13, , 104F
另外throughput絕對不是在當掉前才從最高往下突降到0的,要
10/21 19:13, 104F
→
10/21 19:14, , 105F
throughput最佳化,不能只用當不當掉這個標準.
10/21 19:14, 105F
→
10/21 19:18, , 106F
後續推文已經脫離原po目前權限及資源能考量的情況,我就先
10/21 19:18, 106F
→
10/21 19:18, , 107F
討論到這裏好了
10/21 19:18, 107F
推
10/21 22:09, , 108F
b大說得是,但仍需kernel配合,AP層級才有辦法做某些精細的控管.
10/21 22:09, 108F
→
10/21 22:12, , 109F
又,雖不是突降到0,但以程序數量的角度,也只能知道再加一就當.
10/21 22:12, 109F
→
10/22 07:41, , 110F
樓上,那就是cgroup了吧？ AP queue可以試試看openpbs
10/22 07:41, 110F
推
10/22 08:36, , 111F
flock ?
10/22 08:36, 111F
推
10/22 14:56, , 112F
回樓上上k大,其實cgroup和pbs都只是聞其名,不曾進一步了解:P
10/22 14:56, 112F
→
10/22 14:57, , 113F
不知cgroup可否在多個程序總合超出資源限制時,暫停某程序,
10/22 14:57, 113F
→
10/22 14:58, , 114F
待資源足夠時再繼續之類? 另外 pbs 是否有跟 cgroup 做結合?
10/22 14:58, 114F
→
10/22 15:02, , 115F
^ 甚至進一步 swapout 出記憶體, 待...
10/22 15:02, 115F
‣ 更多 skylikewater 的文章
文章代碼(AID): #1IObmk65 (Linux)