Ограниченная память MongoDB

Я использую mongo для хранения файлов журнала. Оба mongoDB и mysql работают на одном компьютере, виртуализация mongo env не является вариантом. Боюсь, что скоро я столкнусь с перфомансами, поскольку таблица журналов растет очень быстро. Есть ли способ ограничить резидентную память для монго, чтобы он не питался всей доступной памятью и чрезмерно замедлял сервер mysql?

Машина DB: Debian 'lenny' 5

Другие решения (просьба прокомментировать):

  • Поскольку нам нужны все исторические данные, мы не можем использовать ограниченные коллекции, но я также рассматриваю возможность использования cron script, который выгружает и удаляет старые данные

  • Должен ли я также использовать меньшие клавиши, как это было предложено на других форумах?

ОТВЕТЫ

Ответ 1

Эй, Влад, у вас есть пара простых стратегий, касающихся журналов.

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

Другими словами, вы можете разделить использование ОЗУ на две основные части: индекс и данные.

Если вы используете типичное ведение журнала, часть данных постоянно удаляется, поэтому только индекс действительно остается в ОЗУ.

Второе, что нужно знать, это то, что вы можете уменьшить проблему с индексом, поставив журналы на более мелкие ведра. Подумайте об этом так. Если вы соберете все журналы в коллекции с меткой даты (назовите ее logs20101206), вы также можете управлять размером индекса в ОЗУ.

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

но я также рассматриваю использование cron script, который выгружает и удаляет старые данные

Этот метод регистрации по дням также помогает удалять старые данные. Через три месяца, когда вы закончите с данными, вы просто делаете db.logs20101206.drop(), и коллекция моментально уходит. Обратите внимание, что вы не освобождаете место на диске (все предварительно выделенные), но новые данные заполнят пустое место.

Должен ли я также использовать меньшие клавиши, как это было предложено на других форумах?

Да.

Фактически, я встроил его в свои объекты данных. Поэтому я получаю доступ к данным с помощью logs.action или logs->action, но под ними данные фактически сохраняются в logs.a. Это действительно легко потратить больше места на "поля", чем на "ценности", поэтому стоит сжимать "поля" и пытаться отвлечь его в другом месте.

Ответ 2

Для версии 3.2+, использующей механизм wiredTiger, опция --wiredTigerCacheSizeGB относится к вопросу. Вы можете установить его, если знаете, что именно делаете. Я не знаю, лучше ли это, просто прочитайте и поднимите его здесь.