Làm cách nào để cấu hình MongoDB Java driver MongoOptions để sử dụng trong sản xuất?


100

Tôi đã tìm kiếm trên web để tìm kiếm các phương pháp hay nhất để định cấu hình MongoOptions cho trình điều khiển Java MongoDB và tôi chưa tìm ra nhiều thứ khác ngoài API. Tìm kiếm này bắt đầu sau khi tôi gặp lỗi "com.mongodb.DBPortPool $ SemaphoresOut: Hết semaphores để nhận kết nối db" và bằng cách tăng kết nối / hệ số, tôi đã có thể giải quyết vấn đề đó. Tôi đang tìm kiếm các liên kết đến hoặc các phương pháp hay nhất của bạn trong việc định cấu hình các tùy chọn này cho quá trình sản xuất.

Các tùy chọn cho trình điều khiển 2.4 bao gồm: http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html

  • autoConnectRetry
  • kết nốiPerHost
  • connectTimeout
  • maxWaitTime
  • socketTimeout
  • threadAllowedToBlockForConnectionMultiplier

Các trình điều khiển mới hơn có nhiều lựa chọn hơn và tôi cũng muốn nghe về những lựa chọn đó.

Câu trả lời:


160

Cập nhật lên 2.9:

  • autoConnectRetry đơn giản có nghĩa là trình điều khiển sẽ tự động cố gắng kết nối lại với (các) máy chủ sau khi ngắt kết nối không mong muốn. Trong môi trường sản xuất, bạn thường muốn đặt giá trị này thành true.

  • Kết nốiPerHost là số lượng kết nối vật lý mà một cá thể Mongo đơn lẻ (nó là singleton nên bạn thường có một kết nối cho mỗi ứng dụng) có thể thiết lập cho một quy trình mongod / mongos. Tại thời điểm viết, trình điều khiển java sẽ thiết lập số lượng kết nối này cuối cùng ngay cả khi thông lượng truy vấn thực tế thấp (theo thứ tự từ bạn sẽ thấy thống kê "conn" trong mongostat tăng lên cho đến khi đạt đến con số này trên mỗi máy chủ ứng dụng).

    Không cần thiết đặt giá trị này cao hơn 100 trong hầu hết các trường hợp nhưng cài đặt này là một trong những thứ "thử nghiệm và xem". Lưu ý rằng bạn sẽ phải đảm bảo rằng bạn đặt mức này đủ thấp để tổng số kết nối đến máy chủ của bạn không vượt quá

    db.serverStatus().connections.available

    Trong quá trình sản xuất, chúng tôi hiện có con số này ở mức 40.

  • connectTimeout . Như tên gợi ý số mili giây trình điều khiển sẽ đợi trước khi nỗ lực kết nối bị hủy bỏ. Đặt thời gian chờ thành một cái gì đó dài (15-30 giây) trừ khi có một cơ hội thực tế, dự kiến, điều này sẽ cản trở các nỗ lực kết nối thành công. Thông thường, nếu một nỗ lực kết nối mất hơn vài giây thì cơ sở hạ tầng mạng của bạn không có khả năng đạt được thông lượng cao.

  • maxWaitTime . Số mili giây một luồng sẽ đợi kết nối khả dụng trên nhóm kết nối và đặt ra một ngoại lệ nếu điều này không xảy ra kịp thời. Giữ mặc định.

  • socketTimeout . Giá trị thời gian chờ của ổ cắm tiêu chuẩn. Đặt thành 60 giây (60000).

  • threadAllowedToBlockForConnectionMultiplier . Hệ số nhân cho các kết nốiPerHost biểu thị số luồng được phép đợi kết nối khả dụng nếu nhóm hiện đang cạn kiệt. Đây là cài đặt sẽ gây ra ngoại lệ "com.mongodb.DBPortPool $ SemaphoresOut: Out of semaphores để có được kết nối db". Nó sẽ ném ngoại lệ này khi hàng đợi luồng này vượt quá giá trị threadAllowedToBlockForConnectionMultiplier. Ví dụ: nếu các kết nốiPerHost là 10 và giá trị này là 5 thì tối đa 50 luồng có thể chặn trước khi ngoại lệ nói trên được ném ra.

    Nếu bạn mong đợi thông lượng đạt đỉnh lớn có thể khiến hàng đợi lớn tạm thời làm tăng giá trị này. Chúng tôi có nó lúc 1500 vào lúc này vì lý do chính xác. Nếu tải truy vấn của bạn thường xuyên vượt quá máy chủ, bạn chỉ nên cải thiện tình hình phần cứng / tỷ lệ của mình cho phù hợp.

  • readPreference . (UPDATED, 2.8+) Được sử dụng để xác định tùy chọn đọc mặc định và thay thế "slaveOk". Thiết lập một ReadPreference thông qua một trong các phương thức nhà máy của lớp. Mô tả đầy đủ về các cài đặt phổ biến nhất có thể được tìm thấy ở cuối bài đăng này

  • w . (UPDATED, 2.6+) Giá trị này xác định độ "an toàn" của việc ghi. Khi giá trị này là -1, việc ghi sẽ không báo cáo bất kỳ lỗi nào bất kể lỗi mạng hoặc cơ sở dữ liệu. WriteConcern.NONE là WriteConcern được xác định trước thích hợp cho việc này. Nếu w là 0 thì lỗi mạng sẽ làm cho việc ghi không thành công nhưng lỗi mongo thì không. Điều này thường được gọi là ghi "cháy và quên" và nên được sử dụng khi hiệu suất quan trọng hơn tính nhất quán và độ bền. Sử dụng WriteConcern.NORMAL cho chế độ này.

    Nếu bạn đặt w thành 1 hoặc cao hơn, việc ghi được coi là an toàn. Ghi an toàn thực hiện việc ghi và theo dõi nó bằng một yêu cầu tới máy chủ để đảm bảo việc ghi thành công hoặc truy xuất giá trị lỗi nếu không (nói cách khác, nó sẽ gửi một lệnh getLastError () sau khi bạn viết). Lưu ý rằng cho đến khi lệnh getLastError () này hoàn thành, kết nối sẽ được bảo lưu. Do đó và lệnh bổ sung thông lượng sẽ thấp hơn đáng kể so với ghi với w <= 0. Với giá trị aw của chính xác 1 MongoDB đảm bảo việc ghi thành công (hoặc không thể xác minh được) trên trường hợp bạn đã gửi ghi.

    Trong trường hợp tập hợp bản sao, bạn có thể sử dụng các giá trị cao hơn cho w whcih yêu cầu MongoDB gửi bản ghi cho ít nhất thành viên "w" của tập hợp bản sao trước khi trả lại (hoặc chính xác hơn, hãy đợi bản sao của bản ghi của bạn tới thành viên "w" ). Bạn cũng có thể đặt w thành chuỗi "đa số" yêu cầu MongoDB thực hiện việc ghi vào phần lớn các thành viên của nhóm bản sao (WriteConcern.MAJORITY). Đánh máy, bạn nên đặt giá trị này thành 1 trừ khi bạn cần hiệu suất thô (-1 hoặc 0) hoặc ghi sao chép (> 1). Giá trị cao hơn 1 có tác động đáng kể đến thông lượng ghi.

  • fsync . Tùy chọn độ bền buộc mongo chuyển sang đĩa sau mỗi lần ghi khi được bật. Tôi chưa bao giờ gặp bất kỳ vấn đề về độ bền nào liên quan đến việc ghi tồn đọng vì vậy chúng tôi có điều này trên false (mặc định) trong sản xuất.

  • j * (MỚI 2.7+) *. Boolean rằng khi được đặt thành true buộc MongoDB phải đợi một cam kết nhóm ghi nhật ký thành công trước khi quay trở lại. Nếu bạn đã bật tính năng ghi nhật ký, bạn có thể bật tính năng này để tăng độ bền. Tham khảo http://www.mongodb.org/display/DOCS/Journaling để xem việc viết nhật ký mang lại cho bạn điều gì (và do đó, tại sao bạn có thể muốn bật cờ này).

