Được rồi, sau khi lần theo manh mối do loicmathieu và jstell đưa ra, và tìm hiểu thêm một chút, đây là những điều tôi đã tìm ra về MongoDB bằng cách sử dụng công cụ lưu trữ WiredTiger. Tôi đang đặt nó ở đây nếu có ai gặp phải câu hỏi tương tự
Các luồng sử dụng bộ nhớ mà tôi đã đề cập, tất cả đều thuộc về 2012-2014, tất cả đều có trước WiredTiger và đang mô tả hành vi của công cụ lưu trữ MMAPV1 ban đầu không có bộ đệm riêng hoặc hỗ trợ nén
WiredTiger chỉ kiểm soát kích thước bộ nhớ được sử dụng trực tiếp bởi công cụ lưu trữ WiredTiger [không phải tổng bộ nhớ được sử dụng bởi mongod]. Nhiều thứ khác có khả năng chiếm bộ nhớ trong cấu hình MongoDB/WiredTiger, chẳng hạn như sau
WiredTiger nén dung lượng đĩa, nhưng dữ liệu trong bộ nhớ không được nén
WiredTiger theo mặc định không đồng bộ hóa dữ liệu trên mỗi lần xác nhận, do đó, các tệp nhật ký cũng nằm trong RAM, điều này sẽ gây tổn hại cho bộ nhớ. Người ta cũng đề cập rằng để sử dụng I/O một cách hiệu quả, WiredTiger sẽ gộp các yêu cầu I/O [lỗi bộ đệm] lại với nhau, điều đó dường như cũng chiếm một số RAM [Trên thực tế, các trang bẩn [các trang đã thay đổi/cập nhật] có một danh sách các bản cập nhật
WiredTiger giữ nhiều phiên bản của bản ghi trong bộ đệm của nó [Kiểm soát đồng thời nhiều phiên bản, thao tác đọc truy cập phiên bản đã cam kết cuối cùng trước khi chúng hoạt động]
WiredTiger Giữ tổng kiểm tra dữ liệu trong bộ đệm
Bản thân MongoDB tiêu thụ bộ nhớ để xử lý các kết nối mở, tập hợp, mã máy chủ, v.v.
Xem xét những dữ kiện này, việc dựa vào show dbs;
là không đúng về mặt kỹ thuật, vì nó chỉ hiển thị kích thước nén của bộ dữ liệu
Các lệnh sau có thể được sử dụng để có được kích thước tập dữ liệu đầy đủ
db.getSiblingDB['data_server'].stats[]
# OR
db.stats[]
Kết quả này như sau
{
"db" : "data_server",
"collections" : 11,
"objects" : 266565289,
"avgObjSize" : 224.8413545621088,
"dataSize" : 59934900658, # 60GBs
"storageSize" : 22959984640,
"numExtents" : 0,
"indexes" : 41,
"indexSize" : 7757348864, # 7.7GBs
"ok" : 1
}
Vì vậy, có vẻ như kích thước tập dữ liệu thực tế + các chỉ mục của nó đang chiếm khoảng 68GB bộ nhớ đó
Xem xét tất cả những điều này, tôi đoán rằng việc sử dụng bộ nhớ hiện khá được mong đợi, điều tốt là việc giới hạn kích thước bộ đệm WiredTiger hoàn toàn ổn, vì nó xử lý các hoạt động I/O khá hiệu quả [như được mô tả ở trên]
Vẫn còn vấn đề về OOM, để khắc phục vấn đề này, vì chúng tôi không có đủ tài nguyên để loại bỏ mongodb, chúng tôi đã hạ thấp oom_score_adj để ngăn OOM tắt các tiến trình quan trọng trong thời điểm hiện tại [Có nghĩa là chúng tôi đã yêu cầu OOM không giết
Nếu bạn đặt quá nhiều dữ liệu vào cơ sở dữ liệu MongoDB của mình, nó sẽ khiến máy chủ của bạn hết bộ nhớ. Nó cũng có thể làm điều đó một cách nhanh chóng, nhanh đến mức bạn thậm chí sẽ không thể tắt tiến trình mongo db vì bash shell sẽ không còn phản hồi nữa
Giải pháp cho vấn đề này là thêm một nút khác vào cụm của bạn
Chúng tôi minh họa giao diện của máy chủ khi hết bộ nhớ bằng cách cố ý thêm nhiều dữ liệu hơn vào máy 8 GB mà nó có thể hỗ trợ, sau đó chạy các truy vấn đối với dữ liệu đó. Sau đó, chúng tôi hiển thị nhật ký trông như thế nào và bạn có thể sử dụng công cụ nào để theo dõi tình huống này
Với 215 MB dữ liệu, máy chủ này luôn sử dụng 11% bộ nhớ khi thực hiện nhiều tìm kiếm. Sau đó, chúng tôi đã thêm 3. 5 GB dữ liệu tại thời điểm bị khóa khi đạt mức sử dụng bộ nhớ 92%
[Bài viết này là một phần của Hướng dẫn MongoDB của chúng tôi. Sử dụng menu bên phải để điều hướng. ]
Khi MongoDB hết bộ nhớ, hãy thêm một nút khác
MongoDB không phải là cơ sở dữ liệu trong bộ nhớ. Mặc dù nó có thể được cấu hình để chạy theo cách đó. Nhưng nó sử dụng bộ đệm một cách tự do, nghĩa là các bản ghi dữ liệu được lưu giữ trong bộ nhớ để truy xuất nhanh, trái ngược với trên đĩa
MongoDB, trong cấu hình mặc định của nó, sẽ sử dụng sẽ sử dụng dung lượng lớn hơn là 256 MB hoặc ½ của [ram – 1 GB] cho kích thước bộ đệm của nó
Bạn có thể giới hạn kích thước bộ đệm MongoDB bằng cách thêm đối số cacheSizeGB vào /etc/mongod. conf tập tin cấu hình, như hình dưới đây. Nhưng MongoDB sử dụng cả bộ đệm bên trong và bộ đệm hệ thống tệp của hệ thống. Nên hạn chế chỗ này sẽ cắt giảm tiêu thụ chỗ khác. Vì vậy, đó không phải là một giải pháp
storage: dbPath: /var/lib/mongodb journal: enabled: true wiredTiger: engineConfig: cacheSizeGB: 1
Dịch vụ giám sát miễn phí từ MongoDB
Bạn nên tận dụng dịch vụ giám sát miễn phí do MongoDB cung cấp. Điều đó được lưu trữ trên trang web của họ, nhưng điều đó không có nghĩa là bạn cần sử dụng dịch vụ đám mây của họ [Atlas]. Nó hoạt động với các máy chủ của riêng bạn
Để sử dụng, hãy mở vỏ mongo và sau đó dán vào lệnh này
db.enableFreeMonitoring[]
Một phần của trang web của họ trông giống như thế này. Bạn có thể thấy rằng trên máy 8GB này đã hết bộ nhớ. Điều này sẽ khiến MongoDB gửi số liệu thống kê sử dụng đến trang web của họ, nơi họ sẽ theo dõi các trạng thái đó và lưu trữ nó trong một trang web cho bạn. Họ cung cấp cho bạn một URL để theo dõi trang web của bạn. Đó là một URL cố định khi họ chỉ định một ID duy nhất cho bản cài đặt của bạn
Hiển thị bộ nhớ Sử dụng MongoDB
Các số liệu này bao gồm mức sử dụng cpu, v.v. Ở trên tôi chỉ hiển thị phần bộ nhớ. Đó là
- thường trú—số lượng bộ nhớ vật lý thực tế [RAM] được sử dụng bởi một tiến trình
- ảo—RAM cộng với bộ nhớ đã mở rộng tới bộ nhớ cache của hệ thống tệp, tôi. e. bộ nhớ ảo
- đã ánh xạ—MongoDB kể từ phiên bản 3. 2 không thực hiện ánh xạ bộ nhớ của các tệp nữa. Điều đó đã được sử dụng bởi mô-đun quản lý bộ nhớ trước đó có tên là MMAPv1. Bây giờ nó sử dụng WiredTiger theo mặc định
Để kiểm tra bộ đệm hệ thống tệp của bạn, hãy chạy free -k để hiển thị bộ nhớ ảo khả dụng tính bằng kilobyte. Dưới đây là giao diện máy chủ của tôi trong khoảng thời gian 5 phút khi tôi chạy máy hết bộ nhớ. Cột cần lưu ý có sẵn. Chia số được hiển thị cho 1024*1024 để chuyển đổi số này thành gigabyte
free -k total used free shared buff/cache available Mem: 8173744 1088440 6753392 9052 331912 6816176 Swap: 0 0 0 total used free shared buff/cache available Mem: 8173744 4654600 2663432 9080 855712 3249520 Swap: 0 0 0 total used free shared buff/cache available Mem: 8173744 7992568 119508 9052 61668 45682
Tất nhiên bạn cũng có thể sử dụng top -p [mongod pid] để theo dõi bộ nhớ. VIRT và RES là bộ nhớ ảo và thường trú. Dưới đây bạn thấy rằng mongod đang sử dụng 91% bộ nhớ của hệ thống trong ví dụ này. Tại thời điểm đó, hệ thống trở nên không phản hồi
Bạn cũng có thể lấy số liệu thống kê sử dụng bộ nhớ từ MongoDB trong shell
db.serverStatus[].mem { "bits" : 64, "resident" : 907, "virtual" : 1897, "supported" : true, "mapped" : 0, "mappedWithJournal" : 0 }
Nếu bạn thậm chí đã thực hiện lập trình C hoặc C++, bạn sẽ quen thuộc với malloc. Đó là chức năng hệ thống bạn gọi khi cần dự trữ bộ nhớ cho máy của mình. Khi MongoDB không thể thực hiện được nữa, những cảnh báo này bắt đầu hiển thị trong /var/log/mongodb/mongod. đăng nhập
2019-02-19T03:44:18.738+0000 I COMMAND [ftdc] serverStatus was very slow: { after basic: 202, after asserts: 686, after backgroundFlushing: 890, after connections: 1399, after dur: 1717, after extra_info: 2039, after freeMonitoring: 3003, after globalLock: 3389, after locks: 4073, after logicalSessionRecordCache: 4782, after network: 5520, after opLatencies: 6068, after opcounters: 6477, after opcountersRepl: 6818, after repl: 7441, after security: 7799, after storageEngine: 8616, after tcmalloc: 9676, after transactions: 10081, after transportSecurity: 10412, after wiredTiger: 22733, at end: 24170 }
Cho đến khi cuối cùng nó nói
2019-02-19T03:45:17.456+0000 F - [free_mon] out of memory.
Bạn cũng có thể đăng nhập vào mongo và lặp lại hai lệnh bên dưới [bạn cần thực hiện cả hai lệnh để cập nhật đầu ra] để xem mức sử dụng bộ nhớ của bạn tăng đột biến khi máy chủ của bạn xuống dốc
________số 8_______Đây là đầu ra. Như bạn có thể thấy nó đã sử dụng hết bộ nhớ khả dụng trên máy 8GB này. Bạn cũng có thể đăng nhập vào mongo và lặp lại hai lệnh bên dưới [bạn cần thực hiện cả hai lệnh để cập nhật đầu ra] để xem mức sử dụng bộ nhớ của bạn tăng đột biến khi máy chủ của bạn xuống dốc