本人在某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相关指令才开始能够快速反应。
多么惊心动魄的一天... ...
4970
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
