→ skylikewater:我是 CentOS 10/19 18:17
推 Bencrie:ps -A|grep matlab|wc -l 抓數量? 10/19 18:27
→ danielsig727:寫過類似功能的 script，就是用樓上那樣抓數量 10/19 19:41
→ danielsig727:然後每幾秒就抓一次數量，小於某值才繼續開 10/19 19:42
→ bitlife:會寫C嗎? 用C寫個小的主程式負責run需要數量的matlab,然後 10/19 19:44
→ bitlife:處理 SIGCHLD 就知道有matlab跑完了,再決定後續動作 10/19 19:45
→ skylikewater:sorry I don't know C, I'll try 2nd & 3rd floor's 10/19 20:03
→ skylikewater:way ! thank for all of you ! 10/19 20:04
→ kdjf:shell(ex.bash)也可以trap signal啊 10/20 00:00
→ rickieyang:bash的 $! 可以抓前一個丟到背景的pid 10/20 00:31
→ bitlife:要處理多個child process結束SIGCHLD需要精確的signal 10/20 09:29
→ bitlife:handling(例如signal block), 才不會signal lost,我不確定 10/20 09:30
→ bitlife:bash有沒有sigblock(.)對應的相關功能,還要bitwise or 來 10/20 09:31
→ bitlife:產生sigmask等,還是用c比較簡單 10/20 09:32
推 yvb:需不需要考慮別人也跑 matlab, 或 matlab 再 fork 出 matlab? 10/20 10:57
→ yvb:如果答案為是, 那就應使用 ps 算數量的方式. 如果答案為否, 10/20 10:58
→ yvb:那就用 for 產生十個背景的 while sub-shell, matlab 直接跑: 10/20 11:00
→ yvb: for ...; do (while true; do matlab; done) & done 10/20 11:02
→ yvb:這樣應該就沒有 SIGCHLD 或抓背景 pid 的問題. 10/20 11:05
→ bitlife:如果別人也需要跑,大家的總和是N,更需要用c,用ps之類方式, 10/20 11:12
→ bitlife:會有race condition,用c的話可以用semaphore來確保總數量 10/20 11:13
→ bitlife:我因為以前常處理這類race condition問題,所以習慣使用一 10/20 11:14
→ bitlife:開始看來似乎overkill的方式,但其實是最安全正確的方式 10/20 11:15
推 danielsig727:想一想樓上說的方式還是最仔細，不過如果因為 racing 10/20 13:20
→ danielsig727:而多開一兩個或許倒也無妨，那就還是用 shell 比較 10/20 13:21
→ danielsig727:簡單 10/20 13:21
→ skylikewater:我昨天實測遇到更白爛的狀況:開FSL (我做影像的) 10/20 13:27
→ skylikewater:結果他某個指令在不同階段會叫出不同程式 10/20 13:27
→ skylikewater:所以會 被偵測到 => 不見了 ! 10/20 13:27
→ skylikewater:於是 ps -A|grep 法讓我的程序瞬間暴增破百 Orz 10/20 13:28
→ skylikewater:感謝樓上各位詳細解釋 我其實看不太懂 試著寫看看:) 10/20 13:29
→ kdjf:jobs可以看現在還有多少活著的child 10/20 13:48
→ bitlife:jobs還是會有race condition,你剛看完說不定又多死了n個 10/20 13:51
推 yvb:用semaphore控制總量,那就要確保大家都這麼跑,不然還是沒用. 10/20 14:24
推 yvb:另外,以原po的問題,避免多生n個才是重點,多死了n個無關當機. 10/20 14:59
→ yvb:原po的 "瞬間暴增破百",如果不會造成什麼問題,也不用太care. 10/20 15:02
→ bitlife:多user又要控制數量,本來就要follow統一架構,其實最好的架 10/20 15:51
→ bitlife:構是priority queue+單一負責執行的主程式,大家把job命令 10/20 15:52
→ bitlife:丟進queue.不過這是題外話,回到多生少生問題,會少生當然也 10/20 15:53
→ bitlife:會多生(多人狀況下),兩個user接近同時發現多出n個容許數量 10/20 15:54
→ bitlife:然後都各執行了n個,就會多出了n個.隨著(接近)同時做這樣事 10/20 15:54
→ bitlife:的user增加,結果就是數量失控. race condition 本來就很討 10/20 15:55
→ bitlife:厭,多無法容許,也只能靠標準做法解決,沒有偷懶步.當然如果 10/20 15:55
→ bitlife:數量控制本來就不嚴格要求,那就真的隨便了,反正race cond 10/20 15:56
→ bitlife:ition發生低率也不高,就看需求怎麼要求就是了 10/20 15:56
→ bitlife: 若無法容許 10/20 15:57
→ bitlife: 機率 10/20 15:57
推 yvb:樓上b大不需要把問題複雜化. 原po的情況,如果是個人電腦, 10/20 22:09
→ yvb:就不需要考慮 "還有別人" 的情況; 如果是公用電腦, 10/20 22:10
→ yvb:除非是管理者之類, 否則也很難要求別人用 "統一架構". 10/20 22:11
→ yvb:再者, 我別述的 "多死了n個無關當機" 是指上面提jobs的情況, 10/20 22:12
→ yvb:這種情況, 除非自己寫錯處理方式, 只會有多死不會有多生. 10/20 22:14
→ yvb: 前述 10/20 22:14
推 bitlife:考慮別人也要跑matlab 是 10/20 10:57 你的推文先說的 10/21 06:57
→ bitlife:我只是順著寫下來,怎麼變成是我把問題複雜化了呢 XD 10/21 06:57
→ bitlife:如果是單位內大家共用,不遵守的就不準用,系統本來就是這樣 10/21 06:59
→ bitlife:管理的 10/21 06:59
→ bitlife:另外個人電腦若執行多個主程式,就相當於別人也要用的情況, 10/21 07:00
→ bitlife:只是這個別人變自己的另一個shell 10/21 07:00
→ bitlife:如果是公用電腦,原po不是管理員或有權制定政策者,最多只能 10/21 07:05
→ bitlife:建議可行方案就是了. 最後我不認為把問題分析清楚是複雜化 10/21 07:06
→ bitlife:,我前面也說了,需求規格要求不嚴,本來就怎麼做都可以,反正 10/21 07:06
→ bitlife:發生機率不高 10/21 07:07
推 yvb:b大,不好意思沒說清楚. 那段推文雖然提到別人跑,但只簡單帶過, 10/21 12:36
→ yvb:其實是假設原po的環境為否的情況 :P 10/21 12:37
推 yvb:否則若是公用電腦,可能不光只是執行matlab的問題, 10/21 12:49
→ yvb:可能還有別的應用程式; 又比如每個人用matlab執行的工作, 10/21 12:51
→ yvb:不盡相同, 對系統資源的需求可能有的很多有的很少, 10/21 12:52
→ yvb:上述各種考慮是否還有別人之類的問題解法,大概都很容易破功 :P 10/21 12:53
推 yvb:也就是說, 真要考慮多人的情況, 可能就不只是數量問題, 10/21 13:34
→ yvb:比方單獨執行時, user a 的 A 程序最多跑 10 個, 再多會當; 10/21 13:35
→ yvb:而 user b 的 B 程序, 最多 5 個; 那兩人同時丟上去跑的話, 10/21 13:37
→ yvb:顯然單算總量都會有問題, 還得對各個程序做些加權計算之類, 10/21 13:40
→ yvb:使得達到A已跑4隻時,B只能最多只能跑3隻之類... 10/21 13:41
→ yvb:但這類複雜情況, 我想應不是原po問題的本意. 10/21 13:45
→ yvb: (而且往往是當機幾次後,才知道跑幾個會當機XD) 10/21 13:46
→ skylikewater:是公用電腦，很多人有跑Matlab，我自己也是admin， 10/21 14:20
→ skylikewater:我們都不是EECS，所以都是靠講好誰要開始跑大程式協 10/21 14:21
→ skylikewater:調的，感謝各位推文，我覺得這是我們未來(有助理)之 10/21 14:21
→ skylikewater:後可以努力的方向Orz 10/21 14:22
推 yvb:其實這類情況, 靠人工協調後, 自行用簡單的方式進行控管, 10/21 15:29
→ yvb:也就夠了. 弄成複雜的樣子再用程式處理, 還不見得管用. 10/21 15:32
→ bitlife:前面有說,最佳solution是大家把job命令列丟到queue,由單一 10/21 16:47
→ bitlife:程式做類似scheduler工作才是最佳solution.甚至可以考慮 10/21 16:48
→ bitlife:priority/loading 等條件 10/21 16:48
→ bitlife:以前台大的cray超級電腦就是這樣,我早上丟job進去,傍晚去 10/21 16:49
→ bitlife:看,沒任何動靜(發現是day SRU用完),後來半夜被執行,沒幾下 10/21 16:50
→ bitlife:就跑完了(在sun工作站要跑好幾天) 10/21 16:50
推 m8403051:有沒有考慮在執行的程序最後加入寫入文字檔? 10/21 17:59
→ m8403051:監控這個檔案就知道跑完沒 10/21 17:59
推 yvb:b大, 您上述的 "單一程式" 在 Linux 其實就是 kernel. 10/21 18:17
→ yvb:原po的 "大當機", 我認為是系統記憶體不足,而大量進行swap, 10/21 18:18
→ yvb:慢到令人無法忍受地慢; 但超級電腦,一方面有極大量的記憶體 10/21 18:21
→ yvb:(可能十T或百T以上等級),另一方面也做記憶體的資源控管, 10/21 18:23
→ yvb:當然沒機會遇到記憶體不足的 "當機". 10/21 18:25
→ yvb:當然相比之下, 一般機器資源少, Linux 的 kernel 也很陽春. 10/21 18:34
→ yvb:就算控制 job 數量, 還是無法保證記憶體使用量. 10/21 18:36
→ bitlife:Kernel的schedule和AP層級考量的重點不同. AP人可以決定哪 10/21 19:08
→ bitlife:些白天run,哪天夜晚run,哪些第一優先run其它先suspend掉等 10/21 19:09
→ bitlife:等.這些在以前迷你電腦年代確實做在OS,但在Unix時又簡化掉 10/21 19:10
→ bitlife:了.原因就是把這種事交還給AP team 10/21 19:10
→ bitlife:當然以上可以用指令去控制,但那還是需要人去操作指令,所以 10/21 19:11
→ bitlife:一旦有這樣子的需求,自然又會寫成AP層級的管理系統 10/21 19:11
→ bitlife:另外throughput絕對不是在當掉前才從最高往下突降到0的,要 10/21 19:13
→ bitlife:throughput最佳化,不能只用當不當掉這個標準. 10/21 19:14
→ bitlife:後續推文已經脫離原po目前權限及資源能考量的情況,我就先 10/21 19:18
→ bitlife:討論到這裏好了 10/21 19:18
推 yvb:b大說得是,但仍需kernel配合,AP層級才有辦法做某些精細的控管. 10/21 22:09
→ yvb:又,雖不是突降到0,但以程序數量的角度,也只能知道再加一就當. 10/21 22:12
→ kdjf:樓上,那就是cgroup了吧？ AP queue可以試試看openpbs 10/22 07:41
推 Wush978:flock ? 10/22 08:36
推 yvb:回樓上上k大,其實cgroup和pbs都只是聞其名,不曾進一步了解:P 10/22 14:56
→ yvb:不知cgroup可否在多個程序總合超出資源限制時,暫停某程序, 10/22 14:57
→ yvb:待資源足夠時再繼續之類? 另外 pbs 是否有跟 cgroup 做結合? 10/22 14:58
→ yvb:^ 甚至進一步 swapout 出記憶體, 待... 10/22 15:02