Mongod常驻内存使用率低

时间:2013-10-04 03:05:54

标签: mongodb memory

我正在尝试使用MongoDB配置调试一些性能问题,并且我注意到常驻内存使用率非常低(约占系统内存的25%),尽管偶尔会发生大量故障。鉴于MongoDB与内存有关,我很惊讶地发现使用率很低。

这是按内存使用情况排序的顶部快照。可以看出,没有其他进程使用重要内存:

top - 21:00:47 up 136 days,  2:45,  1 user,  load average: 1.35, 1.51, 0.83
Tasks:  62 total,   1 running,  61 sleeping,   0 stopped,   0 zombie
Cpu(s): 13.7%us,  5.2%sy,  0.0%ni, 77.3%id,  0.3%wa,  0.0%hi,  1.0%si,  2.4%st
Mem:   1692600k total,  1676900k used,    15700k free,    12092k buffers
Swap:   917500k total,    54088k used,   863412k free,  1473148k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2461 mongodb   20   0 29.5g 564m 492m S 22.6 34.2  40947:09 mongod
20306 ubuntu    20   0 24864 7412 1712 S  0.0  0.4   0:00.76 bash
20157 root      20   0 73352 3576 2772 S  0.0  0.2   0:00.01 sshd
  609 syslog    20   0  248m 3240  520 S  0.0  0.2  38:31.35 rsyslogd
20304 ubuntu    20   0 73352 1668  872 S  0.0  0.1   0:00.00 sshd
    1 root      20   0 24312 1448  708 S  0.0  0.1   0:08.71 init
20442 ubuntu    20   0 17308 1232  944 R  0.0  0.1   0:00.54 top

我想至少理解为什么服务器没有更好地利用内存,理想情况下要学习如何优化服务器配置或查询以提高性能。

更新: 内存使用情况看起来很高,这可能导致结论是另一个过程。没有其他进程在服务器上使用任何重要内存;内存似乎在缓存中消耗,但我不清楚为什么会出现这种情况:

$free -m
             total       used       free     shared    buffers     cached
Mem:          1652       1602         50          0         14       1415
-/+ buffers/cache:        172       1480
Swap:          895         53        842

更新: 您可以看到数据库仍然是页面错误:

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn   set repl       time
     0    402    377      0    1167     446       0  24.2g  51.4g     3g      0  <redacted>:9.7%          0       0|0     1|0   217k   420k   457 mover  PRI   03:58:43
    10    295    323      0     961     592       0  24.2g  51.4g  3.01g      0 <redacted>:10.9%          0      14|0     1|1   228k   500k   485 mover  PRI   03:58:44
    10    240    220      0     698     342       0  24.2g  51.4g  3.02g      5 <redacted>:10.4%          0       0|0     0|0   164k   429k   478 mover  PRI   03:58:45
    25    449    359      0     981     479       0  24.2g  51.4g  3.02g     32 <redacted>:20.2%          0       0|0     0|0   237k   503k   479 mover  PRI   03:58:46
    18    469    337      0     958     466       0  24.2g  51.4g     3g     29 <redacted>:20.1%          0       0|0     0|0   223k   500k   490 mover  PRI   03:58:47
     9    306    238      1     759     325       0  24.2g  51.4g  2.99g     18 <redacted>:10.8%          0       6|0     1|0   154k   321k   495 mover  PRI   03:58:48
     6    301    236      1     765     325       0  24.2g  51.4g  2.99g     20 <redacted>:11.0%          0       0|0     0|0   156k   344k   501 mover  PRI   03:58:49
    11    397    318      0     995     395       0  24.2g  51.4g  2.98g     21 <redacted>:13.4%          0       0|0     0|0   198k   424k   507 mover  PRI   03:58:50
    10    544    428      0    1237     532       0  24.2g  51.4g  2.99g     13 <redacted>:15.4%          0       0|0     0|0   262k   571k   513 mover  PRI   03:58:51
     5    291    264      0     878     335       0  24.2g  51.4g  2.98g     11  <redacted>:9.8%          0       0|0     0|0   163k   330k   513 mover  PRI   03:58:52

3 个答案:

答案 0 :(得分:4)

这似乎是由于服务器上的大量非活动内存导致Mongo无法使用。

通过查看结果:

cat /proc/meminfo

我可以看到大量非活动内存。将此命令用作sudo用户:

free && sync && echo 3 > /proc/sys/vm/drop_caches && echo "" && free

释放非活动内存,在接下来的24小时内,我能够看到Mongo实例的常驻内存增加,消耗服务器上剩余的内存。

请注意以下博文中的说明:

http://tinylan.com/index.php/article/how-to-clear-inactive-memory-in-linux

答案 1 :(得分:0)

MongoDB只使用它所需的内存,所以如果MongoDB中的所有数据和索引都能够适应它当前使用的内容,那么你将无法再推送它了。

如果数据集大于内存,则需要考虑以下几点:

  • 通过运行mongostat并查看驻留内存来检查MongoDB本身以查看它认为使用了多少数据
  • MongoDB最近重新启动了吗?如果它很冷,那么数据将被分页后才会在内存中(导致更多的页面错误最初会逐渐解决)。查看touch命令,了解有关“升温MongoDB”的更多信息
  • 检查您的预读设置。如果您的系统预读太高,那么MongoDB无法有效地使用系统上的内存。对于MongoDB,一个好的数字开始是32的设置(假设你有512字节的块,这是16 KB的预读)

答案 2 :(得分:0)

我遇到了同样的问题:Windows Server 2008 R2,16 Gb RAM,Mongo 2.4.3。 Mongo仅使用2 Gb的RAM并产生大量页面错误。查询非常慢。磁盘空闲,内存空闲。找不到升级到2.6.5的其他解决方案。它有所帮助。