高可用性测试比较简单,模拟单点故障或者网络故障来确认集群是否能够正常选举出新的主节点,并自动将应用切换到该节点上。压力测试的话可以使用压测工具,比如YCSB,或者使用基于cloud的测试方法。上线后运维阶段的数据库,性能诊断一般从 OS层 --> 数据库 --> 应用这样...
显示全部高可用性测试比较简单,模拟单点故障或者网络故障来确认集群是否能够正常选举出新的主节点,并自动将应用切换到该节点上。
压力测试的话可以使用压测工具,比如YCSB,或者使用基于cloud的测试方法。
上线后运维阶段的数据库,性能诊断一般从 OS层 --> 数据库 --> 应用这样逐级检查,再结合检查结果综合分析。
如果应用在开发阶段,则应该让DBA参与到模式设计,索引创建、架构规划的工作中;会大大减轻上线后的优化难度。
- OS层
- 内存大小:最好能把working set(热数据及索引)完整cache到内存中
- 磁盘IO:MongoDB的IO类型很少是sequentail,可以的话使用SSD,普通的SATA或者SAS磁盘创建RAID类型选择RAID10
- 参数设置(NUMA、 Huge page、ulimit、Readahead等等)
- 数据库
- 性能指标:各种opcounters类型统计、replication延迟、connection、cache等
- 日志:是否有报错
- 索引:无用索引,索引过度会导致插入修改性能下降;索引优化(sort、coverd query等)
- 慢查询:mtools&explain
- write concern & read concern参数
- 应用
- 模式设计
- 索引设计
- 分片(结合应用场景选择合适的片键)
- 聚合优化
- 语言驱动
收起