【问题标题】:MongoDB replication WIndows RAM issueMongoDB复制Windows RAM问题
【发布时间】:2015-03-03 13:39:20
【问题描述】:

我有两台运行 Windows server 2012 R2 的生产服务器。作为主服务器和辅助服务器,它们用于故障转移场景,如果其中一个发生故障,另一个将承担负载。

我的应用程序正在使用 MongoDB 复制。我有 3 个实例。 Primary 和 arbiter(我将把它移到不同的服务器上,这只是一个临时的souliton)和辅助服务器上的辅助节点。

一段时间后,两台服务器上的 RAM 消耗都变得非常高。 MongoDB 会占用所有可用的 RAM,但不会释放它。我仅在 MongoDB 在副本中工作时才注意到此行为。

我做了一些研究,发现限制mongod进程本身的RAM使用是不可能的。我对使用所有 RAM 的 MongoDB 持怀疑态度。

请分享您的经验、想法或想法,如何限制我的 windows 服务器上 mongodb 进程的 RAM 使用量。

  rs.status()"set": "XXXXXX",
"date": ISODate("2015-03-03T13:35:39.000Z"),
"myState": 1,
"members": [
    {
    "_id": 1,
    "name": "Server1:3000",
    "health": 1,
    "state": 1,
    "stateStr": "PRIMARY",
    "uptime": 67557,
    "optime": Timestamp(1425389739,
    19),
    "optimeDate": ISODate("2015-03-03T13:35:39.000Z"),
    "electionTime": Timestamp(1425322202,
    1),
    "electionDate": ISODate("2015-03-02T18:50:02.000Z"),
    "self": true
    },
    {
    "_id": 2,
    "name": "Abritrer1:3001",
    "health": 1,
    "state": 7,
    "stateStr": "ARBITER",
    "uptime": 67547,
    "lastHeartbeat": ISODate("2015-03-03T13:35:38.000Z"),
    "lastHeartbeatRecv": ISODate("2015-03-03T13:35:39.000Z"),
    "pingMs": 0
    },
    {
    "_id": 3,
    "name": "Server2:3000",
    "health": 1,
    "state": 2,
    "stateStr": "SECONDARY",
    "uptime": 67542,
    "optime": Timestamp(1425389737,
    26),
    "optimeDate": ISODate("2015-03-03T13:35:37.000Z"),
    "lastHeartbeat": ISODate("2015-03-03T13:35:37.000Z"),
    "lastHeartbeatRecv": ISODate("2015-03-03T13:35:38.000Z"),
    "pingMs": 1,
    "syncingTo": "Server1:3000"
    }
],
"ok": 1
}

【问题讨论】:

  • 您是否查看过内存的去向?你能发布db.serverStatus()mem 子文档吗?另外,日志中是否有与性能相关的内容?记录缓慢的查询或较长的刷新时间?
  • 你好@wdberkeley。这是 db.serverStatus() "mem" : { "bits" : 64, "resident" : 956, "virtual" : 91003, "supported" : true, "mapped" : 45402, "mappedWithJournal" : 90804 的 mem 部分,不,我在日志中找不到任何关于性能或记录的慢查询和刷新时间的内容..

标签: mongodb


【解决方案1】:

正是出于这个原因,我们不再在生产环境中使用 MongoDB。 强制 Mongo 放弃内存并不容易,将 Mongo 自身限制在一定的内存限制内同样尴尬。

如果您使用的是 Windows Server 2012,则可以安装 Windows 系统资源管理器,它应该允许您修复 Mongo 进程的最大工作集大小,尽管我自己没有尝试过。

您可能会发现以下关于将进程限制为特定大小的博客文章很有用。

http://blogs.technet.com/b/clinth/archive/2012/10/11/can-a-process-be-limited-on-how-much-physical-memory-it-uses.aspx

除非您在 Windows Server 机器上,否则我不确定您可以使用哪些其他工具来进行更改,但限制操作系统分配的最大工作集的方法似乎是最好的方法。

祝你好运!

编辑 - 作为一种想法,如果您的集合中有大量数据,Mongo 内存使用率总是会显得很高,但这并不总是意味着内存已被使用。 与 Java 和 C# 为垃圾回收分配内存的方式类似,Mongo 将最近较少使用的页面标记为可回收的。 如果另一个进程请求内存,Mongo 应该释放一些它使用较少的页面来提供空间。 当您看到 Mongo 占用了超过 3Gb 的系统内存时,这有点令人担忧,但这并不总是像看起来那么严重。

作为测试,您可以尝试在 Mongo 使用量达到峰值时启动一个需要大量内存的应用程序,看看它是否会释放一些内存。 如果是这样,您也许可以简单地让 Mongo 处理它认为合适的内存使用情况(尽管在您的位置上,我宁愿确切地看到什么是空闲内存,什么不是)。

Mongo FAQ 中有关内存映射文件的部分对此有所了解。 http://docs.mongodb.org/manual/faq/storage/

【讨论】:

  • 谢谢亚历克斯。不幸的是,Windows Server 2012 r2 的资源管理器已被弃用:technet.microsoft.com/library/hh831568.aspx 我担心如果我让 mongoDB 占用所有内存,服务器将变得不负责任(发生 2 次)我正在考虑搬家副本集到 linux (Ubuntu) 机器,因为 mongodb 在 Linux 上更“原生”。
  • 迁移到 Ubuntu 系统当然是一种选择。我发现当我们向它写入数据时,Windows 上的 Mongo 偶尔会变得无响应。话虽如此,我们还是定期将其置于高负荷下,事实证明这是无法维护的。当然值得在 Linux 上尝试内存分配,尽管我可能会建议使用 Debian 作为操作系统,因为它比 Ubuntu 更轻巧,而且通常更稳定(如果不是最新的)。
  • 测试应该提供可靠的结果。但是,我说的是无法承受任何停机时间的生产环境。如前所述,对我们的 Zabbix 警报的较晚反应,即内存消耗超过 20% 可用,服务器变得不负责任,导致客户不满意和停机。
  • 啊,好的,在一个非常严肃的生产环境中。抱歉,我错过了服务器之前两次无响应的情况。由于不推荐使用资源管理器,我不确定您可以使用什么来获得相同的结果。这里有一个工具 - codeproject.com/Articles/685826/… - 可以做同样的工作,但它是一个开源工具,我从未尝试过。这可能是解决问题的一种方法,但我会小心在生产系统中使用它。不过可能值得一看。可能是一个真正的工具宝石。
  • 我也不确定 ProcessGovenor 是否适用于任何 .NET 应用程序,但它似乎在 Windows 进程对象而不是特定于 .NET 的进程对象上运行,因此它可能会完成这项工作。
猜你喜欢
  • 2019-06-11
  • 1970-01-01
  • 2019-10-27
  • 1970-01-01
  • 2012-03-29
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多