comando - ¿Cómo configurar MongoDB controlador de Java MongoOptions para uso de producción?

mongodb skip (2)

Actualizado a 2.9:

autoConnectRetry simplemente significa que el controlador intentará reconectarse automáticamente con el servidor después de desconectarse inesperadamente. En entornos de producción, generalmente quiere que este conjunto sea verdadero.
connectionsPerHost es la cantidad de conexiones físicas que una única instancia de Mongo (es singleton, por lo que normalmente tiene una por aplicación) puede establecerse en un proceso mongod / mongos. Al momento de escribir, el controlador java establecerá eventualmente esta cantidad de conexiones, incluso si el rendimiento real de la consulta es bajo (en pocas palabras, verá la estadística "conn" en aumento de mongostat hasta que llegue a este número por servidor de aplicaciones).
No es necesario configurar esto más de 100 en la mayoría de los casos, pero esta configuración es una de esas cosas "prueba y ver". Tenga en cuenta que deberá asegurarse de configurar esto lo suficientemente bajo para que la cantidad total de conexiones a su servidor no exceda
db.serverStatus().connections.available

En producción, actualmente tenemos esto en 40.
connectTimeout . Como su nombre indica el número de milisegundos, el controlador esperará antes de que se anule el intento de conexión. Establezca el tiempo de espera en algo largo (15-30 segundos) a menos que haya una probabilidad realista y esperada de que esto sea un obstáculo para los intentos de conexión que de otro modo serían exitosos. Normalmente, si un intento de conexión demora más de un par de segundos, su infraestructura de red no puede obtener un alto rendimiento.
maxWaitTime . Número de ms que un subproceso esperará a que una conexión esté disponible en el grupo de conexiones, y genera una excepción si esto no ocurre a tiempo. Mantener por defecto
socketTimeout . Valor de tiempo de espera del socket estándar. Establecer a 60 segundos (60000).
threadsAllowedToBlockForConnectionMultiplier . Multiplicador para connectionsPerHost que denota la cantidad de subprocesos que pueden esperar para que las conexiones estén disponibles si el grupo está actualmente agotado. Esta es la configuración que provocará la excepción "com.mongodb.DBPortPool $ SemaphoresOut: Out of semaphores to get db connection". Arrojará esta excepción una vez que esta fila de hilos exceda el valor de threadsAllowedToBlockForConnectionMultiplier. Por ejemplo, si connectionsPerHost es 10 y este valor es 5, hasta 50 hilos pueden bloquearse antes de que se produzca la excepción antes mencionada.
Si espera grandes picos en el rendimiento que podrían causar largas colas, aumentar temporalmente este valor. Lo tenemos en 1500 en este momento exactamente por esa razón. Si la carga de su consulta sobrepasa constantemente al servidor, debería mejorar su situación de hardware / escala en consecuencia.
readPreference . (ACTUALIZADO, 2.8+) Se usa para determinar la preferencia de lectura predeterminada y reemplaza a "slaveOk". Configure una ReadPreference mediante uno de los métodos de fábrica de clase. Se puede encontrar una descripción completa de la configuración más común al final de esta publicación.
w . (ACTUALIZADO, 2.6+) Este valor determina la "seguridad" de la escritura. Cuando este valor es -1, la escritura no informará ningún error, independientemente de los errores de red o de base de datos. WriteConcern.NONE es la WriteConcern predefinida apropiada para esto. Si w es 0, los errores de red harán que la escritura falle, pero los errores de mongo no lo harán. Esto se conoce como "escribir y olvidar" y se debe utilizar cuando el rendimiento es más importante que la consistencia y la durabilidad. Use WriteConcern.NORMAL para este modo.
Si configura w en 1 o más, la escritura se considera segura. Las escrituras seguras realizan la escritura y la siguen solicitando al servidor que se asegure de que la escritura sea exitosa o recupere un valor de error si no lo hizo (en otras palabras, envía un comando getLastError () después de escribir). Tenga en cuenta que hasta que se complete este comando getLastError () la conexión está reservada. Como resultado de eso y el comando adicional, el rendimiento será significativamente más bajo que las escrituras con w <= 0. Con un valor de aw de exactamente 1 MongoDB garantiza que la escritura tuvo éxito (o falló verificablemente) en la instancia a la que envió la escritura.
En el caso de los conjuntos de réplicas, puede usar valores más altos para decirle a MongoDB que envíe la escritura al menos a los miembros "w" del conjunto de réplicas antes de regresar (o más exactamente, espere la replicación de su escritura a los miembros "w" ) También puede establecer w en la cadena "mayoría", que le indica a MongoDB que realice la escritura en la mayoría de los miembros del conjunto de réplicas (WriteConcern.MAJORITY). Por lo general, debe establecerlo en 1 a menos que necesite un rendimiento sin procesar (-1 o 0) o escrituras replicadas (> 1). Los valores superiores a 1 tienen un impacto considerable en el rendimiento de escritura.
fsync . Opción de durabilidad que obliga a mongo a enjuagarse al disco después de cada escritura cuando está habilitado. Nunca he tenido problemas de durabilidad relacionados con una acumulación de escritura, por lo que tenemos esto en falso (el valor predeterminado) en producción.
j * (NUEVO 2.7+) *. Boolean que cuando se establece en verdadero, obliga a MongoDB a esperar que un grupo de diario exitoso se comprometa antes de regresar. Si tiene habilitado el diario, puede habilitarlo para una mayor durabilidad. Consulte http://www.mongodb.org/display/DOCS/Journaling para ver qué le proporciona el diario (y por lo tanto, puede que quiera habilitar esta bandera).

