扫二维码与项目经理沟通
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
描述：
创新互联公司致力于互联网网站建设与网站营销，提供网站设计制作、做网站、网站开发、seo优化、网站排名、互联网营销、成都小程序开发、公众号商城、等建站开发，创新互联公司网站建设策划专家，为不同类型的客户提供良好的互联网应用定制解决方案，帮助客户在新的全球化互联网环境中保持优势。
If a large directory is deleted and namenode is immediately restarted, there are a lot of blocks that do not belong to any file. This results in a log:
2014-11-08 03:11:45,584 INFO BlockStateChange (BlockManager.java:proce***eport(1901)) - BLOCK* proce***eport: blk_1074250282_509532 on 172.31.44.17:1019 size 6 does not belong to any file.
This log is printed within FSNamsystem lock. This can cause namenode to take long time in coming out of safemode.
One solution is to downgrade the logging level.
解决方案
tail -f /var/log/hadoop/hdfs/hdfs-namenode.log
http://
Input "BlockStateChange" and Level is "WARN" and then click "Set Log Level" button
wait 2~3 mins. it works and performance is fine.
我们在微信上24小时期待你的声音
解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流
微信二维码
移动版官网