mongodb 性能调优
基本方法http://www.iyunv.net/article/53878.htm
MongoDB db.serverStatus()输出内容中文注释
http://www.iyunv.net/article/69025.htm
MongoDB运行状态监控、性能分析工具mongostat详解
http://blog.csdn.net/miyatang/article/details/23935729
性能指标
mongodb与内存的关系 2011
虚拟内存
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
mappedvsize res faults
940g1893g21.9g 0
MongoDB开启了journal，需要在内存里多映射一次数据文件，如果关闭journal，则vsize和mapped大致相当。
如果想验证这一点，可以在开启或关闭journal后，通过pmap命令来观察文件映射情况：
shell> pmap $(pidof mongod)
http://www.iyunv.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>
[*] 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
}
insertquery update delete getmore command flushes mappedvsize resfaultslocked db> *0 *0 *0 *0 0 1|0 0 162g 324g64.7g 1719csdb:0.0% 0 0|0 3|0 62b 2k 52 14:59:04
*0 *0 *0 *0 0 1|0 0 162g 324g64.7g 1657csdb:0.0% 0 0|0 3|0 62b 2k 52 14:59:05
*0 *0 *0 *0 0 1|0 0 162g 324g64.7g 1743csdb:0.0% 0 0|0 2|0 62b 2k 52 14:59:06
*0 2 *0 *0 0 1|0 0 162g 324g64.7g 1878csdb:0.0% 0 0|0 3|0 203b 99k 52 14:59:07
*0 1 *0 *0 2 1|0 0 162g 324g64.7g 1629csdb:0.0% 0 0|0 5|0 299b 120k 52 14:59:08
*0 2 *0 *0 1 1|0 0 162g 324g64.7g 1733csdb:0.0% 0 0|0 3|0 248b 995k 52 14:59:09
*0 1 *0 *0 2 1|0 0 162g 324g64.8g 1694csdb:0.0% 0 0|0 4|0 299b 547k 52 14:59:10
*0 *0 *0 *0 0 1|0 0 162g 324g64.8g 1519csdb:0.0% 0 0|0 7|0 62b 2k 52 14:59:11
*0 5 *0 *0 0 1|0 1 162g 324g64.8g 1504csdb:0.0% 0 0|0 6|0 203b 327k 52 14:59:12
*0 *0 *0 *0 1 1|0 0 162g 324g64.8g 1744csdb: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
页:
[1]