Làm cách nào để kiểm tra mức sử dụng bộ nhớ trong MongoDB?

Cụm tiền sản xuất có thêm một số GB đang được sử dụng. Cụm Tiền sản xuất có nhiều điện tích hơn NHƯNG mức tiêu thụ của anh ta thấp hơn và không tăng so với cụm khác có ít điện tích hơn

Bộ trạng thái MongoDB có giới hạn bộ nhớ là 16 GB trong cụm sản xuất, nhưng tiêu thụ nhiều hơn, 11 GB và 20 GB trong giai đoạn tiền sản xuất (Thường tiêu thụ 6-7 GB, .

Gây ra

MongoDB giữ tất cả dữ liệu trong bộ đệm của nó vì lý do hiệu suất và nó sẽ không giải phóng chúng cho đến khi bộ nhớ của nó tăng lên 50% của (RAM hệ thống - 1 GB) (mặc định)

Điều này có nghĩa là bộ nhớ của nó sẽ tăng lên liên tục khi bạn ghi/đọc dữ liệu từ nó. Bạn có thể tìm thêm thông tin tài liệu
Khi bạn chạy bản sao lưu MongoDB, nó sẽ đưa toàn bộ cơ sở dữ liệu vào bộ nhớ, vì vậy sự gia tăng có liên quan đến điều đó. MongoDB sẽ không giải phóng bộ nhớ trừ khi một quá trình khác yêu cầu

Chẩn đoán vấn đề

Để cung cấp cho MongoDB nhiều bộ nhớ hơn để làm việc với


Điều kiện tiên quyết. Có thiết lập CLI lái xe


1) Nhận các giá trị hiện tại đang được sử dụng để phát hành mongoDB

`helm get values mongodb --tls > values-current.yaml`

2) Nối vào cuối `values-current. yaml`

resources:
  limits:
    memory: 16Gi

3) nâng cấp triển khai MongoDB
 

`helm upgrade mongodb https://:/mgmt-repo/requiredAssets/icp-mongodb-3.2.0.tgz --force -f values-current.yaml --tls`

Nếu vì một số lý do mà lệnh đó không thành công, hãy thử điều này.

`helm history mongodb --tls`
`helm rollback mongodb  --tls`

 

Giải quyết vấn đề

Để giải quyết vấn đề này, bạn cần nâng cấp lên ICP 3. 2. 1 và đặt giới hạn cho bộ đệm MongoDB bằng cách áp dụng ICP 3 mới nhất. 2. 1 miếng vá. Hoặc nếu bạn chưa muốn nâng cấp và áp dụng các bản vá thì chỉ có thể hạn chế hoặc làm cho nó phát triển chậm lại.

  • Để giới hạn bộ nhớ mongoDB, bạn có thể làm như sau

1. Chỉnh sửa triển khai mongoDB bằng cách chạy

kubectl edit deployment  -n kube-system

2. Sau đó, bạn có thể thêm đối số --wiredTigerCacheSizeGB vào quá trình triển khai. thông số kỹ thuật. thùng chứa, e. g


spec:
containers:
- args:
- --wiredTigerCacheSizeGB
- "" <------ unit is GB, e.g. 0.5 or 4

Ngoài ra, bạn có thể thử giới hạn tốc độ tăng trưởng bằng cách sử dụng tham số. --weave-interval

Các tham số này cung cấp khoảng thời gian thu thập cho bộ sưu tập dệt

Cung cấp khoảng thời gian lớn hơn (được đặt bằng mili giây, mặc định là 15), bạn có thể giảm tần suất ghi và điều này cũng sẽ hữu ích .

Khi đặt giá trị lớn hơn (ví dụ: 600 hoặc 6000), bạn có thể nhận thấy thông tin cấu trúc liên kết không đầy đủ

Khi một trong các cụm được quản lý đăng dữ liệu lên trung tâm, tất cả dữ liệu cũ có thể bị xóa và đó là lý do tại sao bạn sẽ thấy phần bị thiếu.  

 

Vị trí tài liệu

Toàn cầu

[{"Ngành kinh doanh". {"mã số". "LOB45","nhãn". "Tự động hóa"},"Đơn vị kinh doanh". {"mã số". "BU053","nhãn". "Nền tảng dữ liệu và đám mây"}"Sản phẩm". {"mã số". "SSBS6K","nhãn". "IBM Cloud Private"},"Danh mục ARM". [{"mã số". "a8m0z0000001h3QAAQ","nhãn". "IBM Cloud Private->Performance->Per-Memory"}],"ARM Case Number". "TS004169634","Nền tảng". [{"mã số". "PF025","nhãn". "Nền tảng độc lập"}],"Phiên bản". "Tất cả (các) Phiên bản"}]

