mongodb 性能调优

mongodb与内存的关系   2011

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75

虚拟内存  Playing with Virtual Memory  这块完全没弄清楚   linux top命令VIRT,RES,SHR,DATA的含义 VIRT：virtual memory usage 虚拟内存 1 、进程“需要的”虚拟内存大小，包括进程使用的库、代码、数据等 2 、假如进程申请 100m 的内存，但实际只使用了 10m ，那么它会增长 100m ，而不是实际的使用量 RES：resident memory usage 常驻内存 1 、进程当前使用的内存大小，但不包括swap out 2 、包含其他进程的共享 3 、如果申请 100m 的内存，实际使用 10m ，它只增长 10m ，与VIRT相反 4 、关于库占用内存的情况，它只统计加载的库文件所占内存大小 SHR：shared memory 共享内存 1 、除了自身进程的共享内存，也包括其他进程的共享内存 2 、虽然进程只使用了几个共享库的函数，但它包含了整个共享库的大小 3 、计算某个进程所占的物理内存大小公式：RES – SHR 4 、swap out后，它将会降下来     https: / / huoding.com / 2011 / 08 / 19 / 107 ，写的真好 MongoDB实际使用的Stack大小 所有连接消耗的内存加起来会相当惊人，推荐把Stack设置小一点，比如说 1024 shell> ulimit  - s  1024   Linux 内核stack size 修改 限制Mongodb 内存开销 能否介绍一些有关stack 的东西？例如： 1  stack 主要存放哪类数据？ 2  mongodb 的这类数据都有哪些？ 正常应该多大？ 3  如果一个进程的stack 所需要的大小大于设置大小，内核会怎么处理 通过监控发现，在其高峰时间MongoDB的连接数达到了 1100 ～ 1500 左右，由于每个连接需要使用 10M （stack size默认为 10240 ）的内存，这导致相当大的内存开销 处理方法是，首先通过优化连接池，将连接数控制在了 800 个左右，然后通过修改内核的stack size值，从默认的 10M 修改到 1M ，使连接占用的内存大大减少     你可能想释放掉MongoDB占用的内存 幸好可以使用MongoDB内置的closeAllDatabases命令达到目的 mongo> use admin mongo> db.runCommand({closeAllDatabases: 1 })   通过调整内核参数drop_caches也可以释放缓存 shell> sysctl vm.drop_caches = 1     shell> mongostat mapped  vsize    res faults    940g   1893g   21.9g       0 MongoDB开启了journal，需要在内存里多映射一次数据文件，如果关闭journal，则vsize和mapped大致相当。 如果想验证这一点，可以在开启或关闭journal后，通过pmap命令来观察文件映射情况： shell> pmap $(pidof mongod)     http: / / www.jb51.net / article / 53878.htm db.serverStatus().mem "mem"  : {          "bits"  :  64 ,  - - 64 位机器          "resident"  :  18363 ,  - - 占用物理内存量。          "virtual"  :  478810 ,  - - 占用的虚拟内存量          "supported"  : true,  - - 是否支持扩展内存          "mapped"  :  233311 ,  - - 映射到内存的数据文件大小，很接近于你的所有数据库大小。          "mappedWithJournal"  :  466622 ,          "note"  :  "virtual minus mapped is large. could indicate a memory leak"      },     内存选择 到底MongoDB配备多大内存合适？宽泛点来说，多多益善，如果要确切点来说，这实际取决于你的数据及索引的大小，内存如果能够装下全部数据加索引是最佳情况，不过很多时候，数据都会比内存大，比如本文所涉及的MongoDB实例   mongo> db.stats() http: / / www.cnblogs.com / xuegang / archive / 2011 / 10 / 13 / 2209965.html {      "dataSize"  :  1004862191980 ,      "indexSize"  :  1335929664 }     此时保证内存能装下热数据即可，至于热数据是多少，取决于具体的应用，你也可以通过观察faults的大小来判断当前内存是否能够装下热数据，如果faults持续变大，就说明当前内存已经不能满足热数据的大小了。如此一来内存大小就明确了：内存 > 索引  +  热数据，最好有点富余，毕竟操作系统本身正常运转也需要消耗一部分内存。

