个人经验~mongo故障处理思路

一 简介:mongodb 应该如何排查
二 分析角度
   linux 角度
   1 硬件是否有问题 常见主板 raid卡 和raid磁盘组
   2 综合指标 负载
   uptime : 1min 5min 15min
   平均负载的值，取决于系统上处于R状态（running加runnable）和D状态（不可中断睡眠，也就是等待io完成的进程）的个数之和在指定时间段内的平均值。
   分析角度 :负载分为两部分
       1 cpu密集型业务处理,表现形式top 下的cpu使用率 (单进程cpu使用率为使用逻辑核心数X100%)
       2 cpu io 等待,表现形式为top下的iowait较高或者iostat查看磁盘组的util值使用率经常100%
  综合指标 内存
    mongodb VIRT RES
    mongodb占用内存的方式和mysql不同,会几乎把所有内存进行cache缓存
   分析角度: 内存相关问题
    1 内存使用过度,直到占用swap内存,发生oom-killer,选择大容量内存(我碰到过的只有这个)
   综合指标 网卡流量
   网卡流量 一般为千兆网卡,流量报警
  分析角度:
  1 新增节点,进行全量同步,或者进行mongdump.当数据量大时会发生报警
   2 当并发太高,也可能导致发生报警
三 mongo角度
  1 事务语句
       1 短时间内的并发事务操作暴增(insert,update,delete语句)
       2 多库之间的事务操作互相影响
       3 大量db级别的锁等待情况
  2 查询语句
     1 短时间内的并发查询事务
     2 慢语句
     3 其他场景
 四 处理思路
    1 linux 监控收集
       负载 cpu 内存 流量 图进行收集
   2 mongo 监控收集
      connections DML语句波动
   3 实时查看
     1 通过监控和mongostat 收集哪种语句波动较大,定位删/改/插入 类型语句
     2 通过mongotop 收集哪个db读写耗时更高,定位具体业务
     3 通过观察shard.log观察慢语句,定位慢sql本身

     4 通过mongostat的faults次数定位是否内存本身存在瓶颈
五 优化
   硬件
     1 选用高内存dell机器
   mongo
     1 优化慢语句(80%场景是慢查询导致的问题)
     2 优化业务逻辑,减少mongo DML的次数
     3 优化业务逻辑,做读写分离策略
     4 优化业务逻辑,增加前端redis缓存
     5 冷热数据分离,减少大表数据量
     6 numtal=all方式启动mongo.不然有可能导致cpu暴涨的问题, 禁用zone_reclaim_mod 参数,在sysctl.conf中设置vm.zone_reclaim_mod=0即可 vm.zone_reclaim_mod=0 意味着可以从其他zone或NUMA节点回收内存
     7 多个业务集中在集群,采取拆分,减少并发
六 总结
   mongo场景发生的故障大部分表现在cpu和内存两方面,大量的操作语句极有可能造成cpu的暴涨

转载于:https://www.cnblogs.com/danhuangpai/p/10084318.html