问题现象美女同事找我解决一个问题,说Tomcat启动很慢。开始我以为是程序写的问题,所以把webapps下所有程序都删除掉。(只保留Tomcat自带)灵异的事情发生了,Tomcat停止在—— 我查看了一下进程,Tomcat所在的JVM进程已经被启动了所以可以排除是JVM退出引起的问题。那么问题真的就是JVM因为某种原因被 阻塞 了。 分析问题比较棘手,我排除了CPU、内存不足引起的问题;排除了硬盘空间不足引起的问题;我甚至去观察了网络I/O、硬盘I/O情况,都非常正常。程序被 阻塞 一般来说一定是要等待某个资源,而现在的情况是所有资源都充足,所以我几乎想不到是什么问题引起的。 我开始怀疑是KVM Hypervisor虚拟化的问题(用的是虚拟机)我改变了策略在VMWare开了两台虚拟机上直接下载Tomcat启动。其中一台很快启动,另一台居然也被 阻塞 ,问题被重现了。 眼看要在美女面前丢脸,我光辉伟岸的形象要荡然无存。这种情况下我不能去“撸”代码吧?况且Tomcat那么多人用,真有这么明显的Bug早就炸开锅了。(Tomcat还是很靠谱的不像xxxxStack那么狗屎)仔细想想我需要找到Tomcat停止在了哪里?代码里发生了什么事情,但是我又不可能去撸代码。无可奈何的情况下我决定试一下 strace ,这是一个 跟踪系统调用(System Call)的工具 ,无论是Java还是Pyhton很多资源申请都会变成都会变成System Call。(比如打开文件、新建线程、读写数据、等待I/O)通过这个工具我至少可以知道 Tomcat是停止在哪个System Call上的 ,这样可以方便我推断出问题的原因。
strace -f -o strace.out ./catalina.sh run
strace有很多参数,我用了二个参数
其他参数请自行搜索 下面分析strace.out文件,分析的方法是从下往上(被 阻塞 的地方肯定是在最后咯)。首先我们需要去掉Tomcat停止引起的System Call,它们不是我们需要的。从后往前搜索找到 深入分析如果用Tomcat /dev/random作为关键字基本上就能够回答我们的疑惑了。Tocmat的Session ID是通过SHA1算法计算得到的,计算Session ID的时候必须有一个密钥。为了提高安全性Tomcat在启动的时候回通过随机生成一个密钥。 在 http://wiki.apache.org/tomcat/HowTo/FasterStartUp (Entropy Source部分)有一段解释。stackoverflow上面也有一大批这方面的说明,所以这里就不再多做介绍。 明白了问题的原因解决起来就非常简单了——替换/dev/random为/dev/unrandom,用伪随机函数生成器(/dev/urandom)来替代随机函数生成器(/dev/random)。
当然JVM的开发者不是傻瓜,Tomcat的开发者也不是二百五。他们之所以没有选择/dev/urandom是为了提高系统的安全性,/dev/urandom并不是真正的随机行为。(其实一般情况下/dev/urandom也是足够安全的不太容易被“重复”) 彻底解决问题
上面介绍的两种方式都是用/dev/urandom替换/dev/random,其实还有第三种方式——增大/dev/random的熵池。问题的原因是由于熵池不够大,所以增大它是最彻底的方法。 通过
经过上面的修改,我们再观察
[root@localhost bin]# dd if=/dev/random of=random.dat count=40960
记录了0+40960 的读入
记录了6004+1 的写出
3074362字节(3.1 MB)已复制,5.01017 秒,614 kB/秒
5秒产生了40960个随机数,/proc/sys/kernel/random/entropy_avail会有剧烈的变化,所有随机数产生之后它又会保持在3000左右。 选择哪种解决方法
个人建议选择第三种方式,熵池不仅仅Tomcat用,Linux下的所有应用程序产生随机数都会用到这个,所以不仅仅是Tomcat可能被 阻塞 。如果你搜索会发现Apache、Nginx、OpenSSL都被这个问题 坑过 。如果我们通过修改Java的配置来解决这个问题其实只是解决Java应用程序的问题,只能是治标不治本。根治的方法应该是通过 总结
经验不是经历。用别人的经验解决一个问题不难,难的是自己从头走一遍这条路,更加难的是推翻前人的经验对一个问题能够有自己的看法和领悟。 这个案例加深了我对 如何重现故障可以很容易的重现文章中描述的故障
|