当前位置:   article > 正文

MongoDB数据量大于2亿后遇到的问题 及原因分析_mongodb内存缓慢增长

mongodb内存缓慢增长

MongoDB数据量大于2亿后遇到的问题 及原因分析

一、数据增长情况

    每月增长量最大达到了1.9亿,每天增长约300W-500W
    (增长数据具体可看页尾)


二、遇到的情况及解决方法

    1.数据量过大,并且都集中在一个表,所以此表数据插入变慢。
        表索引越多越明显,

        优化处理方法:
            1.优化索引,以前的startTime日期字段索引,
            修改为客户端用日期生成ObjectId,再用_id 来进行查找。
            2.TraceId 字段(一个TraceId 对应多条记录)计划也删除,后面再用ES 系统先查询到_id 后,
            再从mongoDB 进行查找。

        原因分析:
            当表数据增长到千万级后,内存数据中的索引数据增加,内存越来越不够用,需要刷新脏数据增多,            
            mongostat 分析的 dirty % > 3,后从16G 内存升级到32G 内存后,情况稍有好转。


    2.数据量过大后,从节点时尔出现CPU load 负载过高,从节点尤其明显。
        
        在把表重命名,新数据插入到新表处理后:
        db.TraceLogs.renameCollection("TraceLogs_bak170210");
        (新数据插入时,会自动生成表TraceLogs)


        历史数据表统计信息    
            Log:PRIMARY> db.TraceLogs_bak170210.stats()
            {
                "ns" : "RavenLogs.TraceLogs_bak170210",
                "count" : 384453917,
                "size" : 865594958942,
                "avgObjSize" : 2251,
                "storageSize" : 444,613,255,168,
                .....
                "nindexes" : 2,
                "totalIndexSize" : 15275057152,
                "indexSizes" : {
                    "_id_" : 3,973,029,888,
                    "TraceId_1" : 11,302,027,264
                },
                "ok" : 1
            }
            从此统计信息中可以看到:
                    表存储大小:    444G,
                    索引 _id_ 3.9G, TraceId_1 大小:11G


        再次查看数据库性能

        从以前的:
        load average: > 5.47, 5.47, 5.47
        降到了:
        load average: 0.88, 1.34, 1.69
        (主从节点,皆已下降)

        在做历史数据迁移期间,又升到了> 8 并且时频繁出现。

        完成数据迁移后,回落到  2 < load avg <: 4 之间        (升级到MongoDB3.4 之后)
            

        原因分析:
            个人认为,主因还是因为内存不够。索引+热数据远远超过了16G的MongoDB使用内存。
            从而导致大量的IO,相对的CPU load 也上去了。
            在把原大表TraceLogs 改名后(TraceLogs_bak170210),大量的热块数据已被清除出内存,

    3.此前数据库从节点内存升级后(16G --> 32G),参数配置不当,节点实例当机情况:
        wiredTiger:
            engineConfig:
          cacheSizeGB: 28    (限制mongoDB 使用内存最大值)

        后调整为默认值
                #cacheSizeGB: 28    (限制mongoDB 使用内存最大值),默认值为50%
        mongoDB实例恢复正常,但CPU load 也一直居高不下。

        原因分析:
            系统使用内存太少,可能是磁盘缓存过低,而无法读写数据,但在mongoDB 日志中,
            无法找到原因。只是看到实例被关闭。

    4.因为oplog 同步表最大设置值(oplogSizeMB)为50G, 但50G 只能保存52h 的数量变化量。
    想添加新的从节点时,当同步完成数据后,已过了oplog 的窗口期.
        
    (oplogSizeMB的大小要大于数据同步完成+索引建立完成的时间段内生成的数据量,
    当同步完成后,从节点从主节点读oplog表的数据,发现最小的同步时间,已大于从节点中
    同步开始时的时间了,这就是窗口期已过期)


        数据量大后,重新创建索引的时间特别惊人,一个索引需要10多个小时。
        500G 存储量,总共需要3天左右的数据完成节点的数据同步及索引创建。

        后面计划在添加节点前,做以下调整:
        1.把数据库升级到3.4 版本,此版本在新节点数据同步,创建索引上,号称已有很大的改善。
        2.删除能够优化的索引,如果索引无法优化,也可以考虑先把某个索引删除,节点完成后,再重新建立


经验总结:

    1.索引的优化,尽可能的发挥主键索引的功能,比如上面说到的,使用日期范围自己生成_id 范围,用_id字段进行查询,
    能不建立索引,就不建立。在大增长的表中,极其重要。

    2.数据库服务器的内存配置上,内存>索引大小,或者是配置到 内存>=索引大小+热数据大小 还是有必要的。
    
    3.数据库服务器的磁盘配置上,如果是云服务器,尽量采用高效云盘。使用EXT4,或者使用NFS 格式也是有必要的。

    4.如果一个库有多个表的数据达到亿级时,可能也是考虑使用分片集群的时候,特别是如果此表是做为主业务
    数据库的情况。


---------- 表数据增长情况 ------------------
......
1/1/2017,4318897 
1/2/2017,3619411 
1/3/2017,2583555 
1/5/2017,5523416 
1/6/2017,3052537 
1/7/2017,3482728 
1/8/2017,3931742 
1/9/2017,4732320 
1/10/2017,4651948 
1/11/2017,4438733 
1/12/2017,4286169 
1/13/2017,4405242 
1/14/2017,5664654 
1/15/2017,5623800 
1/16/2017,3638656 
1/17/2017,3617628 
1/18/2017,3601569 
1/19/2017,3738790 
1/20/2017,3788641 
1/21/2017,4603575 
1/22/2017,4466660 
1/23/2017,3913910 
1/24/2017,3749316 
1/25/2017,3969802 
1/26/2017,4101293 
1/27/2017,2581358 
1/28/2017,3160561 
1/29/2017,3051008 
1/30/2017,3332417 
1/31/2017,3476649 
2/1/2017,    3152283 
2/2/2017,    3394489 
2/3/2017,    3524487 
2/4/2017,    3511386 
2/5/2017,    3870305 
2/6/2017,    3056966 
2/7/2017,    3022927 
2/8/2017,    3484463 
2/9/2017,    4033520 

--------------------------
 2016/12:    191914076
 2017/01:    119106985
 2017/02:    31050826
--------------------- 
作者:边城cn 
来源:CSDN 
原文:https://blog.csdn.net/miyatang/article/details/55509419 
版权声明:本文为博主原创文章,转载请附上博文链接!

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/正经夜光杯/article/detail/734344
推荐阅读
相关标签
  

闽ICP备14008679号