青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

攀升·Uranus


Something Different,Something New
數(shù)據(jù)加載中……

(轉(zhuǎn))MongoDB與內(nèi)存

@import url(http://www.shnenglu.com/cutesoft_client/cuteeditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

MongoDB與內(nèi)存

但凡初次接觸MongoDB的人,無不驚訝于它對內(nèi)存的貪得無厭,至于個中緣由,我先講講Linux是如何管理內(nèi)存的,再說說MongoDB是如何使用內(nèi)存的,答案自然就清楚了。

據(jù)說帶著問題學習更有效,那就先看一個MongoDB服務器的top命令結(jié)果:

shell> top -p $(pidof mongod)
Mem:  32872124k total, 30065320k used,  2806804k free,   245020k buffers
Swap:  2097144k total,      100k used,  2097044k free, 26482048k cached
VIRT  RES  SHR %MEM
1892g  21g  21g 69.6

這臺MongoDB服務器有沒有性能問題?大家可以一邊思考一邊繼續(xù)閱讀。

先講講Linux是如何管理內(nèi)存的

在Linux里(別的系統(tǒng)也差不多),內(nèi)存有物理內(nèi)存和虛擬內(nèi)存之說,物理內(nèi)存是什么自然無需解釋,虛擬內(nèi)存實際是物理內(nèi)存的抽象,多數(shù)情況下,出于方便性的考慮,程序訪問的都是虛擬內(nèi)存地址,然后操作系統(tǒng)會通過Page Table機制把它翻譯成物理內(nèi)存地址,詳細說明可以參考Understanding MemoryUnderstanding Virtual Memory,至于程序是如何使用虛擬內(nèi)存的,可以參考Playing with Virtual Memory,這里就不多費口舌了。

很多人會把虛擬內(nèi)存和Swap混為一談,實際上Swap只是虛擬內(nèi)存引申出的一種技術而已:操作系統(tǒng)一旦物理內(nèi)存不足,為了騰出內(nèi)存空間存放新內(nèi)容,就會把當前物理內(nèi)存中的內(nèi)容放到交換分區(qū)里,稍后用到的時候再取回來,需要注意的是,Swap的使用可能會帶來性能問題,偶爾為之無需緊張,糟糕的是物理內(nèi)存和交換分區(qū)頻繁的發(fā)生數(shù)據(jù)交換,這被稱之為Swap顛簸,一旦發(fā)生這種情況,先要明確是什么原因造成的,如果是內(nèi)存不足就好辦了,加內(nèi)存就可以解決,不過有的時候即使內(nèi)存充足也可能會出現(xiàn)這種問題,比如MySQL就有可能出現(xiàn)這樣的情況,一個可選的解決方法是限制使用Swap:

shell> sysctl -w vm.swappiness=0

查看內(nèi)存情況最常用的是free命令:

shell> free -m
total       used       free     shared    buffers     cached
Mem:         32101      29377       2723          0        239      25880
-/+ buffers/cache:       3258      28842
Swap:         2047          0       2047

新手看到used一欄數(shù)值偏大,free一欄數(shù)值偏小,往往會認為內(nèi)存要用光了。其實并非如此,之所以這樣是因為每當我們操作文件的時候,Linux都會盡可能的把文件緩存到內(nèi)存里,這樣下次訪問的時候,就可以直接從內(nèi)存中取結(jié)果,所以cached一欄的數(shù)值非常的大,不過不用擔心,這部分內(nèi)存是可回收的,操作系統(tǒng)的虛擬內(nèi)存管理器會按照LRU算法淘汰冷數(shù)據(jù)。還有一個buffers,也是可回收的,不過它是保留給塊設備使用的。

知道了原理,我們就可以推算出系統(tǒng)可用的內(nèi)存是free + buffers + cached:

shell> echo $((2723 + 239 + 25880))
28842

至于系統(tǒng)實際使用的內(nèi)存是used – buffers – cached:

shell> echo $((29377 - 239 - 25880))
3258

除了free命令,還可以使用sar命令:

shell> sar -r
kbmemfree kbmemused  %memused kbbuffers  kbcached
3224392  29647732     90.19    246116  26070160
shell> sar -W
pswpin/s pswpout/s
0.00      0.00

希望你沒有被%memused嚇到,如果不幸言中,重讀本文。

再說說MongoDB是如何使用內(nèi)存的

目前,MongoDB使用的是內(nèi)存映射存儲引擎,它會把數(shù)據(jù)文件映射到內(nèi)存中,如果是讀操作,內(nèi)存中的數(shù)據(jù)起到緩存的作用,如果是寫操作,內(nèi)存還可以把隨機的寫操作轉(zhuǎn)換成順序的寫操作,總之可以大幅度提升性能。MongoDB并不干涉內(nèi)存管理工作,而是把這些工作留給操作系統(tǒng)的虛擬內(nèi)存管理器去處理,這樣做的好處是簡化了MongoDB的工作,但壞處是你沒有方法很方便的控制MongoDB占多大內(nèi)存,幸運的是虛擬內(nèi)存管理器的存在讓我們多數(shù)時候并不需要關心這個問題。

MongoDB的內(nèi)存使用機制讓它在緩存重建方面更有優(yōu)勢,簡而言之:如果重啟進程,那么緩存依然有效,如果重啟系統(tǒng),那么可以通過拷貝數(shù)據(jù)文件到/dev/null的方式來重建緩存,更詳細的描述請參考:Cache Reheating – Not to be Ignored

有時候,即便MongoDB使用的是64位操作系統(tǒng),也可能會遭遇OOM問題,出現(xiàn)這種情況,多半是因為限制了內(nèi)存的大小所致,可以這樣查看當前值:

shell> ulimit -a | grep memory

多數(shù)操作系統(tǒng)缺省都是把它設置成unlimited的,如果你的操作系統(tǒng)不是,可以這樣修改:

shell> ulimit -m unlimited
shell> ulimit -v unlimited

注:ulimit的使用是有上下文的,最好放在MongoDB的啟動腳本里。

有時候,MongoDB連接數(shù)過多的話,會拖累性能,可以通過serverStatus查詢連接數(shù):

mongo> db.serverStatus().connections

每個連接都是一個線程,需要一個Stack,Linux下缺省的Stack設置一般比較大:

shell> ulimit -a | grep stack
stack size              (kbytes, -s) 10240

至于MongoDB實際使用的Stack大小,可以用如下命令確認(單位:K):

shell> cat /proc/$(pidof mongod)/limits | grep stack | awk -F 'size' '{print int($NF)/1024}'

如果Stack過大(比如:10240K)的話沒有意義,簡單對照命令結(jié)果中的Size和Rss:

shell> cat /proc/$(pidof mongod)/smaps | grep 10240 -A 10

所有連接消耗的內(nèi)存加起來會相當驚人,推薦把Stack設置小一點,比如說1024:

shell> ulimit -s 1024

注:從MongoDB1.8.3開始,MongoDB會在啟動時自動設置Stack。

有時候,出于某些原因,你可能想釋放掉MongoDB占用的內(nèi)存,不過前面說了,內(nèi)存管理工作是由虛擬內(nèi)存管理器控制的,幸好可以使用MongoDB內(nèi)置的closeAllDatabases命令達到目的:

mongo> use admin
mongo> db.runCommand({closeAllDatabases:1})

另外,通過調(diào)整內(nèi)核參數(shù)drop_caches也可以釋放緩存:

shell> sysctl -w vm.drop_caches=1

平時可以通過mongo命令行來監(jiān)控MongoDB的內(nèi)存使用情況,如下所示:

mongo> db.serverStatus().mem:
{
"resident" : 22346,
"virtual" : 1938524,
"mapped" : 962283
}

還可以通過mongostat命令來監(jiān)控MongoDB的內(nèi)存使用情況,如下所示:

shell> mongostat
mapped  vsize    res faults
940g  1893g  21.9g      0

其中內(nèi)存相關字段的含義是:

  • mapped:映射到內(nèi)存的數(shù)據(jù)大小
  • visze:占用的虛擬內(nèi)存大小
  • res:占用的物理內(nèi)存大小

注:如果操作不能在內(nèi)存中完成,結(jié)果faults列的數(shù)值不會是0,視大小可能有性能問題。

在上面的結(jié)果中,vsize是mapped的兩倍,而mapped等于數(shù)據(jù)文件的大小,所以說vsize是數(shù)據(jù)文件的兩倍,之所以會這樣,是因為本例中,MongoDB開啟了journal,需要在內(nèi)存里多映射一次數(shù)據(jù)文件,如果關閉journal,則vsize和mapped大致相當。

如果想驗證這一點,可以在開啟或關閉journal后,通過pmap命令來觀察文件映射情況:

shell> pmap $(pidof mongod)

到底MongoDB配備多大內(nèi)存合適?寬泛點來說,多多益善,如果要確切點來說,這實際取決于你的數(shù)據(jù)及索引的大小,內(nèi)存如果能夠裝下全部數(shù)據(jù)加索引是最佳情況,不過很多時候,數(shù)據(jù)都會比內(nèi)存大,比如本文所涉及的MongoDB實例:

mongo> db.stats()
{
"dataSize" : 1004862191980,
"indexSize" : 1335929664
}

本例中索引只有1G多,內(nèi)存完全能裝下,而數(shù)據(jù)文件則達到了1T,估計很難找到這么大內(nèi)存,此時保證內(nèi)存能裝下熱數(shù)據(jù)即可,至于熱數(shù)據(jù)是多少,取決于具體的應用,你也可以通過觀察faults的大小來判斷當前內(nèi)存是否能夠裝下熱數(shù)據(jù),如果faults持續(xù)變大,就說明當前內(nèi)存已經(jīng)不能滿足熱數(shù)據(jù)的大小了。如此一來內(nèi)存大小就明確了:內(nèi)存 > 索引 + 熱數(shù)據(jù),最好有點富余,畢竟操作系統(tǒng)本身正常運轉(zhuǎn)也需要消耗一部分內(nèi)存。

關于MongoDB與內(nèi)存的話題,大家還可以參考官方文檔中的相關介紹。

@import url(http://www.shnenglu.com/cutesoft_client/cuteeditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

posted on 2012-08-06 13:36 攀升 閱讀(1813) 評論(0)  編輯 收藏 引用 所屬分類: Linux

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            99riav久久精品riav| 欧美伊人久久久久久久久影院| 久久综合给合| 久久久久久久久久久久久久一区| 国产亚洲一区二区精品| 女生裸体视频一区二区三区| 欧美电影免费观看高清| 一区二区久久久久久| 一本不卡影院| 国产日韩亚洲欧美精品| 久热精品视频| 欧美日韩一区在线观看视频| 亚洲欧美在线网| 久久久亚洲国产天美传媒修理工| 亚洲精品美女在线观看| 99视频有精品| 国产亚洲一区二区三区在线播放| 久久国产精品黑丝| 久久最新视频| 久久视频在线免费观看| 欧美日韩妖精视频| 欧美自拍丝袜亚洲| 老**午夜毛片一区二区三区| 亚洲精品在线观| 亚洲欧美一区二区精品久久久| 影音先锋日韩有码| 亚洲区中文字幕| 欧美日韩亚洲高清| 米奇777在线欧美播放| 国产精品黄色在线观看| 欧美aⅴ99久久黑人专区| 国产精品国产三级国产aⅴ9色| 久久综合导航| 亚洲国产精品va在看黑人| 亚洲精品欧美日韩专区| 国产精品久久久久久亚洲调教| 久久永久免费| 国产欧美日韩亚州综合| 亚洲精品一区在线| 91久久国产综合久久91精品网站| 亚洲欧美日韩国产综合在线| 亚洲精品一区在线| 久久九九免费| 久久久精品999| 国产精品国产馆在线真实露脸| 亚洲国产日韩欧美| 在线欧美视频| 久久精品国产69国产精品亚洲| 亚洲欧美日韩一区二区三区在线观看| 免费短视频成人日韩| 久久九九免费视频| 国产精品私拍pans大尺度在线 | 国产精品久久久爽爽爽麻豆色哟哟| 免费在线看一区| 黄色一区三区| 久久精品国产亚洲5555| 久久精品欧洲| 国产欧美视频一区二区| 亚洲女ⅴideoshd黑人| 亚洲欧美日韩一区二区三区在线观看 | 久久青草久久| 红桃视频成人| 久久全球大尺度高清视频| 另类av一区二区| 在线观看成人av| 久久久久久91香蕉国产| 欧美r片在线| 亚洲欧洲日产国码二区| 欧美韩日一区二区三区| 亚洲国产日韩一区二区| 99国产精品久久久久久久久久 | 亚洲一区二区三| 欧美影院一区| 国产一区二区在线观看免费播放| 久久激情视频久久| 免费视频一区| 亚洲精品一区二区三| 欧美日韩精品系列| 亚洲午夜精品一区二区| 久久riav二区三区| 一区在线观看| 欧美激情视频在线免费观看 欧美视频免费一 | 亚洲黄色一区二区三区| 制服诱惑一区二区| 国产欧美大片| 久久综合综合久久综合| 亚洲免费激情| 久久国产免费| 亚洲精品日韩精品| 国产精品手机视频| 免费成人高清视频| 亚洲视频网站在线观看| 久久亚洲色图| 国产精品大全| 亚洲无线观看| 国产视频久久久久久久| 麻豆精品精华液| 在线视频免费在线观看一区二区| 欧美中文字幕视频| 91久久午夜| 国产精品手机在线| 欧美激情中文字幕一区二区| 亚洲女ⅴideoshd黑人| 亚洲高清视频在线观看| 欧美一区二区免费| 亚洲精品久久久久中文字幕欢迎你 | 欧美日韩一区在线观看视频| 久久国产精品久久w女人spa| 亚洲国产精品一区二区三区 | 黄色免费成人| 欧美色图一区二区三区| 久久久久九九九九| 亚洲视频国产视频| 最新亚洲一区| 老司机一区二区| 欧美一区二区三区在线视频 | 亚洲精品日本| 亚洲丰满在线| 国精品一区二区三区| 欧美午夜免费| 欧美精品18| 开心色5月久久精品| 欧美一区二区三区在线观看视频 | 欧美一区二区三区电影在线观看| 亚洲黄色在线观看| 红桃视频亚洲| 好看的日韩av电影| 国产精品亚洲综合久久| 欧美精品三级日韩久久| 免费日韩视频| 狼人社综合社区| 久久久久九九九| 久久久久久久999精品视频| 欧美中文字幕在线| 欧美一级视频| 午夜在线播放视频欧美| 亚洲一区美女视频在线观看免费| 亚洲三级电影在线观看| 亚洲欧洲在线看| 91久久夜色精品国产网站| 亚洲成在线观看| 亚洲国产免费看| 亚洲精品国产精品乱码不99| 亚洲欧洲精品天堂一级| 亚洲精品国产日韩| 亚洲国产精品第一区二区| 亚洲九九精品| 欧美一区二区三区四区视频| 欧美国产精品中文字幕| 亚洲在线播放| 欧美亚洲综合久久| 久久九九99| 你懂的网址国产 欧美| 亚洲高清资源综合久久精品| 亚洲精品一二| 亚洲一区二区三区四区视频| 午夜久久99| 久久免费高清| 欧美精品在线观看| 国产精品久久久久影院亚瑟| 久久国产黑丝| 蜜桃久久精品乱码一区二区| 免费观看一区| 亚洲精品久久久久久久久| 一本久道久久综合狠狠爱| 亚洲一区二区在线免费观看视频| 校园春色综合网| 老司机67194精品线观看| 欧美精品久久久久久久久老牛影院| 欧美日韩亚洲一区二区三区| 国产视频久久久久| 亚洲人成人一区二区三区| 亚洲一区二区在线看| 久久人人97超碰国产公开结果| 欧美国产一区二区| 国产精品99久久99久久久二8| 午夜欧美大尺度福利影院在线看| 美女视频黄免费的久久| 欧美亚男人的天堂| 亚洲高清色综合| 亚洲午夜在线视频| 免费人成网站在线观看欧美高清 | 艳女tv在线观看国产一区| 先锋影音网一区二区| 欧美高清视频| 亚洲尤物在线| 欧美成人午夜77777| 国产伦精品一区二区三区高清版 | 国产精品视频精品视频| 亚洲国产日韩欧美一区二区三区| 亚洲欧美高清| 亚洲国产欧美一区二区三区久久 | 欧美在线视频免费观看| 欧美日韩一区二区免费视频| 又紧又大又爽精品一区二区| 亚洲欧美日韩中文视频| 亚洲风情亚aⅴ在线发布| 久久精品日产第一区二区三区| 欧美午夜欧美| 日韩一级视频免费观看在线|