Mở rộng quy mô tài nguyên là một cách để thêm nhiều tài nguyên hơn vào môi trường của bạn. Có hai cách chính điều này có thể được thực hiện. tỷ lệ dọc và tỷ lệ ngang

  • Chia tỷ lệ theo chiều dọc đang tăng dung lượng phần cứng cho một phiên bản nhất định, do đó có một máy chủ mạnh hơn
  • Chia tỷ lệ theo chiều ngang là khi bạn thêm nhiều máy chủ hơn vào kiến ​​trúc của mình. Một phương pháp khá chuẩn để mở rộng quy mô theo chiều ngang, đặc biệt là đối với cơ sở dữ liệu,  là cân bằng tải và phân đoạn

Khi ứng dụng của bạn phát triển, các bộ làm việc ngày càng lớn hơn và do đó, chúng tôi bắt đầu thấy các nút thắt cổ chai do dữ liệu không vừa với bộ nhớ phải được truy xuất từ ​​đĩa. Đọc từ đĩa là một hoạt động tốn kém, ngay cả với các ổ NVME hiện đại, vì vậy chúng tôi sẽ cần xử lý một trong các giải pháp mở rộng mà chúng tôi đã đề cập

Trong trường hợp này, chúng ta sẽ thảo luận về việc bổ sung thêm RAM, đây thường là cách nhanh nhất và dễ dàng nhất để mở rộng quy mô phần cứng theo chiều dọc và cách có nhiều bộ nhớ hơn có thể giúp ích rất nhiều cho hiệu suất MongoDB

Cách tính mức sử dụng bộ nhớ trong MongoDB

Trước khi chúng tôi thêm bộ nhớ vào triển khai MongoDB của mình, chúng tôi cần hiểu Mức sử dụng bộ nhớ hiện tại của chúng tôi. Điều này được thực hiện tốt nhất bằng cách truy vấn serverStatus và yêu cầu dữ liệu trên bộ đệm WiredTiger

Kể từ MongoDB 3. 2, MongoDB đã sử dụng WiredTiger làm Công cụ lưu trữ mặc định của nó. Và đến , MongoDB sẽ dự trữ 50% bộ nhớ khả dụng – 1 GB cho bộ đệm WiredTiger hoặc 256 MB, tùy theo giá trị nào lớn hơn

Ví dụ: một hệ thống có 16 GB RAM, sẽ có kích thước bộ đệm WiredTiger là 7. 5 GB

Vỏ bọc

1

( 0. 5 * (16 - 1) )

Kích thước của bộ đệm này rất quan trọng để đảm bảo WiredTiger hoạt động hiệu quả. Rất đáng để xem liệu bạn có nên thay đổi nó từ mặc định hay không. Một nguyên tắc tốt là kích thước của bộ đệm phải đủ lớn để chứa toàn bộ ứng dụng đang hoạt động.

Làm thế nào để chúng ta biết có nên thay đổi nó hay không?

Vỏ bọc

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

db. serverStatus(). có dâyTiger. bộ đệm

