值得记念的一天，几秒钟就把公司的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相关指令才开始可以快速反应。

多么惊心动魄的一天... ...