ReadPreference La clase ReadPreference le permite configurar las consultas de instancias mongod que se enrutan si está trabajando con conjuntos de réplicas. Las siguientes opciones están disponibles :

ReadPreference.primary () : todas las lecturas van solo al miembro principal de repset. Úselo si necesita que todas las consultas devuelvan datos consistentes (los más recientes). Este es el predeterminado.
ReadPreference.primaryPreferred () : todas las lecturas van al miembro primario de repset si es posible, pero pueden consultar miembros secundarios si el nodo primario no está disponible. Como tal, si el primario deja de estar disponible, las lecturas se vuelven finalmente consistentes, pero solo si el primario no está disponible.
ReadPreference.secondary () : todas las lecturas van a los miembros secundarios de Repset y el miembro primario se usa solo para escrituras. Úselo solo si puede vivir con lecturas consistentes eventualmente. Se pueden usar miembros adicionales de Repset para ampliar el rendimiento de lectura, aunque existen límites para la cantidad de miembros (de votación) que puede tener un Repset.
ReadPreference.secondaryPreferred () : todas las lecturas van a los miembros secundarios de Repset si alguno de ellos está disponible. El miembro primario se usa exclusivamente para escrituras a menos que todos los miembros secundarios no estén disponibles. Aparte de la reserva para el miembro primario para lecturas, esto es lo mismo que ReadPreference.secondary ().
ReadPreference.nearest () : lee ir al miembro repset más cercano disponible para el cliente de la base de datos. Úselo solo si eventualmente las lecturas consistentes son aceptables. El miembro más cercano es el miembro con la latencia más baja entre el cliente y los diversos miembros de Repset. Dado que los miembros ocupados eventualmente tendrán latencias más altas, esto también debería equilibrar automáticamente la carga de lectura, aunque en mi experiencia secundaria (Preferido) parece ser mejor si las latencias de los miembros son relativamente consistentes.

Nota: Todas las anteriores tienen versiones habilitadas para etiquetas del mismo método que devuelven instancias de TaggableReadPreference. Aquí puede encontrar una descripción completa de las etiquetas de conjuntos de réplicas: Réplica Establecer etiquetas

Estuve buscando en la web las mejores prácticas para configurar MongoOptions para el controlador MongoDB Java y no he encontrado mucho más que la API. Esta búsqueda comenzó después de que me encontré con el error "com.mongodb.DBPortPool $ SemaphoresOut: Out of semaphores to get db connection" y al aumentar las conexiones / multiplicador pude resolver ese problema. Estoy buscando enlaces o sus mejores prácticas para configurar estas opciones de producción.

Las opciones para el controlador 2.4 incluyen: http://api.mongodb.org/java/2.4/com/mongodb/MongoOptions.html

autoConnectRetry
connectionsPerHost
connectTimeout
maxWaitTime
socketTimeout
threadsAllowedToBlockForConnectionMultiplier

Los controladores más nuevos tienen más opciones y me interesaría saber de ellos también.

Los controladores MongoDB proporcionan varias opciones para que los clientes de Mongo manejen diferentes errores de tiempo de espera de red que pueden ocurrir durante el uso. Las opciones varían desde la versión del controlador y el idioma. Recomiendo leer la documentación de la clase MongoClient de su controlador. En producción, es importante establecer valores correctos para estas opciones para evitar interrupciones inesperadas en el flujo de su aplicación. Conectarse de manera inteligente a su servidor de base de datos puede mejorar el rendimiento de su aplicación.

Aquí hay algunas opciones importantes para MongoClient que desea configurar mientras se conecta al servidor MongoDB en producción.

ServerSelctionTimeOut : el tiempo de espera de selección del servidor es la cantidad de milisegundos que el controlador mongo esperará para seleccionar un servidor para una operación antes de abandonar y generar un error. El controlador de Móner utiliza 30 segundos como valor predeterminado del tiempo de espera de selección del servidor. Dependiendo del caso de uso, podemos aumentar o disminuir este umbral.

Tiempo de espera de conexión: el tiempo de espera de conexión es la cantidad de milisegundos que el controlador esperará antes de que se anule un nuevo intento de conexión. El valor predeterminado de un tiempo de espera de conexión depende de la versión y el idioma del controlador. Las últimas versiones de controladores de Mongo Java y Ruby tienen un tiempo de espera predeterminado de 10 segundos para los establecimientos de conexión, mientras que el controlador NodeJs no tiene tiempo de espera. Si el tiempo de espera es demasiado alto, corre el riesgo de estancar su aplicación. Si el tiempo de espera es demasiado bajo, puede darse por vencido demasiado rápido. Es mejor probar con diferentes valores para encontrar el tiempo de espera correcto para su aplicación.

SocketTimeout : el tiempo de espera del socket es la cantidad de milisegundos que un envío o recepción en un socket puede tomar antes de que se agote el tiempo de espera. El controlador deMongo Java y Nodejs tiene un tiempo de espera de socket predeterminado de 0, lo que significa básicamente que no hay tiempo de espera. Mientras que Ruby ofrece un tiempo de espera de 5 sockets. No desea poner un límite a este tiempo de espera ya que las diferentes operaciones tomarán tiempo variable para operar.

Entender las opciones de Tiempo de espera de MongoDB Client tiene una descripción detallada para tener más información sobre estas opciones.