|
基本方法
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
mapped vsize res faults
940g 1893g 21.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
}
insert query update delete getmore command flushes mapped vsize res faults locked db> *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
|
|
|