2016年3月21日，凌晨2点多开始QQ邮箱收到几十封测试报警邮件，是在应该内自己通过切面做的关于Cassandra操作出现问题的报警。内容如下：
打开了手机客户端，试了下发现，没问题。而Cassandra最容易出问题的地方是网络，看了下，测试的两个服务有一台在同一个物理机房，一台不在，所以怀疑是网络连接导致的某种阻塞，然后导致内存溢出。（PS:这是一个合乎逻辑但错误的判断，当时并没有去验证这种假设是否成立。验证方式很简单，看看两台机器是否都存在对应的异常。）
当时联系了早晨即将到公司的小A，并且说：Cassandra可能出问题了。（看着黑乎乎的邮件标题，第一反应是这个。） 小A查看了Cassandra的日志和内存之后发现，并没有内存不足的情况。分配给jvm的内存还有一大半没有使用。
10点钟我到公司后，分析报的错全是java heap space.从新整理了思路，查看了不同keyspace的节点状态，没有任何异常，看完之后发现，正式环境一点错没有，那么测试环境出问题，更是由于测试环境的网络什么的导致的了，在这里又想当然了。
之后，客户端开发人员陆续反应，测试环境出问题了，（庆幸一下，问题是自己先发现的），于是，11点左右，重启了对应的模块。
Everything is 看起来 ok!
中午吃过饭后，下午2点做一个技术分享。。正在听，突然就被小B拦住了，说服务怎么Blabla...,我一看，日志这次没有javaheapspace，却在报：
NoHostAvailableException，这必然是网络问题了啊，花了一个多小时，查看各种资料：
最后觉得这个上面说的比较靠谱，
http://www.datastax.com/dev/blog/cassandra-error-handling-done-right。
于是乎，重启服务，发现Everything is 再一次看起来OK!
之后，做了些别的业务，直到晚上吃饭的时候，服务再次无法用。。内心深处当时的感慨依然是网络不至于这么差劲吧，之前怎么没有类似的情况。
饭后，回来看，发现两台对应服务的机器处于不同的机房，但是那台处于同一个物理机房的机器也在报NoHostAvailableException...
于是这个时候查看了对应进程的情况，发现CPU失踪处于100%，虽然有16核，于是查看了对应的线程日志以及java heap的使用情况。。发现某个对象在heap中占用量极其大，new generation始终是满的。分配的空间完全不够用。
查看了这个对象的逻辑，以及对应的数据，发现，这个逻辑竟然在不停的取200万的数据在处理，而且是个Cron job，每小时一次。。（小A干的！）
核对数据库的数据返现，这些测试数据的时间的确有问题，很大部分的竟然集中在了这一天。。。对应的语句中两个万恶的时间戳：
select * from table where status=1 and expire>=1426867200000 and expire<
1426953600000
回过头来看，如果早晨能冷静思考，是可以定位到具体问题所在的。
后记：从cpu到线程，到heap 的一个分析思路和方法。
1.查看进程CPU的状态。Top
2.如果CPU的状态异常，需要定位到线程的CPU状态。top -h
3.找到对应的线程，记下线程ID。
4. 得到线程ID的hex值，用于下一步查看线程的情况。 可用python 获取hex值。
5. 通过jstack查看对应的情况。并找到对应线程在干嘛。
6.通过jmap -histo查看对应进程的使用情况。
7.分析jmap日志，得到对应的结果。
eg:
582
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
