fullgc

郑昀 汇总 20130309 常见现象的故障分析： 现象倒推一：Java Web应用的连接数暴增 最大的可能是，Web应用的线程调用路径中阻塞在某个远端资源上。 线程向某个远端资源发起的请求被阻塞，可能是以下原因： 连接受阻，如等待client端连接池的空闲连接，如远端服务连接数满； 响应迟迟没有返回，如数据库中的记录被“表锁”或“行锁”，如数据库有大量慢查询； 常见的连接超时时间 为了让 大家 一看到线上日志某些刚刚好的时间就能反应过来，总结如下： memcache PHP下， Memcache::connect 函数传入的 timeout 参数代表连接超时时间，单位秒。 默认值1秒 ； 注：修改此值之前请三思，过长的连接超时时间可能会导致失去所有的缓存优势。 Java下， spymemcached 里，配置 opTimeout 代表操作超时时间， 默认值2.5秒 ； xmemcahced 里，opTimeout 的定义与spy 一样， 默认值1秒 ； mysql wait_timeout：服务器关闭非交互连接之前等待活动的秒数， 默认值28800秒 （即8小时）； connect_timeout：在获取链接时，等待握手的超时时间，只在登录时有效， 默认值10秒 ； innodb_lock_wait_timeout：一个 InnoDB 事务遇到一个行锁，等待的超时时间，

公众号HelloJava刊出一篇《 MySQL Statement cancellation timer 故障排查分享 》，作者的某服务的线上机器报 502（502是 nginx 做后端健康检查时不能连接到 server 时抛出的提示），他用 jstack -l 打印线程堆栈，发现了大量可疑的“ MySQL Statementcancellation timer ”，进一步探究原因，原来是业务应用将数据库更新操作和云存储传图操作放在同一个事务。当云存储发生异常时，由于缺少云存储操作的快速失败，并且缺少对整体事务的超时控制，导致整个应用被夯住，进而 502。 作者文中还谈及他排查过程中注意到 MySQL-Connector-Java 的一个 bug，在 5.1.27 版本以前 MySQL Statement cancellation timer 会导致 Perm 区 Leak，内存泄漏后进而业务应用异常。 我们恰巧遇到过这个坑。鉴于这个坑的排查过程和测试验证还挺有趣，我贴一下去年我们的 RCA 报告： RCA：JDBC驱动自身问题引发的FullGC 郑昀 基于田志全和端木洪涛的分析报告 2015/6/30 关键词： Java，JDBC，升级，MySQL驱动，频繁数据查询，mysql-5.1.34，mysql-5.0.7 问题现象： 2015年4月22日（周日）晚间，线上