MongoDB Java 드라이버 MongoOptions를 실가동용으로 설정하는 방법

MongoDB Java 드라이버 MongoOptions를 실가동용으로 설정하는 방법

MongoDB Java 드라이버용 MongoOptions를 설정하기 위한 베스트 프랙티스를 웹에서 찾고 있지만 API 이외에는 별로 생각해내지 못했습니다.이 검색은 "com.mongodb"에 접속한 후 시작되었습니다.DBPortPool $SemaphoresOut: 세마포어 부족에서 db connection" 오류가 발생하여 연결/승수를 늘림으로써 이 문제를 해결할 수 있었습니다.실가동용으로 이러한 옵션을 설정하기 위한 베스트 프랙티스에 대한 링크 또는 귀사의 베스트 프랙티스를 찾고 있습니다.

2.4 드라이버의 옵션은, http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html 입니다.

• 자동 접속 재시도
• 호스트별 연결 수
• connect Timeout(접속 타임아웃)
• 최대 대기 시간
• 소켓 타임아웃
• 스레드 차단 가능 For Connection 승수

새로운 드라이버일수록 옵션이 넓어지기 때문에 그것들에 대해서도 듣고 싶습니다.

2.9로 갱신:

• AutoConnectRetry는 단순히 예기치 않은 연결 해제 후 드라이버가 자동으로 서버에 재접속을 시도함을 의미합니다.실제 가동 환경에서는 보통 이 설정을 true로 설정합니다.

• connections Per Host는 단일 Mongo 인스턴스(싱글톤이므로 보통 애플리케이션당1개씩)가 mongod/mongos 프로세스에 확립할 수 있는 물리 접속의 양입니다.작성 시 Java 드라이버는 실제 쿼리 처리량이 낮더라도 결국 이 양의 접속을 확립합니다(단어로는 앱 서버당 이 수에 도달할 때까지 mongostat에서 "conn" 통계치가 상승합니다).

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

  db.serverStatus().connections.available

  현재 생산 중인 제품은 40대입니다.

• connect Timeout 입니다.이름에서 알 수 있듯이 드라이버는 접속이 중단될 때까지 대기합니다.그렇지 않으면 정상적으로 접속을 시도할 수 없는 현실적인 가능성이 없는 한 타임아웃을 긴 시간(15~30초)으로 설정합니다.일반적으로 접속 시행에 몇 초 이상 걸리는 경우 네트워크 인프라스트럭처는 높은 throughput을 제공할 수 없습니다.

• maxWaitTime(최대 대기시간)스레드가 접속 풀에서 접속을 사용할 수 있게 될 때까지 대기하는 시간(밀리초)입니다.이 시간이 경과하지 않으면 예외가 발생합니다.디폴트인 채로 합니다.

• 소켓 타임아웃표준 소켓타임아웃값60초(600)로 설정합니다.

• 스레드 Allowed To Block For Connection Multiplier.connectionsPerHost의 승수. 풀이 현재 모두 사용되었을 때 연결을 사용할 수 있을 때까지 대기할 수 있는 스레드 수를 나타냅니다.이것이 "com.mongodb"의 원인이 되는 설정입니다.DBPortPool $SemaphoresOut: 세마포어가 부족하여 db connection" 예외를 가져옵니다.이 스레드 큐가 스레드를 초과하면 이 예외가 발생합니다.AllowedToBlockForConnectionMultiplier 값.예를 들어 connectionsPerHost가 10이고 이 값이 5 ~50 스레드인 경우 위의 예외가 발생하기 전에 차단할 수 있습니다.

  throughput의 큰 피크가 예상되면 큰 큐가 일시적으로 이 값을 증가시킬 수 있습니다.지금 바로 그 이유 때문에 1500시에 있습니다.쿼리 로드가 항상 서버를 앞지를 경우 하드웨어/스케일링 상황을 개선하기만 하면 됩니다.

• read Preference. (UPDATED, 2.8+) 기본 읽기 기본 설정을 결정하는 데 사용되며 "slaveOk"를 대체합니다.클래스 팩토리 메서드 중 하나를 사용하여 Read Preference를 설정합니다.가장 일반적인 설정에 대한 자세한 설명은 이 게시물의 끝에 있습니다.