ReadPreference Lớp ReadPreference cho phép bạn định cấu hình các truy vấn phiên bản mongod nào được định tuyến nếu bạn đang làm việc với các bộ bản sao. Lựa chọn tiếp theo đã khả thi :

  • ReadPreference.primary () : Tất cả các lần đọc chỉ được chuyển đến thành viên chính được thiết lập lại. Sử dụng điều này nếu bạn yêu cầu tất cả các truy vấn trả về dữ liệu nhất quán (được viết gần đây nhất). Đây là mặc định.

  • ReadPreference.primaryPreferred () : Tất cả các lần đọc sẽ được chuyển đến thành viên chính repset nếu có thể nhưng có thể truy vấn các thành viên thứ cấp nếu nút chính không khả dụng. Như vậy nếu tài liệu chính trở nên không khả dụng thì các lần đọc cuối cùng sẽ trở nên nhất quán, nhưng chỉ khi tài liệu chính không khả dụng.

  • ReadPreference.secondary () : Tất cả các lần đọc được chuyển đến thành viên repset thứ cấp và thành viên chính chỉ được sử dụng để ghi. Chỉ sử dụng điều này nếu bạn có thể sống với những lần đọc cuối cùng nhất quán. Các thành viên repset bổ sung có thể được sử dụng để mở rộng hiệu suất đọc mặc dù có những giới hạn về số lượng thành viên (bỏ phiếu) mà một repet có thể có.

  • ReadPreference.secondaryPreferred () : Tất cả các lần đọc sẽ được chuyển đến các thành viên repset phụ nếu có. Thành viên chính chỉ được sử dụng để viết trừ khi tất cả các thành viên phụ không còn nữa. Ngoài dự phòng cho thành viên chính để đọc, nó giống với ReadPreference.secondary ().

  • ReadPreference.nethers () : Các số đọc chuyển đến thành viên repset gần nhất có sẵn cho máy khách cơ sở dữ liệu. Chỉ sử dụng nếu những lần đọc nhất quán cuối cùng được chấp nhận. Thành viên gần nhất là thành viên có độ trễ thấp nhất giữa khách hàng và các thành viên repset khác nhau. Kể từ khi các thành viên bận rộn cuối cùng sẽ có độ trễ cao này nên cũng tự động cân bằng tải đọc mặc dù kinh nghiệm của tôi thứ cấp (ưu tiên) dường như làm như vậy tốt hơn nếu độ trễ thành viên là tương đối phù hợp.

