zoukankan      html  css  js  c++  java
  • namenode 问题小记

    问题1:namenode进程故障

    Namenode挂掉,Namenode gc日志里面YGC报错promotion failed

    现象描述

    NameNode进程挂掉,Namenode gc日志里面YGC报错promotion failed。

    可能原因

    Young gc的时候,需要复制eden区和from区内的对象到to区,如果此时to区满了,就会使用悲观策略复制到old区,而此时old区也满了,就会报promotion failed。

    定位思路

    1. GC参数设置不合理
    2. 进程内存分配过少

    处理方式

    方式1:
    1. 对于第三方管理的JVM,调低-XX:XXInitiatingOccupancyFraction值,降低触发NN XX GC的百分比,保证old区有足够内存。
    方式2:

    1.扩大NN内存。

    问题2:NameNode内存FULL GC问题处理

    生产集群namenode Full GC 告警频繁

    问题描述:

    将standby namenode(nn1)的内存扩至80GB后,切换namenode,standby namenode在转换为active状态时进程死掉,查看namenode和zkfc日志发现:

    standby namenode由standby转换为active时,出现socket timeout,导致namenode状态转为SERVICE_NOT_RESPONDING,切换失败。

    原因

    bdp生产集群文件数量达到1.9亿,namenode当前内存64G,已使用约57G,内存不足,GC严重

    处理

    主机内存共128G,当前namenode内存为64GB,除namenode,resourcemanager,ZK,journalnode,ZKFC等进程已分配的内存外,剩余总内存约40G。

    1. 修改namenode JVM内存参数,将内存由64GB改为90GB,并分发;
    2. 检查当前active namenode为nn2;
    3. 重启standby namenode (nn1),确定已修改的参数已生效;
    4. 通过命令“hdfs haadmin -failover nn2 nn1”将active namenode切换至nn1;
    5. 待nn1为active,确定日志正常,且正常提供服务后,重启nn2 namenode
    6. 确定nn2 UI页面及日志正常,及已修改的参数已生效。

    可选优化方向

    1. 文件数量达到1.9亿,导致namenode元数据量过大,可合并小文件以减少namenode内存使用,避免Full GC。
    2. 在core-site.xml文件中修改ha.health-monitor.rpc-timeout.ms参数值,来扩大zkfc监控检查超时时间。
  • 相关阅读:
    ajax
    vue 思維導圖
    python项目_log日志的使用
    mysql数据库_serialisers
    常见的时间复杂度及其增长速度比较
    C++中的sort()函数
    用C++实现输入三个整数,中间用逗号隔开
    python——递归函数
    python——函数
    python——可变对象和不可变对象
  • 原文地址:https://www.cnblogs.com/qiaoyihang/p/9733215.html
Copyright © 2011-2022 走看看