Rendimiento extraordinariamente pobre de MongoDB en la aplicación de escritura intensiva

Question

Estoy ejecutando MongoDB de escritura intensiva para una aplicación web y obtengo un rendimiento extraordinariamente bajo. Dicho esto, estoy bastante seguro de que el problema tiene más que ver con nuestro código, configuración y/o nuestro uso que con el propio mongo.

Estoy a punto de abrir la cabeza con un mazo por la desesperación, así que me preguntaba si a alguien le importaría mirar algunas de las salidas que he preparado para ver si algo parece problemático.

• db.stats()
• fstab, mdadm and iostat -xm 2
• mongostat

El código no es demasiado complicado (está en PHP, por cierto). Es mucho mucho -> find() y -> update(). Me aseguré de usar los índices para ambas llamadas y confirmé que, de hecho, estaban siendo utilizadas al explicar() en las consultas.

He intentado 1 servidor (ec2 m2.2xlarge), 4 servidores (2 fragmentos de 2 repeticiones) y 9 servidores (3 fragmentos de 3 repeticiones) y no pude obtener mucho de ellos.

En los buenos momentos, no puedo obtener nada más de 1500 escrituras por segundo (insertar + actualizar). La mayoría de las veces, tengo la suerte de alcanzar una cantidad combinada de 100 insert/update y siempre tengo un gran "% bloqueado" y muchas consultas en cola "qr | qw".

En este momento, tengo un script que se está ejecutando y está reptando. Lo peor es que cuando miro el mongostat por un tiempo, la cantidad de RAM utilizada en "res" es aproximadamente el 50% de la RAM disponible del servidor y hay suficiente RAM para ajustarse a los índices de todas las colecciones. No hay ninguna razón por la cual esto no esté escupiendo datos como loco.

Debo haber recodificado la aplicación 2-3 veces ya, tratando de encontrar mejores patrones de acceso para los datos. He leído todo lo que pude leer sobre índices, actualizaciones, claves de fragmentos y otras cosas. Todos los servidores en los que puse Mongo están usando una configuración de 8 discos EBS incursión 10 con algunos ajustes de rendimiento agregados (blockdev, noatime, etc ...).

Sé que el problema está en mi parte y no estoy culpando a mongodb. Sé que empresas más grandes que yo lo están utilizando para aplicaciones de escritura intensiva y que les encanta (foursquare, por ejemplo). Al mismo tiempo, simplemente no puedo entender lo que estoy haciendo mal y por qué estoy obteniendo un rendimiento tan pobre, sin importar lo que haga.

Información adicional:

• Todos los servidores (cliente y servidor) está ejecutando Ubuntu 10.04 LTS con MongoDB 1.8.2
• Todos los servidores están en EC2 Medio y en la misma zona
• Actualmente, Estoy de regreso en 1 m2.2xlarge servidor (4 núcleos, 34.2 GB RAM) hasta que pueda averiguar dónde está el problema.

Answer 1

Así que el primer problema es que su disco parece estar ocupado principalmente con la lectura en lugar de escribir. (basado en iostat). Su utilización supera el 50%, pero básicamente es todo lo que se lee.

Si miro las estadísticas de su base de datos, tiene 35GB de índices y 41GB de datos en 133GB de archivos asignados. 133GB está bastante cerca de su número mapped en mongostat.Entonces, la suma de los datos a los que puede acceder es de aproximadamente 120 GB o aproximadamente 4x de RAM.

Normalmente, 4x es una relación perfectamente fina. Sin embargo, en su caso, tiene índices que exceden la RAM. Esto tiende a ser un punto de "caída" para el rendimiento en MongoDB.

Si está accediendo aleatoriamente en el índice, la mayoría o la totalidad del índice está en la memoria. Esto significa que la mayoría de sus datos no están en la memoria y deben estar "localizados" desde el disco. Puede ver esto en las lecturas de discos pesados ​​que está recibiendo.

Sé que dices que has probado con sharding, ¿tienes números para esas pruebas? ¿Los datos se distribuyeron correctamente en los tres fragmentos?

El sharding debería aliviar su problema ya que está "agregando más RAM" a la base de datos, pero debe confirmar que los datos están fragmentados uniformemente y que se comporta correctamente o que no puede solucionar su problema.