프로덕션 용도로 MongoDB Java 드라이버 MongoOptions를 구성하는 방법은 무엇입니까?


100

MongoDB Java 드라이버에 대해 MongoOptions를 구성하는 모범 사례를 찾기 위해 웹을 검색해 왔지만 API 외에는 많이 생각 해보지 못했습니다. 이 검색은 "com.mongodb.DBPortPool $ SemaphoresOut : Out of semaphores to get db connection"오류가 발생하고 연결 / 승수를 늘림으로써이 문제를 해결할 수 있었던 후에 시작되었습니다. 프로덕션을위한 이러한 옵션 구성에 대한 링크 또는 모범 사례를 찾고 있습니다.

2.4 드라이버에 대한 옵션은 다음과 같습니다. http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html

  • autoConnectRetry
  • connectionsPerHost
  • connectTimeout
  • maxWaitTime
  • socketTimeout
  • threadsAllowedToBlockForConnectionMultiplier

최신 운전자에게는 더 많은 옵션이 있으며 이에 대해 듣고 싶습니다.

답변:


160

2.9로 업데이트 :

  • autoConnectRetry 는 예상치 못한 연결이 끊어진 후 드라이버가 자동으로 서버에 다시 연결을 시도 함을 의미합니다. 프로덕션 환경에서는 일반적으로이 설정을 true로 설정합니다.

  • connectionsPerHost 는 단일 Mongo 인스턴스 (싱글 톤이므로 일반적으로 애플리케이션 당 하나씩 있음)가 mongod / mongos 프로세스에 설정할 수있는 물리적 연결의 양입니다. 작성 시점에 Java 드라이버는 실제 쿼리 처리량이 낮더라도 결국이 연결 수를 설정합니다 (순서 말하자면 앱 서버 당이 수에 도달 할 때까지 mongostat에서 "conn"통계가 증가 함을 볼 수 있습니다).

    대부분의 경우이 값을 100보다 높게 설정할 필요는 없지만이 설정은 "테스트 및 확인"항목 중 하나입니다. 서버에 대한 총 연결 수가 초과하지 않도록이 값을 충분히 낮게 설정해야합니다.

    db.serverStatus().connections.available

    프로덕션에서는 현재이 값이 40 개입니다.

  • connectTimeout . 이름에서 알 수 있듯이 연결 시도가 중단되기 전에 드라이버가 대기하는 시간 (밀리 초)입니다. 다른 방법으로 성공적인 연결 시도를 방해하는 현실적이고 예상되는 기회가없는 한 제한 시간을 길게 (15-30 초) 설정하십시오. 일반적으로 연결 시도가 몇 초 이상 걸리는 경우 네트워크 인프라는 높은 처리량을 제공 할 수 없습니다.

  • maxWaitTime . 스레드가 연결 풀에서 연결을 사용할 수있을 때까지 대기하는 시간 (밀리 초)이며, 이것이 제 시간에 발생하지 않으면 예외를 발생시킵니다. 기본값을 유지합니다.

  • socketTimeout . 표준 소켓 제한 시간 값. 60 초 (60000)로 설정합니다.

  • threadsAllowedToBlockForConnectionMultiplier . 풀이 현재 소진 된 경우 연결을 사용할 수있을 때까지 대기 할 수있는 스레드 수를 나타내는 connectionsPerHost의 승수입니다. 이것은 "com.mongodb.DBPortPool $ SemaphoresOut : db 연결을 얻기위한 세마포어 부족"예외를 유발하는 설정입니다. 이 스레드 큐가 threadsAllowedToBlockForConnectionMultiplier 값을 초과하면이 예외가 발생합니다. 예를 들어 connectionsPerHost가 10이고이 값이 5이면 앞서 언급 한 예외가 발생하기 전에 최대 50 개의 스레드를 차단할 수 있습니다.

    대용량 대기열을 유발할 수있는 처리량의 최대치가 예상되는 경우이 값을 일시적으로 늘리십시오. 정확히 그 이유 때문에 현재 1500에 있습니다. 쿼리 부하가 지속적으로 서버를 초과하는 경우 그에 따라 하드웨어 / 확장 상황을 개선해야합니다.

  • readPreference . (업데이트, 2.8+) 기본 읽기 기본 설정을 결정하는 데 사용되며 "slaveOk"를 대체합니다. 클래스 팩토리 메소드 중 하나를 통해 ReadPreference를 설정하십시오. 가장 일반적인 설정에 대한 전체 설명은이 게시물의 끝에서 찾을 수 있습니다.

  • w . (업데이트 됨, 2.6+) 이 값은 쓰기의 "안전성"을 결정합니다. 이 값이 -1이면 쓰기는 네트워크 또는 데이터베이스 오류에 관계없이 오류를보고하지 않습니다. WriteConcern.NONE은 이에 대해 사전 정의 된 적절한 WriteConcern입니다. w가 0이면 네트워크 오류로 인해 쓰기가 실패하지만 mongo 오류는 그렇지 않습니다. 이는 일반적으로 "실행 후 삭제"쓰기라고하며 일관성과 내구성보다 성능이 더 중요한 경우에 사용해야합니다. 이 모드에는 WriteConcern.NORMAL을 사용하십시오.

    w를 1 이상으로 설정하면 쓰기가 안전한 것으로 간주됩니다. 안전한 쓰기는 쓰기를 수행하고 서버에 대한 요청에 따라 쓰기가 성공했는지 확인하거나 실패한 경우 오류 값을 검색합니다 (즉, 쓰기 후에 getLastError () 명령을 보냅니다). 이 getLastError () 명령이 완료 될 때까지 연결이 예약됩니다. 그 결과 및 추가 명령의 결과로 처리량은 w <= 0 인 쓰기보다 현저히 낮습니다. aw 값이 정확히 1 인 MongoDB는 쓰기를 보낸 인스턴스에서 쓰기 성공 (또는 검증 가능)을 보장합니다.

    복제본 세트의 경우 MongoDB에 반환하기 전에 복제본 세트의 최소 "w"구성원에게 쓰기를 보내도록 지시하는 데 더 높은 값을 사용할 수 있습니다 (또는 더 정확하게는 "w"구성원에 대한 쓰기 복제를 기다립니다. ). w를 "majority"문자열로 설정하여 MongoDB가 대부분의 복제본 세트 멤버 (WriteConcern.MAJORITY)에 쓰기를 수행하도록 지시 할 수도 있습니다. 일반적으로 원시 성능 (-1 또는 0) 또는 복제 된 쓰기 (> 1)가 필요하지 않은 경우이 값을 1로 설정해야합니다. 1보다 큰 값은 쓰기 처리량에 상당한 영향을 미칩니다.

  • fsync . 사용 가능한 경우 Mongo가 각 쓰기 후 디스크에 플러시하도록하는 내구성 옵션입니다. 쓰기 백 로그와 관련된 내구성 문제가 없었으므로 프로덕션에서 false (기본값)로 설정했습니다.

  • j * (새로운 2.7+) *. true로 설정되면 MongoDB가 반환하기 전에 성공적인 저널링 그룹 커밋을 기다리도록하는 부울입니다. 저널링을 활성화 한 경우 추가 내구성을 위해 활성화 할 수 있습니다. 를 참조하십시오 http://www.mongodb.org/display/DOCS/Journaling 저널링 당신을 얻는 것을보고 (그리고 왜이 플래그를 활성화 할 수 있음).

