Java两则故障分析和常见连接超时时间

原创
2013/03/29 17:34
阅读数 212

郑昀 汇总 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 事务遇到一个行锁,等待的超时时间,默认值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 工具分析,找到对应的对象或直接找到类。
 
语录分享:
语录:
『主 动沟通,要求反馈:当你接到一个新的、没有经验的任务时,首先要确认目标、时间点等具体要求(what,why,when);在有了做事的思路和框架时和 老板沟通,获取反馈(how);在初稿完成后再次沟通获取反馈;最后才是最终成果。切忌自己闷头做到最后的时间点,此时如果结果不符合预期会很被动。』 ——Qiaoxin
 
语录:
『上周和兄弟们饭后百步走,随口一句:组织是什么?组织就是屁股。组织架构就是摆屁股,架构调整就是调整屁股。因屁股造成事情办不妥,推进不了。就该时候动手了。』——carnec
 
语录:
『早期项目一看团队,二看方向,但都需要打得赢。团队希望是一起打过仗的,立过战功的,有基本的默契,这样的团队继续赢的概率更大。方向打得赢则是指所在方向有大概率打得赢,至少能先站住,后站高。』——林军
 
语录:
『我 选领导团队的四个原则:一是必须有理想有事业心有共同的价值观;二是个人能力一定要互补,不能都找能力和你相似的人,个人可以有不足,团队不能有短板;三 是每个人要有独立作战独挡一面独立发展的能力,有这样的团队公司才能有发展空间;四是我管的团队不能太多人,喝酒时一桌一定要都坐得下。 』——孙宏斌
 
语录:
『曾在一处见到,淘宝在长期使用java构建web项目后,得出一个结论:积重难返。
实 际工作经验得到的结论,积重难返的原因,往往不是java本身的缘故,而是团队成员基础积累参差不齐,许多次的“一不小心”积累成了最终的结果。到了悔之 晚矣的时候自然就积重难返了。如何避免java使用自伤,最关键在于,统一团队成员的code入口,框下可能发生的事情,避开不能发生的事情』—— 54chen
 
语录:
『有人说「台风来的时候,猪都能飞起来」,公司快速成长期,每个人好像都能力都倍增,其实没有,大形势好,滥竽充数也能像个高手,所以这时候千万别忽视个人学习,否则大潮退去,越在浪头上越死在沙滩上。』——Fenng
 
语 录『几乎每个工程师都能挑出discuz的若干不足和问题,有时候我就会从中选择一些面试题,比如discuz在ip地区识别中的一些算法函数,一些复合 索引和冗余字段的设计思路,乃至用户密码随机salt的原理,一深究下去,发现应聘者基本上都回答不出来。』——caoz
 
语录:
『【CEO必鉴:烂苹果定律】在任何组织里,都存在几个难管理的人物,他们像苹果箱里的烂苹果,如果你不及时处理,它会迅速传染,把果箱里其他苹果也弄烂。一个不干工作,喜欢搬弄是非的人足以很快将一个高效的部门变成一盘散沙。“烂苹果”要果断清除!』——正和岛标准
 
语录:
『担当、责任意识和自动补位是创业团队早期必要的。而不是经常说这不是我的事、我不是管事的、需要找xxx……从0-1,从1-10,只有敢于要,敢于担当的人最后才能成为获得成就、地位、认可的人』——文昭武穆
 
语录:
『你 遇到过很多聪明人,你的大学同学,你的同事,你的朋友,有几个比你傻?很多年以后,你会看到成功的并不是最聪明的人。因为决定成功的更多是非智力因素:明 确的目标,积极的心态,努力和坚持,承受挫折和压力的能力,成熟的接人待物等等。有一种人注定没戏:不努力和怨天尤人。』——孙宏斌
 
语录:
『我以为,工资的定价依据,不是自己在其他地方能拿多少,而是公司花多少钱可以招到替代自己的人。』 ——邓熔
 
语录:
@孙陶然:#昆仑的仑# 一把手要对进度敏感,盯住KPI,把精力放在解决那些未达成KPI的部门上。解决问题时先看人再看事儿,人对了事儿才可能对,人不对事儿不可能对。
 
语录:
『越 是在最紧要的时刻,越是考验团队:哪些人可以拉得出、扛得上;哪些人怯阵、退缩;哪些人是真正的顶梁柱,哪些人是打酱油的。请每一位想在职场上不断取得更 好发展的人都要格外珍惜这样的机会,充分施展自己的才能,在关键时刻发挥关键作用,这种机会不是想有就有,甚至可能不是由团队左右,切忌掉队。
——sodme』
 
语录:
@ 许晓辉 :在创业公司,不会主动找事做的人,不是原地踏步,就是会被淘汰。主动找事首先是基于本职岗位的创新和实践(这一点大多数人做不到),其次是对自己所处工 作链条的完善(不必顾虑是否跨界),最后是对公司各环节的观察、思考与建议(做到这一层离晋级就不远了)。第一点最重要,有了根据地才好扩张疆域。
 
语录:
『@许晓辉:
曾 经不理解老板变化无常,定下来的事怎么说变就变;等你自己做老板会发现:局势总在变化,必须随时做出调整,以应对来袭的风浪,确保航行安全。若你在创业公 司,更要深刻理解这一点,理解变化背后的缘由。自此,我也深刻领会了马云的话:“真正的高手还在于制造变化,在变化来临之前变化自己。”
 
语录:
@许晓辉 :对于跳槽频繁者(在一家公司时间低于一年)一定要谨慎,此类人大部分不是能力就是态度有问题。你不能指望自己有点石成金的魔法,也不能指望一个缺乏耐力的人能在你公司变得坚韧不拔,他可能只是以跳槽逃避困难与压力。
展开阅读全文
打赏
0
7 收藏
分享
加载中
更多评论
打赏
0 评论
7 收藏
0
分享
返回顶部
顶部