值得纪念的一天,几秒钟就把公司的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相关指令才开始能够快速反应。
多么惊心动魄的一天... ...
转载于:https://my.oschina.net/liyanqing/blog/890957