ReadPreference ReadPreference 클래스를 사용하면 복제본 세트로 작업하는 경우 어떤 mongod 인스턴스 쿼리가 라우팅되는지 구성 할 수 있습니다. 다음 옵션을 사용할 수 있습니다.

  • ReadPreference.primary () : 모든 읽기는 repset 기본 멤버로만 이동합니다. 모든 쿼리가 일관된 (가장 최근에 작성된) 데이터를 반환해야하는 경우이 옵션을 사용합니다. 이것이 기본값입니다.

  • ReadPreference.primaryPreferred () : 가능한 경우 모든 읽기가 repset 기본 멤버로 이동하지만 기본 노드를 사용할 수없는 경우 보조 멤버를 쿼리 할 수 ​​있습니다. 따라서 기본을 사용할 수 없게되면 읽기는 결국 일관성을 갖게되지만 기본을 사용할 수없는 경우에만 가능합니다.

  • ReadPreference.secondary () : 모든 읽기는 보조 repset 멤버로 이동하고 기본 멤버는 쓰기 전용으로 사용됩니다. 최종적으로 일관된 읽기를 사용할 수있는 경우에만 이것을 사용하십시오. repset이 가질 수있는 (투표) 구성원 수에 제한이 있지만 추가 repset 구성원을 사용하여 읽기 성능을 확장 할 수 있습니다.

  • ReadPreference.secondaryPreferred () : 사용 가능한 모든 읽기는 보조 repset 멤버로 이동합니다. 모든 보조 멤버를 사용할 수 없게되는 경우가 아니면 기본 멤버는 쓰기 전용으로 사용됩니다. 읽기를위한 기본 멤버로의 대체를 제외하고 이것은 ReadPreference.secondary ()와 동일합니다.

  • ReadPreference.nearest () : 읽기는 데이터베이스 클라이언트에서 사용할 수있는 가장 가까운 repset 멤버로 이동합니다. 최종 일관성 읽기가 허용되는 경우에만 사용하십시오. 가장 가까운 멤버는 클라이언트와 다양한 repset 멤버 사이의 지연 시간이 가장 짧은 멤버입니다. 바쁜 구성원은 결국 더 높은 대기 시간 을 가지므로 내 경험상 보조 (선호)가 구성원 대기 시간이 비교적 일관된 경우 더 나은 것처럼 보이지만 읽기로드의 균형을 자동으로 조정 해야합니다 .

