值得記念的一天，幾秒鐘就把公司的openlava搞崩潰了

本人在某IC公司，有百臺左右服務器，用於跑電路仿真，之前公司配置了lsf，今天剛剛切換到openlava，寫了個程序作processer limitation測試，結果中間出了點bug，幾秒鐘就把公司的openlava搞崩潰了。

具體過程是這樣的。原本openlava queue上設置了UJOB_LIMIT爲20，須要測試這個，可是後來這個限制被註釋掉了，我不知道。我寫了個multi-thread的程序B，每次執行程序B會佔用5個thread，而後寫了個程序A，每次執行程序A會執行20次"bsub B",經過調整A中job的數目和B中thread的數目來觀測openlava queue上對job數目和thread數目的限制是否起做用，結果我在A中誤將「bsub B」寫成了「bsub A」，幾秒鐘後公司的openlava sever down掉了，down掉以前我瞅了一眼，已經提交了500000+ jobs。

我一琢磨，我乾的這個事情剛好和第一代計算機病毒的原理是同樣的。

首先本地將任務A提交到openlava上，openlava machine上程序A又將本身自己從新向openlava提交20次，這樣程序A以20的幾何級數不斷提交，在openlava total job number缺少限制的狀況下，程序A短期內不斷提交自身達百萬次，openlava severl不堪重負迅速崩潰。

好了，我終於闖了大禍了，幾分鐘以後公司的engineer開始一批批來抱怨爲何openlava不工做了，我真不知道該說什麼好了，感謝領導，幫我隱瞞了事情的真相，告訴他們openlava在作壓力測試，稍等。

而後咱們開始擦屁股。

首先我及時終止了local機器上的提交任務，而後嘗試「bkill -r `ps aux | grep <user_name> | grep <script A>` | awk '{print $1}'」，沒有用，openlava sever已經down掉了，沒有迴應。

而後咱們嘗試重啓openlava sever，可是等待半個小時後，openlava仍然沒有迴應。

突然我想到了，上百臺openlava machines上還在源源不斷地執行程序A，程序A像病毒同樣，哪怕openlava重啓過來，也會被海量的bsub請求迅速拖垮。（是否是有點像飽和攻擊？）

而後咱們請求IT幫忙把全部openlava上個人進程都殺死，而後再次重啓openlava sever，好歹openlava的命令可執行了，bqueues通過老牛拉破車通常的等待後終於顯示出來，還有1000000 PEND jobs。

我還覺得重啓openlava sever全部的舊任務就丟了呢，好吧，openlava儘管活過來了，可是仍然苟延殘喘，我還得想辦法殺掉全部的PEND jobs才行，「bkill 0 -u <user_name>」，PEND的job不斷被殺死，十幾分鍾以後，PEND job number減小到900000個，全部的open lava相關指令纔開始可以快速反應。

多麼驚心動魄的一天... ...