{

"Số lượng trang luồng ứng dụng được đọc từ đĩa vào bộ đệm" . 9,

"thời gian đọc trang chủ đề ứng dụng từ đĩa vào bộ đệm (usecs)" . 17555,

"trang chủ đề ứng dụng ghi từ bộ đệm vào số lượng đĩa" . 1820,

"trang chủ đề ứng dụng ghi từ bộ đệm vào thời gian đĩa (usecs)" . 1052322,

"byte được phân bổ để cập nhật" . 20043,

"byte thuộc về hình ảnh trang trong bộ đệm" . 46742,

"byte thuộc về bảng lưu trữ lịch sử trong bộ đệm" . 173,

"byte hiện có trong bộ đệm" . 73044,

"byte bẩn trong bộ nhớ cache tích lũy" . 38638327,

"byte không thuộc về hình ảnh trang trong bộ đệm" . 26302,

"byte đã đọc vào bộ đệm" . 43280,

"byte được ghi từ bộ đệm" . 20517382,

"điểm tràn bộ nhớ cache" . 0,

"xóa trang bị chặn trạm kiểm soát" . 0,

"các cuộc gọi trục xuất để có được một trang" . 5973,

"các cuộc gọi trục xuất để nhận hàng đợi tìm thấy trang trống" . 4973,

"việc trục xuất yêu cầu hàng đợi được tìm thấy trống sau khi khóa" . 20,

"việc trục xuất hiện đang hoạt động ở chế độ tích cực" . 0,

"điểm trống trục xuất" . 0,

"thông qua trục xuất tệp" . 0,

"hàng đợi ứng cử viên máy chủ trục xuất trống khi nạp tiền" . 0,

"hàng đợi ứng cử viên của máy chủ trục xuất không trống khi nạp tiền" . 0,

"các trang trục xuất máy chủ" . 0,

"máy chủ trục xuất đã ngủ vì chúng tôi không đạt được tiến triển với việc trục xuất" . 735,

"máy chủ trục xuất không thể đạt được mục tiêu trục xuất" . 0,

"máy chủ trục xuất đang chờ trang lá" . 2,

"trạng thái trục xuất" . 64,

"biểu đồ trang mục tiêu đi bộ trục xuất - 0-9" . 0,

"biểu đồ trang mục tiêu đi bộ trục xuất - 31-10" . 0,

"biểu đồ trang mục tiêu đi bộ trục xuất - 128 trở lên" . 0,

"biểu đồ trang mục tiêu đi bộ trục xuất - 32-63" . 0,

"biểu đồ trang mục tiêu đi bộ trục xuất - 64-128" . 0,

"chiến lược loại bỏ mục tiêu đi bộ cả trang sạch và trang bẩn" . 0,

"chiến lược loại bỏ mục tiêu đi bộ chỉ làm sạch các trang" . 0,

"chỉ mục tiêu chiến lược loại bỏ chỉ các trang bẩn" . 0,

"việc trục xuất bị bỏ rơi" . 0,

"các cuộc đi bộ trục xuất đã bỏ cuộc vì họ bắt đầu lại cuộc đi bộ hai lần" . 0,

"việc trục xuất đã bỏ cuộc vì họ đã xem quá nhiều trang và không tìm thấy ứng viên nào" . 0,

"các cuộc trục xuất đã bỏ cuộc vì họ xem quá nhiều trang và tìm thấy quá ít ứng cử viên" . 0,

"việc trục xuất đã đi đến cuối cây" . 0,

"việc trục xuất bắt đầu từ gốc cây" . 0,

"các cuộc trục xuất bắt đầu từ vị trí đã lưu trên cây" . 0,

"chuỗi công nhân trục xuất đang hoạt động" . 4,

"đã tạo chuỗi nhân viên trục xuất" . 0,

"các trang trục xuất nhân viên trục xuất" . 902,

"chủ đề nhân viên trục xuất đã bị xóa" . 0,

"số ổn định chuỗi nhân viên trục xuất" . 0,

"tệp có lệnh trục xuất đang hoạt động" . 0,

"các tệp có lượt trục xuất mới đã bắt đầu" . 0,

"thỉnh thoảng buộc điều chỉnh lại nhân viên trục xuất" . 0,

"bắt buộc gỡ bỏ - các trang lưu trữ lịch sử không thể gỡ bỏ trong khi phiên mở con trỏ lưu trữ lịch sử" . 0,

"bắt buộc trục xuất - các trang lưu trữ lịch sử được chọn trong khi phiên có con trỏ lưu trữ lịch sử mở" . 0,

"bắt buộc gỡ bỏ - các trang lưu trữ lịch sử đã được gỡ bỏ thành công trong khi phiên có con trỏ lưu trữ lịch sử đang mở" . 0,

"buộc gỡ bỏ - các trang bị gỡ bỏ được tính sạch" . 0,

"bắt buộc gỡ bỏ - các trang bị gỡ bỏ không có thời gian sạch (usecs)" . 0,

"bắt buộc trục xuất - số trang bị trục xuất bị coi là bẩn" . 0,

"bắt buộc trục xuất - các trang bị trục xuất có thời gian bẩn (usecs)" . 0,

"bắt buộc trục xuất - các trang được chọn do có quá nhiều mục bị xóa" . 0,

"buộc trục xuất - số trang đã chọn" . 0,

"bắt buộc trục xuất - số trang đã chọn không thể bị trục xuất" . 0,

"buộc phải trục xuất - các trang đã chọn không thể bị trục xuất trong thời gian" . 0,

"buộc trục xuất - phiên trả lại lỗi khôi phục trong khi buộc trục xuất do cũ nhất" . 0,

"con trỏ nguy hiểm trục xuất trang bị chặn" . 0,

"cuộc gọi kiểm tra con trỏ nguy hiểm" . 902,

"mục kiểm tra con trỏ nguy hiểm đã đi" . 25,

"độ dài mảng tối đa của con trỏ nguy hiểm" . 1,

"lịch sử lưu trữ các cuộc gọi rút ngắn khóa trả về khởi động lại" . 0,

"lịch sử lưu trữ khóa bị cắt do dấu thời gian hỗn hợp" . 0,

"lịch sử lưu trữ khóa bị cắt do khóa bị xóa khỏi trang dữ liệu" . 0,

"điểm lưu trữ lịch sử" . 0,

"các cuộc gọi chèn bảng lưu trữ lịch sử" . 0,

"các cuộc gọi chèn bảng lưu trữ lịch sử đã trả về khởi động lại" . 0,

"kích thước tối đa của bảng lưu trữ lịch sử trên đĩa" . 0,

"kích thước bảng lưu trữ lịch sử trên đĩa" . 0,

"bảng lưu trữ lịch sử đã giải quyết các bản cập nhật không theo thứ tự làm mất dấu thời gian bền" . 0,

"bản cập nhật không theo thứ tự của bảng lưu trữ lịch sử đã được khắc phục bằng cách di chuyển các bản ghi hiện có" . 0,

"bản cập nhật không theo thứ tự của bảng lưu trữ lịch sử đã được sửa trong quá trình chèn" . 0,

"lịch sử đọc bảng lưu trữ" . 0,

"các lần đọc bảng lưu trữ lịch sử bị bỏ sót" . 0,

"các lần đọc bảng lưu trữ lịch sử yêu cầu sửa đổi bị nén" . 0,

"bảng lưu trữ lịch sử xóa cuộc gọi do cắt ngắn khóa" . 0,

"bảng lưu trữ lịch sử ghi yêu cầu sửa đổi bị nén" . 0,

"trang trong bộ nhớ đã vượt qua tiêu chí để được chia" . 0,

"tách trang trong bộ nhớ" . 0,

"các trang nội bộ đã bị xóa" . 0,

"các trang nội bộ được xếp hàng để xóa" . 0,

"các trang nội bộ được nhìn thấy khi trục xuất" . 0,

"các trang nội bộ được nhìn thấy bởi lối đi trục xuất đã được xếp hàng đợi" . 0,

"các trang nội bộ bị tách ra trong quá trình trục xuất" . 0,

"các trang lá bị tách ra trong quá trình trục xuất" . 0,

"số byte tối đa được định cấu hình" . 8053063680,

"kích thước trang tối đa khi trục xuất" . 376,

"các trang đã sửa đổi bị xóa" . 902,

"các trang đã sửa đổi bị chuỗi ứng dụng gỡ bỏ" . 0,

"thao tác đã hết thời gian chờ dung lượng trong bộ đệm" . 0,

"tràn trang đã đọc vào bộ đệm" . 0,

"việc tách trang trong quá trình trục xuất đã đào sâu cây" . 0,

"trang viết yêu cầu bản ghi lưu trữ lịch sử" . 0,

"các trang hiện được giữ trong bộ đệm" . 24,

"các trang bị chuỗi ứng dụng gỡ bỏ" . 0,

"các trang được xếp hàng để trục xuất" . 0,

"các trang được xếp hàng để sắp xếp lru bài đăng trục xuất" . 0,

"các trang đang xếp hàng chờ trục xuất khẩn cấp" . 902,

"các trang được xếp hàng chờ xóa khẩn cấp trong khi đi bộ" . 0,

"các trang được đọc vào bộ đệm" . 20,

"các trang được đọc vào bộ đệm sau khi cắt bớt" . 902,

"các trang được đọc vào bộ đệm sau khi cắt bớt ở trạng thái chuẩn bị" . 0,

"các trang được yêu cầu từ bộ đệm" . 33134,

"các trang được nhìn thấy khi đi bộ trục xuất" . 0,

"các trang được nhìn thấy bởi lối đi trục xuất đã được xếp hàng đợi" . 0,

"các trang được chọn để trục xuất không thể bị trục xuất" . 0,

"Các trang được chọn để xóa không thể bị xóa vì trang mẹ có các mục tràn" . 0,

"Các trang được chọn để xóa không thể bị xóa do trang con đang hoạt động trên trang nội bộ" . 0,

"Các trang được chọn để trục xuất không thể bị trục xuất do không thể đối chiếu" . 0,

"các trang bị trục xuất" . 0,

"các trang được ghi từ bộ đệm" . 1822,

"các trang được viết yêu cầu khôi phục trong bộ nhớ" . 0,

"chi phí phần trăm" . 8,

"các byte được theo dõi thuộc về các trang nội bộ trong bộ đệm" . 5136,

"các byte được theo dõi thuộc về các trang lá trong bộ đệm" . 67908,

"các byte bẩn được theo dõi trong bộ đệm" . 493,

"các trang bẩn được theo dõi trong bộ đệm" . 1,

"các trang chưa sửa đổi đã bị xóa" . 0

}

 