• w. (UPDATED, 2.6+) 이 값은 쓰기의 "안전성"을 결정합니다.이 값이 -1일 경우 네트워크 또는 데이터베이스 오류에 관계없이 쓰기는 오류를 보고하지 않습니다.Write Contern.NONE은 이에 적합한 사전 정의된 WriteConsern입니다.w가 0일 경우 네트워크 오류로 인해 쓰기가 실패하지만 mongo 오류는 실패하지 않습니다.이것은 통상 「불꽃과 기억」이라고 불리며, 일관성과 내구성보다 퍼포먼스가 중요한 경우에 사용합니다.WriteConsern을 사용합니다.이 모드에서는 NORMAL.

  w를 1 이상으로 설정하면 쓰기는 안전한 것으로 간주됩니다.안전한 쓰기는 쓰기를 수행하고 서버에 대한 요구에 따라 후속 작업을 수행하여 쓰기가 성공했는지 확인하거나 실패했을 경우 오류 값을 가져옵니다(즉, 쓰기 후 getLastError() 명령어를 전송합니다).이 getLastError() 명령어가 완료될 때까지 접속은 예약됩니다.따라서 추가 명령을 사용하면 w <= 0인 쓰기보다 처리량이 상당히 낮아집니다.W 값이 정확히 1인 MongoDB는 쓰기를 보낸 인스턴스에서 쓰기가 성공(또는 검증 가능한 실패)했음을 보증합니다.

  레플리카 세트의 경우, 반환하기 전에 레플리카 세트의 적어도 "w" 멤버에게 쓰기를 전송하도록 MongoDB에 지시하는 경우(또는 보다 정확하게는 "w" 멤버에 쓰기가 복제되기를 기다리는 경우)에 더 높은 값을 사용할 수 있습니다.w를 문자열 "majority"로 설정할 수도 있습니다.이 문자열은 MongoDB에 대부분의 복제 세트멤버(WriteConcern)에 쓰기를 수행하도록 지시합니다.다수).로 퍼포먼스(-1 또는 0)나 리플리케이트 된 기입(>1)이 필요한 경우를 제외하고, 이것을 1로 설정할 필요가 있습니다.값이 1보다 크면 쓰기 스루풋에 큰 영향을 미칩니다.

• fsync. 유효하게 하면, 기입할 때마다 mongo를 디스크에 강제적으로 플러시 하는 내구성 옵션.쓰기 백로그와 관련된 내구성 문제는 한 번도 발생하지 않았기 때문에 실제 가동에서는 false(기본값)로 되어 있습니다.

• j *(NEW 2.7+)*. true로 설정하면 MongoDB가 반환하기 전에 성공적인 저널 그룹 커밋을 대기하도록 강제하는 부울입니다.문서철을 사용하도록 설정한 경우 추가 내구성을 위해 이 기능을 유효하게 할 수 있습니다.저널링을 통해 얻을 수 있는 정보(이 플래그를 유효하게 하는 이유)에 대해서는, http://www.mongodb.org/display/DOCS/Journaling 를 참조해 주세요.

ReadPreference ReadPreference 클래스에서 복제 세트를 사용하는 경우 라우팅되는 mongod 인스턴스 쿼리를 구성할 수 있습니다.다음의 옵션을 사용할 수 있습니다.

• Read Preference.primary() : 모든 읽기는 repset 프라이머리 멤버에게만 전송됩니다.모든 쿼리에서 일관성 있는(가장 최근에 작성된) 데이터를 반환해야 하는 경우 이 옵션을 사용합니다.이것이 기본값입니다.

• Read Preference.primary Preferred() : 가능한 경우 모든 읽기가 repset 프라이머리 멤버에게 전송되지만 프라이머리 노드를 사용할 수 없는 경우 세컨더리 멤버에게 문의할 수 있습니다.따라서 프라이머리를 사용할 수 없게 되면 프라이머리를 사용할 수 없는 경우에만 읽기가 일관되게 됩니다.

• [ Read Preference ]를 참조.secondary() : 모든 읽기는 secondary repset 멤버에게 전송되며 프라이머리 멤버는 쓰기 전용입니다.이 기능은 일관된 읽기로 사용할 수 있는 경우에만 사용하십시오.repset에 포함할 수 있는 (투표) 멤버 수에 제한이 있지만 읽기 성능을 확장하기 위해 추가 repset 멤버를 사용할 수 있습니다.

• [ Read Preference ]를 참조.secondary Preferred() : 사용 가능한 secondary repset 멤버가 있으면 모든 읽기가 secondary repset 멤버에게 전달됩니다.프라이머리 멤버는 모든 세컨더리 멤버를 사용할 수 없는 경우를 제외하고 쓰기 전용으로 사용됩니다.읽기용 프라이머리 멤버로의 폴백 이외에는 Read Preference와 동일합니다.세컨더리의

• Read Preference.nearest() : 데이터베이스 클라이언트가 사용할 수 있는 가장 가까운 repset 멤버로 읽습니다.일관된 읽기가 허용되는 경우에만 사용하십시오.가장 가까운 멤버는 클라이언트와 다양한 repset 멤버 사이의 지연이 가장 짧은 멤버입니다.비지 멤버는 최종적으로 레이텐시가 높아지기 때문에 읽기 부하도 자동적으로 밸런스 할 수 있습니다.단, 제 경험상 멤버 레이텐시가 비교적 일정하면 secondary(선호)가 더 나은 것 같습니다.

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

언급URL : https://stackoverflow.com/questions/6520439/how-to-configure-mongodb-java-driver-mongooptions-for-production-use