1.Too many MongoDB page_faults 172.1.1.1:27017

"page_faults" : 11718117 //数据库访问数据时发现数据不在内存时的页面数量，当数据库性能很差或者数据量极大时，这个值会显著上升

2.关注的性能指标

https://dba.stackexchange.com/questions/46271/what-happens-if-there-are-too-many-inserts-in-mongodb-how-to-ensure-all-data-is

• The Average Flush time (this is how long MongoDB's periodic sync to disk is taking)

平均刷新时间（这是MongoDB周期性同步到磁盘的时间）

• The IOStats in the hardware tab (IOWait in particular)

硬件选项卡中的IOStats（尤其是IOWait）

• Page Faults (if your disk is busy with writes and you need to read data, they are going to be competing for a scarce resource)

页面错误（如果您的磁盘忙于写入，并且您需要读取数据，则它们将竞争稀缺的资源）

It's a bit complicated then, but here's a basic idea:

• When average flush time starts to increase, be worried

• If it gets into the multiple second range, you are probably on the limit (though this depends on the volume of data written and the disk speed)

• If it approaches 60 seconds you will see performance degrade severely (the flush happens every 60 seconds, so they would essentially be queuing up)

• High IOWait is going to hinder performance too, especially if you have to read from disk at any point

• Hence looking at page fault levels will also be important

3.慢查询

Slow query in log

explain，看nYields

getmore csdb.archive query: { _id: { $gt: 1540584014914176, $lt: 1540584641314176 } }

cursorid:88959318045397 ntoreturn:0 keyUpdates:0 numYields: 2858 locks(micros) r:81292194 

nreturned:21332 reslen:554652 415116ms

WorkingSet:

db.serverStatus({"workingSet":1}).workingSet

{

        "note" : "thisIsAnEstimate",

        "pagesInMemory" : 244491,

        "computationTimeMicros" : 42233,

        "overSeconds" : 3

}

insert  query update delete getmore command flushes mapped  vsize    res  faults  locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 

    *0     *0     *0     *0       0     1|0       0   162g   324g  64.7g    1719  csdb:0.0%          0       0|0     3|0    62b     2k    52   14:59:04 

    *0     *0     *0     *0       0     1|0       0   162g   324g  64.7g    1657  csdb:0.0%          0       0|0     3|0    62b     2k    52   14:59:05 

    *0     *0     *0     *0       0     1|0       0   162g   324g  64.7g    1743  csdb:0.0%          0       0|0     2|0    62b     2k    52   14:59:06 

    *0      2     *0     *0       0     1|0       0   162g   324g  64.7g    1878  csdb:0.0%          0       0|0     3|0   203b    99k    52   14:59:07 

    *0      1     *0     *0       2     1|0       0   162g   324g  64.7g    1629  csdb:0.0%          0       0|0     5|0   299b   120k    52   14:59:08 

    *0      2     *0     *0       1     1|0       0   162g   324g  64.7g    1733  csdb:0.0%          0       0|0     3|0   248b   995k    52   14:59:09 

    *0      1     *0     *0       2     1|0       0   162g   324g  64.8g    1694  csdb:0.0%          0       0|0     4|0   299b   547k    52   14:59:10 

    *0     *0     *0     *0       0     1|0       0   162g   324g  64.8g    1519  csdb:0.0%          0       0|0     7|0    62b     2k    52   14:59:11 

    *0      5     *0     *0       0     1|0       1   162g   324g  64.8g    1504  csdb:0.0%          0       0|0     6|0   203b   327k    52   14:59:12 

    *0     *0     *0     *0       1     1|0       0   162g   324g  64.8g    1744  csdb:0.0%          0       0|0     3|0   158b     5k    52   14:59:13 

4.问题

内存够大，但是Mongodb: slow range queries and too many page faults

https://stackoverflow.com/questions/23868635/mongodb-slow-range-queries-and-too-many-page-faults

本文转自 liqius 51CTO博客，原文链接：http://blog.51cto.com/szgb17/1974136，如需转载请自行联系原作者