참고 : 위의 모든 항목에는 대신 TaggableReadPreference 인스턴스를 반환하는 동일한 메서드의 태그 사용 버전이 있습니다. 복제 세트 태그에 대한 전체 설명은 여기에서 찾을 수 있습니다. 복제 세트 태그


6
socketTimeout과 connectTimeout을 기본값 (무한)으로 두는 것은 위험하지 않습니까? 어떤 이유로 연결이 중단되면 앱 (또는 적어도 해당 스레드)이 영원히 중단됩니다. 이 값을 매우 높게 설정해야하지 않습니까 (연결에 30 초, 소켓에 2 분 정도)?
Idris Mokhtarzada

이드리스, 매우 사실입니다. 내 게시물에서 MongoOptions에 기본값이 있다고 착각하게 생각했습니다. Mongo ORM 레이어는 각각 15 초와 1 분에이 값을 가지고 있으며 글을 쓰는 동안 이것이 기본값이라고 가정했습니다. 무한 시간 초과는 확실히 나쁜 생각입니다. 머리를 올려 주셔서 감사합니다. 포스트에서 수정했습니다
Remon van Vliet 2011-08-24

"slaveOk"옵션은 이제 더 이상 사용되지 않습니다. 이에 상응하는 값을 true로 설정하려면 다음을 수행하십시오. mongoOptions.readPreference = ReadPreference.secondaryPreferred ();
Gubatron

좋은 대답이지만 threadsAllowedToBlockForConnectionMultiplier에 대한 정의가 잘못되었습니다 (키워드 승수). 문서에 따라 : "connectionsPerHost가 10이고 threadsAllowedToBlockForConnectionMultiplier가 5 인 경우 차단할 수있는 스레드 수에 대한 connectionsPerHost의 배수는 50 개 스레드가 그 이상을 차단할 수 있으며 예외가 발생합니다."
Tyler Zale

3
꽤 대중적인 대답 인 것 같습니다. 사람의 날 최신 드라이버의 변경 사항을 반영하기 위해이 업데이트에 관심이 있다면 알려주세요
레몬 반 Vliet 고을
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.