dev用不了_什么？过了个周末应用就突然提供不了服务了？

什么？过了个周末应用就突然提供不了服务了？

Bug现场

这年头，诡异的问题层出不穷。这不，今天就出现了个坑爹问题。某个系统A,上周五还能提供服务，过了个周末，莫名其妙就GG了。

what?系统过了个周末过傻了？

先重启

于是立马重启，看看是否能够解决，毕竟是线下测试环境么(-_-!)。这一启动，就起不来了。。。

怎么办，要联调啊。一大堆人等着呢！于是问题就到了笔者这里。

有错误日志

这问题有错误日志输出啊，看上去看是挺好办的，连接数据库失败！

2020-09-27 16:34:39.227 init datasource error
java.sql.SQLRecoverableException: IO Error: Socket read timed out
 at oracle.jdbc.driver.T4CConnection.logon
 ......
 at com.alibaba.druid.filter.FilterChainImpl.connection_connect
 ......
Caused by: oracle.net.ns.NetException: Socket read timed out
 ......
 at oracle.jdbc.driver.T4CConnection.logon

这道题我会，不就是数据库连接异常么！肯定是配置配错了。查了一圈，反复校验配置，发现没有配错，最关键的是DBA自己用工具是能连上的。靠，神马情况? 看看连接的情况

netstat -anp | grep 1521

发现有大量连接处于TIME_WAIT状态，这个明显是超时然后客户端关闭了。现在就是DBA自己能够连接上去，应用确连接不上去了！笔者以前踩过这个坑，立马就反应过来，嘿嘿，是不是随机熵呀！

随机熵导致Oracle连接失败

之前踩过这个坑，Oracle JDBC在建立连接的时候需要随机熵，不然会导致连接失败。于是笔者立马cat了下linux熵池，发现果然没了！

// cat了下，只有这么一点
cat /dev/null
dad892queashca     
// 正常情况下，应该满屏幕都是

随机熵这个东西是Linux根据键盘数据/磁盘动作等将值加入随机熵池，如果很长时间没有做过操作或者没有请求，再有人消耗随机熵很容易导致熵池归0，进而连接Oracle失败！

这个也是有解决方案的，在JVM里面加上一个参数即可,即采用伪随机熵:

// 采用伪随机熵
-Djava.security.egd=file:///dev/urandom

就感觉是这个问题了，加上这个参数后，应该就轻松愉快了，重启！

竟然没有起起来，还是数据库连接问题

what?今天脸打的有点多啊,难道不是随机熵？这个表现一模一样啊。这时候DBA突然反映，他自己都用不了工具连数据库了，看了下监控，发现连接数被打爆了，处理新建的listen进程完全没响应！怎么回事？我突然想到，这台没有加urandom参数，其它也可能没有加urandom参数。其它的应用也卡在新建连接上，最后把数据库的整体连接打爆！(因为很多应用的超时时间设置的特别长！) 于是找DBA拉出来所有连接次数据库的ip!梳理了一下，发现有一大堆都没有加这个参数。而只要有一两台反复重连，那么数据库就会耗尽所有的资源！

只能放大招了

找出所有没有加伪随机熵的应用，全部kill掉，然后一台一台在JVM参数上加上伪随机熵。然后一台一台重启，这才解决了这个问题。

为什么线上没有问题

之前线上也出现过这个问题，在预上线环境出现。随机熵是由于键盘输入或者磁盘操作等随机熵源产生的，只要一直有请求，那么这个熵源应该不会被耗尽。但是预上线和测试环境就很容易出现这样的问题！

总结

Oracle连接需要使用随机熵这个坑确实坑到了不少人。笔者把这个分享出来，希望读者能够提前规避掉这个坑。值得注意的是,MySQL连接不需要用到随机熵^_^

学MySQL,还是要看<>