2015-03-03 5 views
1

У меня есть два рабочих сервера под управлением Windows Server 2012 R2. Как первичный и вторичный сервер, они используются для сценария перехода на другой ресурс, где, если он терпит неудачу, другой принимает нагрузку.Репликация MongoDB WIndows Проблема с памятью

Мое приложение использует репликацию MongoDB. У меня 3 экземпляра. Первичный и арбитр (который я собираюсь переместить на другой сервер, это всего лишь временный souliton) и вторичный узел на вторичном сервере.

Через некоторое время потребление ОЗУ становится очень высоким на обоих серверах. MongoDB берет всю доступную оперативную память и не выпускает ее. Я заметил это поведение только тогда, когда MongoDB работает в реплике.

Я провел некоторое исследование и выяснил, что невозможно ограничить использование ОЗУ самого процесса mongod. Я немного скептически отношусь к MongoDB, используя всю оперативную память.

Пожалуйста, поделитесь своими впечатлениями, мыслями или идеями о том, как ограничить использование ОЗУ приложением mongodb на моем сервере Windows.

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 
} 
+0

Вы посмотрели, куда идет память? Можете ли вы разместить подкомплекс 'mem'' db.serverStatus() '? Кроме того, есть ли что-либо в журналах, касающихся производительности?Записанные медленные запросы или длинные таймауты? – wdberkeley

+0

Hello @wdberkeley. Здесь MEM часть db.serverStatus() ' "MEM": { "биты": 64, "резиденты": 956, "виртуальный": 91003, "поддерживается": правда, «отображается »: 45402, « mappedWithJournal »: 90804' Нет, я не мог найти ничего в журналах относительно производительности или зарегистрированных медленных запросов и времени очистки. –

ответ

2

По этой причине мы перешли от использования MongoDB в производственную среду. Нелегко заставить Монго отказаться от памяти, и ограничение самого Монго на определенный предел памяти тоже неудобно.

Если вы используете 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 должен освободить некоторые из менее используемых страниц, чтобы обеспечить пространство. Это несколько беспокоит, когда вы видите, что над 3Gb системной памяти занят Mongo, но это не всегда такая же проблема, как кажется.

В качестве теста вы можете попробовать запустить головоломное приложение для памяти, когда использование Mongo достигнет своего пика, и посмотрите, освобождает ли он память. Если это так, вы могли бы просто позволить Mongo обрабатывать использование памяти по своему усмотрению (хотя в вашей позиции я бы лучше посмотрел, что такое свободная память, а что нет).

Раздел по файлам с памятью в Mongo FAQ немного проливает свет на него. http://docs.mongodb.org/manual/faq/storage/

+0

Добро пожаловать. – Alex

+0

Спасибо, Алекс. К сожалению, менеджер ресурсов для WIndows Server 2012 r2 устарел: technet.microsoft.com/library/hh831568.aspx Я боюсь, если я позволю mongoDB взять всю память, сервер станет безответственным (произошло 2 раза) Я рассматриваю возможность перемещения набор реплик устанавливается на Linux (Ubuntu), поскольку mongodb более «родной» с Linux. –

+0

Переход к системе Ubuntu, безусловно, является опцией. Я обнаружил, что Mongo on Windows иногда становился невосприимчивым, когда мы писали ему данные. Сказав это, мы постоянно подвергали его интенсивной нагрузке, что было просто невозможно поддерживать. Конечно, стоит поэкспериментировать с распределением памяти в Linux, хотя я бы предложил использовать Debian в качестве ОС из-за того, что он несколько легче, чем Ubuntu, и часто более стабилен (если не так, как сейчас). – Alex