У мене є така конфігурація:
- хост-машина, яка працює з трьома докерними контейнерами:
- MongoDB
- Редіс
- Програма, що використовує попередні два контейнери для зберігання даних
І Redis, і MongoDB використовуються для зберігання величезної кількості даних. Я знаю, що Redis повинен зберігати всі свої дані в оперативній пам'яті, і я з цим добре. На жаль, що трапляється, це те, що монго починає займати багато оперативної пам’яті, і як тільки оперативна оперативна пам’ять заповнена (ми говоримо про 32 ГБ тут), або монго, або Redis виходить з ладу.
Я прочитав наступні запитання щодо цього:
- Обмеження використання оперативної пам'яті MongoDB : очевидно, більшість оперативної пам’яті використовується кешем WiredTiger
- MongoDB обмежує пам'ять : тут, очевидно, проблемою були дані журналу
- Обмежте використання оперативної пам'яті в MongoDB : тут вони пропонують обмежити пам'ять монго, щоб він використовував менший об'єм пам'яті для кешу / журналів / даних
- MongoDB використовує занадто багато пам’яті : тут вони кажуть, що це система кешування WiredTiger, яка прагне використовувати якомога більше оперативної пам’яті для швидшого доступу. Вони також заявляють
it's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently - Чи є можливість обмежити використання пам'яті mongodb? : знову кешування, вони також додають
MongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these two questions - Зв'язок індексу / оперативної пам'яті MongoDB : цитата:
MongoDB keeps what it can of the indexes in RAM. They'll be swaped out on an LRU basis. You'll often see documentation that suggests you should keep your "working set" in memory: if the portions of index you're actually accessing fit in memory, you'll be fine. - як звільнити кешування, яке використовує MongoDB? : така ж відповідь, як у 5.
Тепер, з усіх цих відповідей я розумію:
- Для швидшого доступу монго було б краще відповідати всім індексам оперативної пам'яті. Однак у моєму випадку я добре з показниками, що частково знаходяться на диску, оскільки у мене досить швидкий SSD.
- ОЗП в основному використовується для кешування монго.
З огляду на це, я очікував, що монго спробує використати якомога більше простору оперативної пам’яті, але зможе функціонувати також з невеликим простором оперативної пам’яті та вилученням більшості речей з диска. Однак я обмежив пам'ять контейнера mongo Docker (наприклад, до 8 ГБ), використовуючи --memoryта --memory-swap, але замість того, щоб витягувати речі з диска, монго просто вийшов з ладу, як тільки у нього не вистачало пам'яті.
Як я можу змусити монго використовувати лише наявну пам'ять і витягти з диска все, що не вписується в пам'ять?
dmesgспіввідносяться з несподіваним відключенням? Найбільш імовірна можливість з Docker полягає в тому, що процеси в контейнері виявляють загальну доступну оперативну пам'ять, а не обмеження для контейнера.
mongodв контейнері ( lxc, cgroups, Докер, і т.д.) , що робить НЕ має доступ до всіх оперативної пам'яті в системі, необхідно встановити storage.wiredTiger.engineConfig.cacheSizeGBна значення менше , ніж кількість наявних в оперативній пам'яті контейнер. Точна кількість залежить від інших процесів, що працюють в контейнері, але зазвичай це не повинно перевищувати значення за замовчуванням 50% ОЗУ мінус 1 ГБ.