值得纪念的一天，几秒钟就把公司的openlava搞崩溃了

值得纪念的一天，几秒钟就把公司的openlava搞崩溃了

weixin_34319111 2017-05-02 20:14:00 363 收藏

文章标签： python awk

原文链接： https://my.oschina.net/liyanqing/blog/890957

版权

一站式学习AI基础知识+核心技术+实操教程+免费工具集

9大课程，边学习边实操，带你通关计算机视觉应用，还有免费工具集和开放平台供所有开发者使用！

2019独角兽企业重金招聘Python工程师标准>>>

本人在某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

相关资源： lsf-admin(openlava)