MongoDB 性能问题 - MongoDB 磁盘 IO 高问题
概述
阿里云数据库MongoDB的IOPS使用率是一个非常重要的监控指标,IOPS使用率达到或接近100%后容易引起业务响应缓慢,甚至导致业务不可用的情形。一般云数据库厂商为了避免宿主机出现IO争抢,会使用Cgroup等技术进行实例间的IO隔离和IOPS限制,即不同规格的实例配置对应不同的IOPS使用上限。
本文将由浅入深帮您查看、分析和优化云数据库MongoDB的IOPS使用率。
1 查看IOPS使用
1.1 监控图查看
首先需要确认该实例的最大IOPS上限,通过点击"基本信息"可以查看,如下图:
不同实例规格对应的IOPS使用上限参考:
https://help.aliyun.com/document_detail/57141.html
通过点击"监控信息"可以查看到当前的IOPS使用量,因为绝大部分情况下阿里云数据库MongoDB的data目录和log目录使用同一块盘,所以IOPS使用量=data_iops=log_iops。
1.2 命令行查看
在监控图展示上,目前阿里云MongoDB仅限制IOPS,也仅展示IOPS的相关信息。在实际的IO问题中,我们同样可能需要关注IO吞吐量,IO延迟情况,通过db.serverStatus().systemInfo命令可以查看IO相关的其他指标监控,不过所有监控项都是自MongoDB启动以来的累加值,并不建议直接查看。
如果用户有自行开发更为详细的MongoDB性能指标,可以基于上述命令的累加数值获取更多的MongoDB IO指标。
2 MongoDB 磁盘IO问题常见原因和优化策略
对于云数据库MongoDB来说,底层的磁盘硬件性能对用户透明,完全交由云厂商负责,用户只需要核心关注业务的正确使用MongoDB,以及配置合适的内存和IOPS上限。
通常来说,MongoDB的IO问题与内存的CacheSize大小息息相关。CacheSize越大,表示能够缓存的热数据越大,那么系统需要的磁盘IO量也就越低,出现IO瓶颈的概率越低;反之,CacheSize越小,表示能否缓存的热数据越少,系统刷脏也更频繁,实例出现IO压力的概率也就越大。
您可以通过mongostat或者阿里云数据库自治服务DAS实时查看当前的cache dirty,目前阿里云数据库MongoDB暂不支持cache dirty历史情况查看。如果出现 dirty>20%,并一直持续,说明内存淘汰压力很大,用户的请求线程会阻塞参与page淘汰,请求延时就会增加,这时可以考虑"扩大内存"或者"扩大IOPS"。
更多mongostat的使用方式可以参考:
https://docs.mongodb.com/v4.2/reference/program/mongostat/
还有一些与磁盘IO相关的参数和配置,比如MongoDB Journal和运行日志刷盘,WriteConcern设置,分片集群的MoveChunk等,这些因素我们建议用户根据实际业务需求情况设置即可,一般来说,不必为了尽可能地提高IO能力刻意修改。
关于更多Journal内容可参考:
https://docs.mongodb.com/manual/core/journaling/
关于更多WriteConcern内容可参考:
https://docs.mongodb.com/manual/reference/write-concern/
对于阿里云MongoDB来说,我们更推荐配置好合适的实例规格的同时,重点关注Index的优化和部分应用系统的写入优化。
3 如何配置合适的实例规格
一般很难事先预估热数据与CacheSize的比例设置为多少最合适,这是性能与实例费用的一个折衷。通用经验下,我们建议在MongoDB实例在日常态运行过程中满足业务RT要求的情况下,保证每日的峰值CPU使用率和IOPS使用率控制在50%以内。
4 Index优化
SQL全表扫描或者使用了不恰当的Index,比如导出全表数据期间,消耗的IO必然很大。另一方面,过多累赘的Index创建也会产生更多的数据规模,导致WiredTiger Cache只能缓存更小的热数据,业务数据写操作过程中也同样多一次IO操作去更新Index,从而影响IO性能。
所以在避免滥用Index的情况下,需要为每个Query创建最合适的Index,关于这部分内容,可以参考:https://docs.mongodb.com/manual/indexes/
5 业务架构和运维优化
在业务架构层面,要避免磁盘IO成为瓶颈,主要从以下几个方面入手:
5.1 控制并发写入/读取线程数
MongoDB是多线程应用,但是我们并不推荐"极致压榨"MongoDB实例本身的性能,过高的并发写入速度和复杂查询并发数,容易引起IOPS瓶颈,甚至导致Secondary节点持续延迟。具体的MongoDB IO压力可以参考上文提到的mongostat中的dirty数值。
如果业务写入量就是大到超出单机瓶颈,建议升级至MongoDB分片集群模式,通过数据的水平拆分来线性扩容MongoDB的写入性能。
5.2 尽可能避免峰值写入
部分业务,比如日志系统的定期写入或者游戏系统中用户信息的批量持久化,容易造成一个一个IOPS峰值。针对这种情况,在当前的实例配置不足以支撑如此峰值写入的情况下,我们建议业务侧改造为平滑写入,比如给每一个批量写入操作添加一个随机时间片。
5.3 避免业务高峰期间做运维操作
一些对性能影响较大的运维操作本质上也是认为造成了IOPS峰值,在无法避免的情况下,应该尽可能避免在业务高峰期执行。常见的容易引起IO高峰的运维操作有批量写入/更新/删除数据,添加Index,对集合执行Compact操作,批量导出数据等。
以上内容来自于《云数据库运维实战手册》电子书,可点击https://developer.aliyun.com/topic/download?id=8198下载完整版,助力云运维能力更上一层楼!
推荐阅读
-
MongoDB 性能问题 - MongoDB 磁盘 IO 高问题
-
【Netty】「萌新入门」(七)ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的,这意味着它们可以快速地被分配和释放,但是也会产生一些开销。 直接内存需要手动分配和释放,因为它由操作系统管理,这使得分配和释放的速度更快,但是也需要更多的系统资源。 另外,直接内存可以映射到本地文件中,这对于需要频繁读写文件的应用程序非常有用。 此外,直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时,数据必须先从文件或网络中读取到堆内存中,然后再从堆内存中复制到直接缓冲区中,最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时,数据可以直接从文件或网络中读取到直接缓冲区中,并且可以直接从直接缓冲区中发送到网络中,避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf: ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf: ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意: 直接内存是一种特殊的内存分配方式,可以通过在堆外申请内存来避免 JVM 堆内存的限制,从而提高读写性能和降低 GC 压力。但是,直接内存的创建和销毁代价昂贵,因此需要慎重使用。 此外,由于直接内存不受 JVM 垃圾回收的管理,我们需要主动释放这部分内存,否则会造成内存泄漏。通常情况下,可以使用 ByteBuffer.clear 方法来释放直接内存中的数据,或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码: public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果: class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中,池化技术指的是通过对象池来重用已经创建的对象,从而避免了频繁地创建和销毁对象,这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options,来决定池化功能是否开启: -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后,非 Android 平台默认启用池化实现,Android 平台启用非池化实现; 这里我们使用非池化功能进行测试,依旧使用的是上面的测试代码 testCreateByteBuf,运行结果如下所示: class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到,ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf; 在没有池化的情况下,每次使用都需要创建新的 ByteBuf 实例,这个操作会涉及到内存的分配和初始化,如果是直接内存则代价更为昂贵,而且频繁的内存分配也可能导致内存碎片问题,增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销,并且重用池中的 ByteBuf 实例,减少了内存占用和内存碎片问题。另外,池化技术还可以采用类似 jemalloc 的内存分配算法,进一步提升分配效率。 在高并发环境下,池化技术的优点更加明显,因为内存的分配和释放都是比较耗时的操作,频繁的内存分配和释放会导致系统性能下降,甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中,从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时,需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现,包括堆内存(JVM 内存)实现 UnpooledHeapByteBuf 和堆外内存(直接内存)实现 UnpooledDirectByteBuf,以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf:通过 Java 的垃圾回收机制来自动回收内存; UnpooledDirectByteBuf:由于 JVM 的垃圾回收机制无法管理这些内存,因此需要手动调用 release 方法来释放内存; PooledByteBuf:使用了池化机制,需要更复杂的规则来回收内存; 由于池化技术的特殊性质,释放 PooledByteBuf 对象所使用的内存并不是立即被回收的,而是被放入一个内存池中,待下次分配内存时再次使用。因此,释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存,我们需要根据实际情况来设置池化技术的相关参数,以便及时回收内存; Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收,在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解; 每个 ByteBuf 对象被创建时,都会初始化为1,表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中,如果当前 handler 已经使用完该对象,需要通过调用 release 方法将计数减1,当计数为0时,底层内存会被回收,该对象也就被销毁了。此时即使 ByteBuf 对象还在,其各个方法均无法正常使用。 但是,如果当前 handler 还需要继续使用该对象,可以通过调用 retain 方法将计数加1,这样即使其他 handler 已经调用了 release 方法,该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说,应该尽可能地保证 retain 和 release 方法成对出现,以确保计数正确。