2016.06.24
昨天3台服务器中的1台,supervisor起不来,一直报FileNotFoundException,找不到“storm/data/supervisor/localstate/1466652445675”这个文件。
后来把storm/data/supervisor目录删除掉就好了。
这个估计是不正常关机造成的状态不一致造成的。具体原因不清楚。解决办法受这个帖子启发:
http://stackoverflow.com/questions/22318783/storm-supervisors-crashing-on-reboot
昨天还有一件事,
140、14服务器以前部署过统计集群,这次集群并没有包含201、14,但是14上的守护并没有删除,从log看14上的mongo一直尝试连接140,140确实在处理214的请求,但最终好象是因为opTime不同,并没有成功。此尝试一直在进行,干扰是肯定的。估计是replset名相同造成的。
从14上的log看,14上收到的hearbeat信息中id值不匹配。
昨天给email库的各个collection添加了索引。
增加索引是在库的初始化脚本中进行的,复制集初始化完成后即进行。虽然库、表都没有,表结构也没有,但不影响创建索引,这就是freeschema的魅力吧。
昨天实体机集群非正常关机,今天开机后,竟然奇迹般自动恢复了。
storm:
134 worker日志:
worker起的比较早,9:33以前一直在连接140的6700端口,应该是supervisor还没有起来。为什么连140的呢?
9:34, 报kafka连不上, node broker/id/0 doesn't exist.
一直报从kafka获取topic数据失败,fetch failed.
9:40分正常了,没有error了。
supervisor日志:
9:31报zookeeper连不上的错误,socket, connection refused, zookeeper timeout
9:33:08之后错误消失。
kafka日志:
9:33:07之前报zookeeper连不上错误。
9:39:46~9:39:49一直报NotLeaderForPartition, leader not local的错误, 告警。应该是重启之后做了balance。之后消失。
mongodb日志:
9:31~9:34replset之间的连接建立。到9:40,storm相关的连接建立。这与5分钟tick相关吗?
flume日志:
9:31报zookeeper连不上错误,6秒之后就不报了,这个这么快?
zookeeper日志:
9:33之后建立好集群。flume为什么那么快就连上了?
验证ui上kill topo,bolt的clear是否可以调用成功。答案yes
验证通过脚本停止topo,bolt的clear是否可以调用成功。答案yes
有待验证, rebalance时,bolt的clear是否可以调用成功
在初始化mongodb的时候,在一台服务器上,先初始化完rs,然后给某个库的某个collection添加索引(写在一个脚本里面)。
这个添加索引的操作,使用命令行时,必须在primary上进行。
按道理,进行rs初始化的服务器不一定是primary,所以,创建索引有可能会失败。但实际情况是,即使该服务器不是primary,创建索引也成功了。
应该是创建索引的命令,在rs选举primary之前完成的,貌似这时候可以做各种初始化工作而不要管服务器是否为primary。
2016.7.1
今天启动集群,发现一个机子的zookeeper起不来。
手动起一下,报“starting zookeeper ... already running as process 3797”。 ps -ef 里面又找不到该process 3797。ps -ef | grep zookeeper, 也找不到。
有点莫名其妙,zookeeper bug? 解决办法: kill -9 3797, 再启动就OK了。
2016.7.29
前天有个同事说一台storm服务器的oracle起不来了。说是内存不足。
看了下,16G内存还有9G free。
然后启动停止集群,deploy程序跑到这台服务器的时候,也报内存不足。
top查看了一下,nimbus、kafka、worker进程的cpu使用率都在100%以上。这时候集群啥事也没干。
停止topology,cpu使用率都下来了。看来kafka的cpu高利用率也跟topology有关系。
通过top -H -p 进程id 查看进程中哪个线程cpu占用率高
再用jstack查看调用栈
jstack -F pid > tmp1.log
grep -A 50 线程id tmp1.log
最终发现都是跟topology与kafka的通讯有关。
gg了一下:
http://www.cnblogs.com/lingfengblogs/p/5242288.html
http://stackoverflow.com/questions/20469734/cpu-usage-and-serialization-at-each-worker
http://www.cnblogs.com/jianyuan/p/4891450.html
问题出在storm的一个配置项上:
topology.sleep.spout.wait.strategy.time.ms
spout每次发送完消息,会更新emitted_count, 如果没有更新,则休眠“topology.sleep.spout.wait.strategy.time.ms”后,再次调用spout发送。
“topology.sleep.spout.wait.strategy.time.ms”缺省值是1毫秒。由于是空闲状态,所以并没有消息发送,所以每隔1ms,kafkaspout都会重新
连接kafka,获取消息。我们的topology里有141个spout,所以1毫秒内会有141个socket连接。大概是这么个意思。
把“topology.sleep.spout.wait.strategy.time.ms”调到1000毫米,cpu使用率绝大部分时间都降到5%以下了。
上述问题估计也造成内存碎片化很厉害,导致分不出1较大块完整的内存来,造成其它程序启动失败。
同时还修改了kafka的“heatbeat.interval.ms”, 新值10000,缺省值1000。但从测试的效果看,该值影响不大。
2017.4.19
预处理启动时,检测zookeeper总说zookeeper有可能他没起来,但进程在啊。
后来发现是防火墙没关
通过新安装的预处理平台调试storm程序,但是debug的时候一启动就报:
java.lang.RuntimeException: java.nio.channels.UnresolvedAddressException
......
搜了下,这篇文章解决问题:
http://www.cnblogs.com/zhwbqd/p/4045263.html
问题在于: storm kafkaSpout 通过ZK去获取kafka的地址, 但是zk中保存的kafka是以域名的方式保存的, 调试机没有配置这几台服务器的host。
2017.6.1
今天同事说有台机器的redis起不来了,打开日志看了一下,说
Wrong signature trying to load DB from file
Fatal error loading the DB: Invalid argument. Exiting
查了一下,应该是redis非正常关闭造成 rdb文件损坏引起的。 删掉rdb文件再启动就好了。
这个原因是现在的redis停止脚本用的kill -9杀进程,应该用
redis-cli -p 63xx shutdown