Lưu ý: Tất cả những điều trên đều có các phiên bản hỗ trợ thẻ của cùng một phương pháp, thay vào đó trả về các phiên bản TaggableReadPreference. Một mô tả đầy đủ các bản sao thiết lập thẻ có thể được tìm thấy ở đây: Replica Set Thẻ


6
Có nguy hiểm không khi để socketTimeout và connectTimeout làm mặc định (vô hạn)? Nếu kết nối bị treo vì một lý do nào đó, ứng dụng của bạn (hoặc ít nhất là chuỗi đó) sẽ bị kẹt vĩnh viễn. Không nên đặt những thứ này là rất cao (chẳng hạn như 30 giây cho kết nối, 2 phút cho ổ cắm)?
Idris Mokhtarzada

Idris, rất đúng. Trong bài đăng của mình, tôi đã nhầm tưởng rằng MongoOptions có các giá trị mặc định của chúng tôi. Lớp Mongo ORM của chúng tôi có các giá trị này lần lượt là 15 giây và 1 phút và trong khi viết, tôi cho rằng đây là các giá trị mặc định. Thời gian chờ vô hạn chắc chắn là một ý tưởng tồi. Cảm ơn Thủ trưởng lên, tôi cố định nó trong bài
REMON van Vliet

tùy chọn "slaveOk" hiện không được dùng nữa, nếu bạn muốn tùy chọn tương đương là true, hãy thực hiện: mongoOptions.readPreference = ReadPreference.secondaryPreferred ();
Gubatron

Câu trả lời hay nhưng định nghĩa của bạn về threadAllowedToBlockForConnectionMultiplier (hệ số từ khóa) là sai. Theo tài liệu: "số nhân cho các kết nốiPerHost cho số luồng có thể chặn nếu các kết nốiPerHost là 10 và các chủ đềAllowedToBlockForConnectionMultiplier là 5, thì 50 chủ đề có thể chặn nhiều hơn thế và một ngoại lệ sẽ được ném ra"
Tyler Zale

3
Có vẻ là một câu trả lời khá phổ biến. Nếu bất kỳ ai quan tâm đến tôi cập nhật này để phản ánh những thay đổi trong trình điều khiển mới nhất cho tôi biết
REMON van Vliet
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.