MongoDB chậm lại sau mỗi 2 giờ và 10 phút chính xác

Question

Trong 3 tháng qua, máy chủ MongoDB của tôi nhận được rất chậm mỗi 2 giờ và 10 phút, rất chính xác.

cấu hình My Server:

• 3 bản sao bộ, và với mục đích sao lưu dữ liệu, 1 trong số đó có 3600 giây chậm trễ.
• Không có máy chủ nô lệ nào cho 3 chủ nhân trong bộ bản sao.
• Sử dụng mongoose + node.js để cung cấp api còn lại.
• Khoảng 9 lần đọc và 1,5 ghi mỗi giây trung bình trong dữ liệu thống kê 24 giờ.

Những gì tôi đã làm sau khi tìm kiếm stackoverflow và google:

• Khởi động lại máy chủ không thể thay đổi khoảng thời gian chậm 2 giờ và 10 phút
• Tạo chỉ số cho tất cả các lĩnh vực tôi truy vấn, không có tác động
• Xóa tệp dữ liệu trong một máy chủ và sử dụng một tệp khác để khôi phục, sau đó xóa anohter và khôi phục lại, không ảnh hưởng
• Thay đổi máy chủ chính, không tác động
• Chạy 'currentOps' khi cơ sở dữ liệu bị chậm, tôi có thể thấy nhiều truy vấn treo ở đó, quá nhiều nhật ký để dán ở đây, nhưng không thấy một số truy vấn bất thường.
• Trong giao diện điều khiển mongo, hãy kiểm tra "serverStatus" khi cơ sở dữ liệu bị chậm, lệnh chờ cho đến khi cơ sở dữ liệu được khôi phục.
• Không tăng mức sử dụng bộ nhớ từ lệnh "trên cùng" khi cơ sở dữ liệu chậm.
• phần còn lại mà không truy cập cơ sở dữ liệu hoạt động tốt.

Tôi đoán có thể có khóa nào đó, nguyên nhân tiềm năng nhất là nó có thể là chỉ mục xây dựng. Có điều gì đó đặc biệt trong cơ sở dữ liệu của tôi:

• Tôi có khoảng 14000 bộ sưu tập trong một cơ sở dữ liệu và đang tăng lên. Có thể có từ 1 đến 3000 hồ sơ trong một bộ sưu tập.
• Cả số bộ sưu tập và bản ghi số đang tăng tự động.
• Các trường chỉ mục sẽ được chỉ định khi tạo bộ sưu tập mới.

Tôi đã bị ám ảnh bởi vấn đề này trong 3 tháng. Bất kỳ ý kiến ​​/ đề xuất sẽ được đánh giá cao!

Dưới đây là một số bản ghi từ tập tin đăng nhập của tôi:

Fri 05 Tháng Bảy 15:20:11.040 [conn2765] serverStatus rất chậm: {sau basic: 0, sau khi xác nhận: 0, sau khi backgroundFlushing: 0, sau khi kết nối: 0, sau con trỏ: 0, sau dur: 0, sau extra_info: 0, sau globalLock: 0, sau indexCounters: 0, sau khi khóa: 0, sau mạng: 0, sau opcounters: 0, sau opcountersRepl: 0, sau recordStats: 222694, sau repl: 222694, ở cuối: 222694}

Fri Jul 5 17: 30:09 .367 [conn4711] serverStatus rất chậm: {sau cơ bản: 0, sau khi xác nhận: 0, sau khi backgroundFlushing: 0, sau khi kết nối: 0, sau con trỏ: 0, sau dur: 0, sau extra_info: 0, sau globalLock: 0, sau indexCounters: 0, sau khóa: 0, sau mạng: 0, sau khi opcounters: 0, sau opcountersRepl: 0, sau recordStats: 199498, sau repl: 199498, ở cuối: 199528}

