设为首页 收藏本站
查看: 1503|回复: 0

[经验分享] mongodb 性能调优

[复制链接]

尚未签到

发表于 2018-10-25 07:23:21 | 显示全部楼层 |阅读模式
  基本方法
  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



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.iyunv.com/thread-626081-1-1.html 上篇帖子: Spring整合MongoDB实现多个or的范围查询 下篇帖子: mongodb之Linux下安装
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表