Có rất nhiều dữ liệu ở đây về bộ đệm của WiredTiger, nhưng chúng ta có thể tập trung vào các trường sau

  • Đây là kích thước bộ đệm tối đa hiện tại
  • – Đây là kích thước của dữ liệu hiện có trong bộ đệm. Đây thường là 80% kích thước bộ đệm của bạn cộng với lượng bộ đệm "bẩn" chưa được ghi vào đĩa. Giá trị này không được lớn hơn số byte tối đa được định cấu hình. Có giá trị bằng hoặc lớn hơn số byte tối đa được định cấu hình là một chỉ báo tuyệt vời mà bạn nên thu nhỏ lại
  • – Đây là kích thước của dữ liệu bẩn trong bộ đệm. Con số này phải nhỏ hơn năm phần trăm giá trị kích thước bộ đệm của bạn và có thể là một chỉ báo khác mà chúng tôi cần mở rộng quy mô. Khi điều này vượt quá năm phần trăm giá trị kích thước bộ đệm của bạn, WiredTiger sẽ tích cực hơn trong việc xóa dữ liệu khỏi bộ đệm của bạn và trong một số trường hợp có thể buộc ứng dụng khách của bạn xóa dữ liệu khỏi bộ đệm trước khi có thể ghi thành công vào bộ đệm
  • – Đây là số trang được đọc vào bộ đệm và bạn có thể sử dụng số này để đánh giá mức trung bình mỗi giây của nó để biết dữ liệu nào đang được đưa vào bộ đệm của bạn
  • – Đây là số trang được ghi từ bộ đệm vào đĩa. Điều này sẽ đặc biệt nghiêm trọng trước khi xảy ra. Nếu giá trị này tiếp tục tăng, thì điểm kiểm tra của bạn sẽ ngày càng dài hơn

    Nhìn vào các giá trị trên, chúng tôi có thể xác định xem chúng tôi có cần tăng kích thước của bộ đệm WiredTiger cho phiên bản của mình hay không. Chúng tôi cũng có thể xem xét việc sử dụng vé và đồng thời WiredTiger. Sẽ tốt thôi nếu một số vé được sử dụng, nhưng nếu số lượng tiếp tục tăng theo số lượng lõi thì bạn đang đạt đến mức bão hòa CPU của mình. Để kiểm tra vé của bạn đã sử dụng, bạn có thể xem điều này trong Công cụ quản lý và giám sát Percona (PMM) hoặc chạy truy vấn sau

     

    Vỏ bọc

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    db. serverStatus(). có dâyTiger. giao dịch đồng thời

    {

    "ghi" . {

    "ra" . 0,

    "sẵn hàng" . 128,

    "totalTickets" . 128

    },

    "đọc" . {

    "ra" . 1,

    "sẵn hàng" . 127,

    "totalTickets" . 128

    }

    }

     

    Giá trị này cũng có thể là dấu hiệu của sự cố đối với các ứng dụng đọc nhiều. Nếu giá trị này luôn chiếm một phần lớn trong kích thước bộ đệm của bạn, thì việc tăng bộ nhớ của bạn có thể cải thiện hiệu suất đọc tổng thể

    Thí dụ

    Sử dụng các số sau làm điểm bắt đầu ví dụ của chúng tôi, chúng tôi có thể thấy bộ đệm nhỏ và chắc chắn có áp lực bộ nhớ trên bộ đệm

    • = 8053063680 là 7. 5 GB
    • = 8053063680 là 7. 5 GB
    • = 4294967296 tức là khoảng 4 GB
    • = ~ 512 MB dữ liệu
    • =  ~ 1 GB dữ liệu và ngày càng tăng

    Chúng tôi cũng đang sử dụng kích thước bộ đệm ẩn wireTiger mặc định, vì vậy chúng tôi biết rằng chúng tôi có 16 GB bộ nhớ trên hệ thống (0. 5 * (16-1)) = 7. 5 GB. Dựa trên kiến ​​thức về ứng dụng (tưởng tượng) của chúng tôi, chúng tôi biết bộ làm việc là 16 GB, vì vậy chúng tôi muốn cao hơn con số này. Để tạo điều kiện cho chúng tôi phát triển thêm vì nhóm làm việc của chúng tôi sẽ chỉ tiếp tục phát triển, chúng tôi có thể thay đổi kích thước RAM của máy chủ từ 16 GB thành 48 GB. Nếu chúng tôi sử dụng các cài đặt mặc định, điều này sẽ tăng bộ đệm WiredTiger của chúng tôi lên 23. 5 GB. (0. 5 * (48-1)) = 23. 5 GB. Điều này sẽ để lại 24. 5 GB RAM cho HĐH và bộ đệm hệ thống tệp của nó. Nếu chúng tôi muốn tăng kích thước được cung cấp cho bộ đệm WiredTiger, chúng tôi sẽ đặt thành giá trị mà chúng tôi muốn. Ví dụ: giả sử chúng tôi muốn phân bổ 30 GB cho bộ đệm có dâyTiger để thực sự tránh bất kỳ lần đọc nào từ đĩa trong thời gian tới, để lại 18 GB cho HĐH và bộ đệm hệ thống tệp của nó. Chúng tôi sẽ thêm phần sau vào mongod của chúng tôi. tập tin conf

    Vỏ bọc

    1

    2

    3

    4

    bộ nhớ.

        wiredTiger.

            engineConfig.

                cacheSizeGB. 30

    Để cài đặt mặc định hoặc cài đặt cụ thể nhận ra bộ nhớ đã thêm và có hiệu lực, chúng tôi sẽ cần khởi động lại quy trình mongod

    Cũng lưu ý rằng không giống như nhiều hệ thống cơ sở dữ liệu khác, nơi bộ đệm cơ sở dữ liệu thường có kích thước gần bằng 80-90% bộ nhớ hệ thống, điểm hấp dẫn của MongoDB nằm trong khoảng 50-70%. Điều này là do MongoDB chỉ sử dụng bộ đệm WiredTiger cho các trang không nén, trong khi hệ điều hành lưu trữ các trang đã nén và ghi chúng vào các tệp cơ sở dữ liệu. Bằng cách để lại bộ nhớ trống cho hệ điều hành, chúng tôi tăng khả năng nhận được trang từ bộ đệm của hệ điều hành thay vì cần đọc đĩa

    Bản tóm tắt

    Trong bài viết này, chúng tôi đã giới thiệu cách cập nhật cấu hình MongoDB của bạn sau khi bạn đã nâng cấp lên nhiều bộ nhớ hơn. Chúng tôi hy vọng rằng điều này sẽ giúp bạn điều chỉnh cấu hình MongoDB của mình để bạn có thể tận dụng tối đa RAM tăng lên của mình. Cảm ơn vì đã đọc

    MongoDB đang sử dụng bao nhiêu bộ nhớ?

    Và theo mặc định, MongoDB sẽ dự trữ 50% bộ nhớ khả dụng – 1 GB cho bộ đệm WiredTiger hoặc 256 MB, tùy theo giá trị nào lớn hơn . Ví dụ: một hệ thống có 16 GB RAM, sẽ có kích thước bộ đệm WiredTiger là 7. 5 GB.

    Làm cách nào để kiểm tra việc sử dụng bộ nhớ MongoDB trong Linux?

    Chúng ta có thể kiểm tra việc sử dụng bộ nhớ của máy chủ cơ sở dữ liệu MongoDB bằng cách sử dụng lệnh free –m . Lệnh này sẽ hiển thị tổng bộ nhớ, bộ nhớ đã sử dụng, bộ nhớ khả dụng, bộ đệm và bộ nhớ dùng chung. Ví dụ dưới đây cho thấy việc kiểm tra mức sử dụng bộ nhớ trong MongoDB.