Fri Jul 5 19:40:12 .697 [conn6488] serverStatus rất chậm: {sau cơ bản: 0, sau khi xác nhận: 0, sau khi backgroundFlushing: 0, sau khi kết nối: 0, sau con trỏ: 0, sau dur: 0, sau khi extra_info: 0, sau globalLock: 0, sau indexCounters: 0, sau khóa: 0, sau mạng: 0, sau khi opcounters: 0, sau opcountersRepl: 0, sau recordStats: 204061, sau repl: 204061, tại kết thúc: 204081}

Đây là ảnh chụp màn hình báo cáo pingdom của tôi, máy chủ giảm 4 phút sau 2 giờ và 7 phút. Ban đầu, máy chủ giảm 2 phút sau mỗi 2 giờ và 6 phút.

[EDIT 1] Xem thêm màn hình kết quả từ nhà cung cấp máy chủ: CPU http://i.minus.com/iZBNyMPzLSLRr.png DiskIO http://i.minus.com/ivgrHr0Ghoz92.png Connections http://i.minus.com/itbfYq0SSMlNs.png Các kết nối tăng kỳ là bởi vì các kết nối đang chờ đợi, và đếm cho kết nối hiện tại sẽ tích lũy cho đến khi cơ sở dữ liệu được bỏ chặn. Điều này không phải vì lưu lượng truy cập lớn.

Answer 1

Tôi nghĩ bạn có nghĩa là một bản sao có 3 nút thay vì "3 bản sao được đặt".

Nếu bạn vẫn gặp sự cố tương tự. Đây là ý kiến ​​của tôi:

1. Vì bạn đang chạy máy chủ của mình trong linode.com. Máy chủ của bạn thực sự là một máy ảo và bạn đang chia sẻ tài nguyên với người khác. Việc làm chậm định kỳ có thể do những người khác đang chạy đĩa định kỳ. Vì bạn đã xem xét rất nhiều khả năng khác nhau, nên đây có thể là một lựa chọn cho bạn ngay cả khi bạn cần một chút nỗ lực.

2. Điều này chắc chắn là do công việc do mongodb hoặc hệ thống của bạn chạy. Hãy cố gắng tìm kiếm bất kỳ công việc nào chạy thường xuyên. Ví dụ: hãy thử xóa độ trễ 3600 giây trên một trong số phụ của bạn. Thậm chí đó không phải là 2 giờ và 10 phút, nhưng đó có thể là một kích hoạt của nó.

Tôi không thể đăng đề xuất của mình trong nhận xét vì nó không cho phép tôi. Vì vậy, tôi đăng bài này như một câu trả lời.

Answer 2

Tôi đã gặp sự cố tương tự. Tôi bắt đầu với mongostat/mongotop và làm việc theo cách của bạn từ đó. Xác định khối lượng công việc chiếm ưu thế với mongostat và sau đó tìm ra bộ sưu tập nào đang gây ra hoạt động đó.

Đối với trường hợp cụ thể của tôi, tôi có một công việc định kỳ xóa các bản ghi lỗi thời. Nó chỉ ra rằng cách các bản sao thiết lập tuyên truyền các lệnh này là cực kỳ tài nguyên chuyên sâu.Ví dụ, tôi sẽ xóa các bản ghi 3m từ một bộ sưu tập, điều đó xảy ra trên bộ bản sao chính. Đối với một số lý do, tuyên truyền này làm cho tất cả các người thứ hai làm việc mạnh mẽ trong việc tuyên truyền tiếp theo.

Nếu bạn có thể thấy mọi thứ trong db.currentOp, tôi sẽ tập trung vào những thứ có thời gian chạy dài và cố gắng xác định nguyên nhân gốc rễ bằng cách loại bỏ khỏi đó.

Hy vọng điều đó sẽ hữu ích.

Answer 3

Chúng tôi đã tìm thấy một vấn đề cụ thể trong 2:10. Trong trường hợp của chúng tôi, nó đã được thực hiện dbStats qua MMS. Chúng tôi phải nâng cấp nhân vật và vấn đề đã được giải quyết.