最近国家打击网络“低俗”，其它同事都忙着让自己的业务“不低俗”，而我则因为业务不低俗相对轻松许多,就想早点下班回家，但是这时候那个万恶的短信声音又一次响起来了。唉，又是那个报警，这个报警从上午10点左右开始就一直持续不断，但主要又是一些非重要、调用量较少的接口，而且整个白天时有时无，就没太在意，但是到了用户高峰期的时候报警愈发频繁，于是我不得不打消回家的念头，搞定这个问题才行。

    我的这个业务的简单拓扑结构是"Client<->Server<->外部接口"，其中Client是一个WebServer[可以想象成Tomcat]，以UDP的方式与Server[独立Java应用程序]进行交互。业务的流程很简单，比如用户从Client发一个login请求给Server端，Server端会将该请求发送到外部接口进行验证，然后将结果缓存到本地，并返回一些信息给Client。这个业务已经平稳运行了很长时间，通常的报警都是由外部接口缓慢导致Client到Server、Server到外部接口的监控同时报警，但是这回不一样，报警的内容为client端到Server端的调用超时，超时率都是10%左右，耗时比平时多出几倍[由几十毫秒上升到200毫秒左右]。与此同时，Server端到外部接口的成功率和超时率都和平时没有什么区别。看来外部接口这次没问题，是业务内部的原因了。

    看了一下发布记录，今天没有任何到正式环境的更新，可以排除代码错误。是Client到Server所在的IDC之间的网络故障吗？问了下运维并没有相关的故障信息，同时ping了一下也是正常的。同时JMX监控也显示从上午10点到现在的WebServer线程数一直居高不下，具体一看都是在调UDP等Server端回复，看样子只能是Server应答不及时导致的问题。但是代码没更新过，而且是上午10点突然发生[并持续到现在]的问题，查看了一下Server端的UDP对列，发现从10点开始，每隔一分钟

，UDP对列都会变满，导致响应缓慢或丢包，我们的监控是10分钟一次，当然是10%的超时率了(-_-!)。随后仔细回想今天都干了些啥，想来想去就只有上午给Server端的服务器加了jmap监控用于查看JVM内存对象，每分钟统计一次写入到一个log中。看了一下日志，启动的时间点吻合，关闭该监控之后Client端调用逐步恢复正常。

    看来已经找到了真正的罪犯jmap，这个东西在获取jvm内存对象的时候会暂停掉进程的工作[为了统计对象数量，老/新/永久代内存的分布数量]从而导致Server端Java进程请求无法及时被处理，UDP对列溢出而导致丢包。之所以当初没发现是因为监控导致的问题是因为并不是这个监控上了之后立刻就导致报警，而是过了大约一个多小时之后中午用户流量小高潮的时候才开始逐步报得比较多，而在中午高峰过去之后又是时有时无，降低了我的警惕性。虽然是很幼稚的错误，因为粗心及对工具了解不够，但不够重视的话这两点也足以酿成大祸，自己引以为戒。

发表于 @ 2009年01月13日　21:15:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:浅析Context Class Loader | 新一篇:java的Mmap二三事