1.端口号被占用(java.net.BindException)
不论是Flink,还是Kafka,Zk,hadoop之类的,正常启动,jps进程却未显示错误,先查看启动日志。例如:
直接查看某个端口号被哪个进程占用,注意一定要加sudo,不然只能查看当前用户下该端口号被占用的进程。
sudo netstat -nap | grep 端口号
之后会显示占用该端口号的进程pid,java左边的即为占用该端口号的进程pid。
tcp 0 0 172.20.104.219:9001 0.0.0.0:* LISTEN 8490/java
然后杀掉该进程。
sudo kill -9 8490
此时即可正常启动。
2.Hibench框架测量的延迟吞吐所有结果均为0
当收集到的每个分区都是0条结果的时候,生成的数据csv表格数据出了时间以外全为0,第一时间应该想到的是kafka的问题。
先用jps查看集群中所有节点的kafka进程是否都存活(注意:一半以上的kafka节点都存活时候,整个kafka集群才能正常工作,这也就是为什么kafka集群的节点数目一般布置为单数个的原因。)
如果kafka集群正常工作,可以查看kafka日志(建议kafka后台启动),看看也没有错误或者异常。
如果也没有,可能是设置了定期或者定时删除kafka日志,此时有可能导致刚刚kafka产生的数据流,立即被删除掉。该配置项在kafka的config/server.properties目录下,如图所示:
将光标所在的那一行注释掉即可。
Kafka有两种日志清理策略,定期删除或者日志达到一定数量后删除,这两个条件哪一个先满足,都会进行日志的清理。
如果不是kafka的问题,那就是测量的流式框架的问题了,这里我测的Flink benchmark,由于更改了Flink-conf.yaml导致收集到的吞吐和延迟均为0,所以使用默认的flink-conf.yaml即可,重启Flink即可。
Hibench测量数据全为0,可能是flink没有成功提交job,也就是Hibench 运行流式程序的第三步:
bin/workloads/streaming/identity/flink/run.sh
这一部分报错的话不会立即报错,因为hadoop里的yarn-site.xml设置有最大提交次数,所有需要等待一段时间才会出现出错的日志。查看flink的master的启动日志,可以看到出错的原因。
- 常见的错误有:分配的slots不足。此时需要增加flink-conf.yaml里的taskmanager.numberOfTaskSlots或者减少并行度。
- 还有一种错误,就是Flink的TaskManager没有正常启动,此时查看flink的slave的启动日志,注意slave日志数字下标最大的为最新产生的那个日志,查看slave的日志或者master的日志即能解决问题。
重启Flink即可解决错误。
重新运行Hibench上的应用程序,即能正常收集p99 latency或者throughput了。
3.Hadoop集群无缘无故多了一个NodeManager
在hadoop上运行jar包时候会一直卡个running job xxxxxxxxx那一步。
然后检查hadoop的启动日志,发现yarn-resourcemanager中有报未知的主机名字异常(Unknown hostname exception)。
此时执行
yarn node -list
发现多了一个nodemanager,但是slaves文件中却没有该主机名字,这是为什么呢?看了这篇博主的文章,恍然大悟。
创建include和exclude文件,更改yarn-site.xml和hdfs-site.xml,然后这样添加的新节点安全性就比较高了。
4.Kafka自动宕机
- 同一集群不同kafka节点的broker.id必须不同,否则启动时候就必定会宕机。
- 使用守护进程的方式启动(好多博客这样说,但感觉没什么用)。
- 更换kafka的版本(如果好多方法试过之后仍然宕机,建议你换一个版本,比如kafka_2.11-2.3.
5.Hadoop启动时候需要输入密码
没有配置ssh免密登录,需要注意的是,本机ssh本机也是需要配置免密登录的(感觉这个操作真的蠢)。
本机与本机的免密登录,与其余ssh免密登录几乎没有什么不同,唯一需要注意的是,将自己的公钥(id_rsa.pub),追加到自己的需要授权的文件下(authorized_keys)。即可完成本机与本机的免密登录。
这几个文件都在~/.ssh目录下,其中.ssh为隐藏目录。