MongoDB chấm dứt khi hết bộ nhớ


11

Tôi có cấu hình như sau:

  • một máy chủ chạy ba container docker:
    • MongoDB
    • Redis
    • Một chương trình sử dụng hai container trước để lưu trữ dữ liệu

Cả Redis và MongoDB đều được sử dụng để lưu trữ lượng dữ liệu khổng lồ. Tôi biết Redis cần giữ tất cả dữ liệu của nó trong RAM và tôi ổn với điều này. Thật không may, điều xảy ra là mongo bắt đầu chiếm rất nhiều RAM và ngay khi RAM máy chủ đầy (chúng ta đang nói về 32GB ở đây), thì mongo hoặc Redis gặp sự cố.

Tôi đã đọc các câu hỏi trước đây về điều này:

  1. Hạn chế sử dụng RAM MongoDB : rõ ràng hầu hết RAM được sử dụng hết bởi bộ đệm WiredTiger
  2. Bộ nhớ giới hạn MongoDB : ở đây rõ ràng vấn đề là dữ liệu nhật ký
  3. Giới hạn việc sử dụng bộ nhớ RAM trong MongoDB : ở đây họ đề xuất giới hạn bộ nhớ của người dùng để nó sử dụng một lượng bộ nhớ nhỏ hơn cho bộ nhớ cache / nhật ký / dữ liệu của nó
  4. MongoDB sử dụng quá nhiều bộ nhớ : ở đây họ nói rằng đó là hệ thống bộ nhớ đệm WiredTiger có xu hướng sử dụng càng nhiều RAM càng tốt để cung cấp truy cập nhanh hơn. Họ cũng nóiit's completely okay to limit the WiredTiger cache size, since it handles I/O operations pretty efficiently
  5. Có tùy chọn nào để hạn chế sử dụng bộ nhớ mongodb không? : bộ nhớ đệm một lần nữa, họ cũng thêmMongoDB uses the LRU (Least Recently Used) cache algorithm to determine which "pages" to release, you will find some more information in these two questions
  6. Mối quan hệ chỉ số / RAM MongoDB : quote: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.
  7. Làm cách nào để giải phóng bộ nhớ đệm được MongoDB sử dụng? : trả lời giống như trong 5.

Bây giờ những gì tôi dường như hiểu từ tất cả các câu trả lời là:

  1. Để truy cập nhanh hơn, sẽ tốt hơn cho mongo phù hợp với tất cả các chỉ số trong RAM. Tuy nhiên, trong trường hợp của tôi, tôi ổn với các chỉ số nằm trong đĩa vì tôi có ổ SSD khá nhanh.
  2. RAM chủ yếu được sử dụng để lưu vào bộ nhớ cache của mongo.

Xem xét điều này, tôi đã mong đợi mongo sẽ thử và sử dụng nhiều dung lượng RAM nhất có thể nhưng có thể hoạt động với ít không gian RAM và lấy hầu hết mọi thứ từ đĩa. Tuy nhiên, tôi đã giới hạn bộ nhớ của trình chứa Docker (ví dụ như 8GB), bằng cách sử dụng --memory--memory-swap, nhưng thay vì tìm nạp nội dung từ đĩa, mongo chỉ bị hỏng ngay khi hết bộ nhớ.

Làm cách nào tôi có thể buộc mongo chỉ sử dụng bộ nhớ khả dụng và tìm nạp từ đĩa mọi thứ không phù hợp với bộ nhớ?


Nó được gọi là sát thủ OOM. MongoDB được thiết kế để chạy trên phần cứng hàng hóa. Tôi sẽ không bao giờ chạy nó trên các nguồn lực hạn chế giả tạo. Nếu bạn chỉ có một cơ sở dữ liệu nhỏ, MongoDB không phải là lựa chọn lý tưởng. Nếu bạn có một cơ sở dữ liệu lớn (ba con số triệu đến hàng tỷ mục) thì việc giới hạn tài nguyên là một lựa chọn tồi. Theo vấn đề của bạn: bạn không thể có bánh và ăn nó. Chọn.
Markus W Mahlberg

Nếu được định cấu hình chính xác, MongoDB không nên gặp sự cố khi hết bộ nhớ. Bạn có thể xác nhận phiên bản cụ thể của máy chủ MongoDB và O / S bạn đang sử dụng và cũng mô tả sự cố chi tiết hơn không? Ví dụ, có bất kỳ thông báo nào trong nhật ký MongoDB hoặc dmesgtương quan với việc tắt đột xuất không? Khả năng có thể xảy ra nhất với Docker là các quá trình trong vùng chứa phát hiện RAM tổng thể có sẵn thay vì giới hạn vùng chứa.
Stennie

Theo Ghi chú sản xuất MongoDB : nếu bạn chạy mongodtrong một thùng chứa ( lxc,, cgroupsDocker, v.v.) không có quyền truy cập vào tất cả RAM có sẵn trong hệ thống, bạn phải đặt storage.wiredTiger.engineConfig.cacheSizeGBgiá trị nhỏ hơn dung lượng RAM có sẵn trong các container. Số tiền chính xác phụ thuộc vào các quy trình khác đang chạy trong bộ chứa, nhưng thông thường không nên nhiều hơn giá trị mặc định là 50% RAM trừ đi 1GB.
Stennie

Câu trả lời:


9

Theo MongoDB BOL ở đây đã thay đổi trong phiên bản 3.4: Các giá trị có thể dao động từ 256MBđến 10TBvà có thể là a float. Ngoài ra, giá trị mặc định cũng đã thay đổi.

Bắt đầu từ năm 3.4, các WiredTiger bộ nhớ cache nội bộ, theo mặc định, sẽ sử dụng lớn hơn của một trong hai:

50% of RAM minus 1 GB, or
256 MB.

Với WiredTiger, MongoDB sử dụng cả WiredTiger internal cachefilesystem cache.

Thông qua filesystem cache, MongoDB tự động sử dụng tất cả bộ nhớ trống không được sử dụng bởi WiredTiger cachehoặc bởi các quy trình khác.

Các storage.wiredTiger.engineConfig.cacheSizeGB giới hạn kích thước của WiredTigerbộ nhớ cache nội bộ. Hệ điều hành sẽ sử dụng bộ nhớ trống có sẵn cho bộ đệm của hệ thống tệp, cho phép các tệp dữ liệu MongoDB được nén ở lại trong bộ nhớ. Ngoài ra, operating systemsẽ sử dụng bất kỳ RAM miễn phí để đệm khối hệ thống tệp và bộ đệm hệ thống tệp.

Để phù hợp với người tiêu dùng RAM bổ sung , bạn có thể phải giảm WiredTigerkích thước bộ đệm trong.

Để biết thêm các tùy chọn tệp cấu hình và công cụ lưu trữ WiredTiger của bạn


4

Trên thực tế, nếu bạn nhìn kỹ, nó không phải là mongod mà chết vì "hết bộ nhớ", đó là trình quản lý OOM (hết bộ nhớ) giết chết mongod, bởi vì nó có mức sử dụng bộ nhớ lớn nhất.

Có, bạn có thể cố gắng giải quyết vấn đề với tham số cấu hình monngodb cacheSizeGB , nhưng trong môi trường vùng chứa, tốt hơn là sử dụng các nhóm để giới hạn tài nguyên mà bất kỳ ba container nào của bạn có được.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.