标签：监控 拆分 cpu 多个 导致 应该 got 均值 mod
一 简介: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 短时间内的并发事务操作暴增(比如压测,活动)
2 多库之间的事务操作互相影响
3 务语句形成的大量锁等待情况
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 多个 导致 应该 got 均值 mod
原文地址：https://www.cnblogs.com/danhuangpai/p/10084318.html
