Khi đang trong quá trình sản xuất, ứng dụng phải cung cấp phản hồi kịp thời cho người dùng nhằm mục đích cải thiện sự tương tác của người dùng với ứng dụng của bạn. Tuy nhiên, đôi khi, các truy vấn cơ sở dữ liệu có thể bắt đầu bị trễ do đó mất thời gian chờ lâu hơn để phản hồi đến được với người dùng hoặc đúng hơn là hoạt động thông lượng bị chấm dứt do vượt quá thời gian chờ trung bình đã đặt.
Trong blog này, chúng ta sẽ tìm hiểu cách bạn có thể xác định những vấn đề này trong MongoDB, cách khắc phục chúng bất cứ khi nào chúng phát sinh và những chiến lược có thể thực hiện để điều này có thể không xảy ra lần nữa.
Thông thường, điều dẫn đến phản hồi truy vấn chậm là dung lượng CPU bị suy giảm không thể chịu được bộ hoạt động cơ bản. Tập hợp làm việc trong trường hợp này là lượng dữ liệu và chỉ mục sẽ phải chịu một phiên bản thông lượng do đó hoạt động tại thời điểm đó. Điều này đặc biệt được xem xét trong việc lập kế hoạch dung lượng khi người ta mong đợi lượng dữ liệu liên quan sẽ tăng lên theo thời gian và số lượng người dùng tương tác với nền tảng của bạn.
Xác định Vấn đề Truy vấn Chậm
Có hai cách bạn có thể xác định các truy vấn chậm trong MongoDB.
- Sử dụng Trình giới thiệu
- Sử dụng trình trợ giúp db.currentOp ()
Sử dụng Hồ sơ MongoDB
Trình biên dịch cơ sở dữ liệu trong MongoDB là cơ chế thu thập thông tin chi tiết về các Lệnh cơ sở dữ liệu được thực thi dựa trên phiên bản mongod đang chạy, đó là:các hoạt động thông lượng (Tạo, Đọc, Cập nhật và Xóa) và các lệnh cấu hình &quản trị.
Hồ sơ sử dụng một tập hợp có giới hạn tên là system.profile nơi nó ghi tất cả dữ liệu. Điều này có nghĩa là, khi bộ sưu tập đầy đủ về kích thước, các tài liệu cũ hơn sẽ bị xóa để nhường chỗ cho dữ liệu mới.
Profiler bị tắt theo mặc định nhưng tùy thuộc vào cấp độ cấu hình mà người ta có thể bật nó trên mỗi cơ sở dữ liệu hoặc mỗi phiên bản. Các mức cấu hình có thể có là:
- 0 - trình biên dịch bị tắt do đó không thu thập được bất kỳ dữ liệu nào.
- 1 - trình biên dịch thu thập dữ liệu cho các hoạt động mất nhiều thời gian hơn giá trị của slowms
- 2- trình biên dịch thu thập dữ liệu cho tất cả các hoạt động.
Tuy nhiên, việc bật cấu hình sẽ tạo ra tác động về hiệu suất trên cơ sở dữ liệu và việc sử dụng đĩa, đặc biệt khi mức cấu hình được đặt thành 2. Người ta nên xem xét bất kỳ tác động nào về hiệu suất trước khi bật và định cấu hình trình biên dịch khi triển khai sản xuất.
Để thiết lập cấu hình, chúng tôi sử dụng trình trợ giúp db.setProfilingLevel () như:
db.setProfilingLevel(2)Một tài liệu mẫu sẽ được lưu trữ trong bộ sưu tập system.profile sẽ là:
{ "was" : 0, "slowms" : 100, "sampleRate" : 1.0, "ok" : 1 }Cặp khóa-giá trị “ok”:1 cho biết rằng thao tác đã thành công trong khi tốc độ chậm là thời gian ngưỡng tính bằng mili giây mà một thao tác phải thực hiện và theo mặc định là 100 mili giây.
Để thay đổi giá trị này
db.setProfilingLevel(1, { slowms: 50 })Để truy vấn dữ liệu đối với bộ sưu tập system.profile, hãy chạy:
db.system.profile.find().pretty()Sử dụng trình trợ giúp db.currentOp ()
Hàm này liệt kê các truy vấn đang chạy hiện tại với thông tin rất chi tiết như chúng đã chạy trong bao lâu. Trên một trình bao mongo đang chạy, bạn chạy nhận xét, ví dụ:
db.currentOp ({“secs_running”:{$ gte:5}})
Trong đó secs_running là chiến lược lọc để chỉ các hoạt động mất hơn 5 giây để thực hiện mới được trả về, làm giảm kết quả đầu ra. Điều này thường được sử dụng khi sức khỏe của CPU có thể được xếp hạng 100% do tác động bất lợi về hiệu suất mà nó có thể liên quan đến cơ sở dữ liệu. Vì vậy, bằng cách thay đổi các giá trị, bạn sẽ biết được truy vấn nào mất nhiều thời gian để thực thi.
Các tài liệu được trả lại có những nội dung sau là chìa khóa quan tâm:
- truy vấn :truy vấn đòi hỏi gì
- hoạt động :Nếu truy vấn vẫn đang được xử lý.
- ns :tên bộ sưu tập mà truy vấn sẽ được thực thi
- secs_running :Thời lượng truy vấn tính đến thời điểm này tính bằng giây
Bằng cách đánh dấu những truy vấn nào mất nhiều thời gian, bạn đã xác định được điều gì đang làm quá tải CPU.
Diễn giải Kết quả và Khắc phục Sự cố
Như chúng tôi đã mô tả ở trên, độ trễ truy vấn phụ thuộc rất nhiều vào lượng dữ liệu liên quan, nếu không sẽ dẫn đến các kế hoạch thực thi không hiệu quả. Điều này có nghĩa là, ví dụ:nếu bạn không sử dụng các chỉ mục trong bộ sưu tập của mình và muốn cập nhật các bản ghi nhất định, thì thao tác phải xem xét tất cả các tài liệu thay vì chỉ lọc những tài liệu phù hợp với đặc tả truy vấn. Về mặt logic, điều này sẽ mất nhiều thời gian hơn, do đó dẫn đến truy vấn chậm. Bạn có thể kiểm tra một kế hoạch thực thi không hiệu quả bằng cách chạy:giải thích (‘executeStats’), cung cấp số liệu thống kê về hiệu suất của truy vấn. Từ điểm này, bạn có thể tìm hiểu cách truy vấn đang sử dụng chỉ mục bên cạnh việc cung cấp manh mối nếu chỉ mục là tối ưu.
Nếu trình trợ giúp giải thích trả về
{
"queryPlanner" : {
"plannerVersion" : 1,
...
"winningPlan" : {
"stage" : "COLLSCAN",
...
}
},
"executionStats" : {
"executionSuccess" : true,
"nReturned" : 3,
"executionTimeMillis" : 0,
"totalKeysExamined" : 0,
"totalDocsExamined" : 10,
"executionStages" : {
"stage" : "COLLSCAN",
...
},
...
},
...
}queryPlanner.winningPlan.stage:Giá trị khóa COLLSCAN chỉ ra rằng mongod phải quét toàn bộ tài liệu thu thập để xác định kết quả, do đó nó trở thành một hoạt động tốn kém do đó dẫn đến truy vấn chậm.
executeStats.totalKeysExamined:0 có nghĩa là bộ sưu tập không sử dụng chiến lược lập chỉ mục
Đối với một truy vấn nhất định, số lượng tài liệu liên quan phải gần bằng không. Nếu số lượng tài liệu khá lớn, có hai khả năng:
- Không sử dụng lập chỉ mục với bộ sưu tập
- Sử dụng chỉ mục không tối ưu.
Để tạo chỉ mục cho một tập hợp, hãy chạy lệnh:
db.collection.createIndex( { quantity: 1 } )Trong đó số lượng là trường mẫu bạn đã chọn để tối ưu cho chiến lược lập chỉ mục.
Nếu bạn muốn tìm hiểu thêm về lập chỉ mục và sử dụng chiến lược lập chỉ mục nào, hãy xem trên blog này
Kết luận
Sự suy giảm hiệu suất cơ sở dữ liệu có thể dễ dàng khắc họa bằng việc có các truy vấn chậm, đây là điều ít mong đợi nhất mà chúng tôi muốn người dùng nền tảng gặp phải. Người ta có thể xác định các truy vấn chậm trong MongoDB bằng cách bật hồ sơ và định cấu hình nó theo một số thông số kỹ thuật của nó hoặc thực thi db.currentOp () trên một cá thể mongod đang chạy.
Bằng cách xem các thông số thời gian trên kết quả trả về, chúng tôi có thể xác định truy vấn nào bị trễ. Sau khi xác định các truy vấn này, chúng tôi sử dụng trình trợ giúp giải thích về các truy vấn này để biết thêm chi tiết, chẳng hạn như nếu truy vấn đang sử dụng bất kỳ chỉ mục nào.
Nếu không lập chỉ mục, các thao tác sẽ trở nên tốn kém vì rất nhiều tài liệu cần được quét qua trước khi áp dụng các thay đổi. Với khoảng lùi này, CPU sẽ làm việc quá sức do đó dẫn đến truy vấn chậm và tăng đột biến CPU.
Sai lầm chính dẫn đến truy vấn chậm là lập kế hoạch thực thi không hiệu quả có thể dễ dàng giải quyết bằng cách sử dụng chỉ mục với bộ sưu tập liên quan.
