常见现象的故障分析
2016-03-25 23:29
363 查看
现象倒推一: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 事务遇到一个行锁,等待的超时时间,默认值50秒,届时会打印“Lock wait timeout exceeded; try restarting transaction”错误;
mongodb
Java下,
MongoOptions.maxWaitTime:连接上阻塞线程的最大等待时间,默认值120秒。
MongoOptions.connectTimeout:建立新连接超时时间, (注意Only used for new connections) 默认无限制。
MongoOptions.socketTimeout:socket通讯超时时间,默认无限制。
现象倒推二:Java应用频繁 fullgc
频繁 fullgc 大致有几种原因:
第一种,还是由于某一个资源成为瓶颈,导致大量线程进入 blocked 状态,新的 Requests 源源不断进入,不断开启新线程。加之线程在内存中做了很多运算,且这些内存无法收回,导致 old generation(旧生代内存区)占用比例超过阈值(此阈值由 JVM 参数 CMSInitiatingOccupancyFraction设定,默认值是90%),进一步导致新对象分配没有更多的空间,从而频繁触发 fullgc。
举例,由于某段代码没有释放数据库连接——>连接池中的连接耗尽——>部分线程无限 TIMED_WAITING ——>其余线程都 Blocked——>开启新线程——>频繁引发GC——>占用大量CPU——>应用挂起。
第二种,产生了大量大内存对象,占用了大量堆空间,引发 fullgc 。
可以将当时的 memory dump 文件经由 MAT 工具分析,找到对应的对象或直接找到类。
最大的可能是,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 事务遇到一个行锁,等待的超时时间,默认值50秒,届时会打印“Lock wait timeout exceeded; try restarting transaction”错误;
mongodb
Java下,
MongoOptions.maxWaitTime:连接上阻塞线程的最大等待时间,默认值120秒。
MongoOptions.connectTimeout:建立新连接超时时间, (注意Only used for new connections) 默认无限制。
MongoOptions.socketTimeout:socket通讯超时时间,默认无限制。
现象倒推二:Java应用频繁 fullgc
频繁 fullgc 大致有几种原因:
第一种,还是由于某一个资源成为瓶颈,导致大量线程进入 blocked 状态,新的 Requests 源源不断进入,不断开启新线程。加之线程在内存中做了很多运算,且这些内存无法收回,导致 old generation(旧生代内存区)占用比例超过阈值(此阈值由 JVM 参数 CMSInitiatingOccupancyFraction设定,默认值是90%),进一步导致新对象分配没有更多的空间,从而频繁触发 fullgc。
举例,由于某段代码没有释放数据库连接——>连接池中的连接耗尽——>部分线程无限 TIMED_WAITING ——>其余线程都 Blocked——>开启新线程——>频繁引发GC——>占用大量CPU——>应用挂起。
第二种,产生了大量大内存对象,占用了大量堆空间,引发 fullgc 。
可以将当时的 memory dump 文件经由 MAT 工具分析,找到对应的对象或直接找到类。
相关文章推荐
- Markdown语法实践
- linux下mysql查询时中文乱码(终极解决办法)亲测!
- OkHttp3找不到FormEncodingBuilder
- Error: read ECONNRESET
- html标签
- bzoj 2049: [Sdoi2008]Cave 洞穴勘测
- 多线程:全局队列
- Leetcode #23 Merge k Sorted Lists 合并K个有序列表 解题报告
- 第13课 接续符和转义符
- UI 开源代码 FileBrowserView
- 多线程:同步的作用
- 删除docker0网卡
- 网络编程常见问题总结
- execute、executeQuery和executeUpdate之间的区别
- MySql与SqlServer的一些常用用法的差别
- Oracle11g release2数据导出到Oracle10g release2方法
- 多线程:主队列
- 多线程:并发队列
- mvn profiles
- linux中断系统那些事之----中断处理过程【转】