2011-05-09 11 views
8

Tenemos un clúster de 2 conjuntos de réplicas, con 3 servidores por conjunto. Con una sola colección fragmentada. También tenemos bastantes más (8+) colecciones que utilizamos a diario. Con la mayoría de los datos en la colección fragmentada con cerca de 100 millones de registros.MongoDB Cursor Tiempos de espera mientras realiza muchas escrituras

Recientemente hemos agregado el requisito para obtener 100x los datos que habíamos obtenido previamente, y tenemos que escribir esto en mongodb. Se ha establecido un daemon para realizar las escrituras necesarias para mantener la base de datos actualizada. El script se ejecuta a más de 200 escrituras por segundo, y la mayoría va a todas las colecciones por separado.

Con esta cantidad de escrituras, no hemos podido realizar lecturas grandes para fines analíticos. Recibir una combinación de Cursor Timeouts del lado del cliente y del lado del servidor ("Cursor no encontrado").

Hemos intentado limitar/saltear esquemas en las lecturas, pero el problema persiste. ¿Cuál es el mejor curso de acción para remediar esto ya que requerimos tanto una gran cantidad de escrituras, con pocas, pero grandes lecturas?

Respuesta

3

Normalmente, en un caso como este, desea comenzar a buscar las consultas que causan la hora. Luego, quiere ver el hardware para ver qué está siendo estresado.

  1. ¿Están estas consultas correctamente indexadas?
  2. ¿Qué tan grandes son los índices? ¿Caben en RAM?
  3. ¿Puede proporcionarnos algunos detalles sobre dónde están los cuellos de botella?
  4. ¿Está bloqueado en IO?
  5. ¿Están funcionando sus procesadores a toda velocidad?

Además, ¿hay algo inusual en los registros?

Básicamente tenemos que asegurarse de que tiene: 1. correctamente construido el sistema para manejar la consulta 2. aprovisionado correctamente el sistema para manejar los volúmenes de datos

+0

1. Sólo estamos consultar nuestra lee con _ID campo. 2. Nuestros índices son solo un poco más grandes que el tamaño de la memoria, con nuestras instancias EC2 con 7.5 GB y nuestros índices por replSet en 9.5 GB. Actualmente estamos en el proceso de actualización a 32 GB maestros. 3. No puedo ver ningún cuello de botella, solo los problemas son leer completamente los datos. 4. En general, estamos bloqueados en la colección que requiere más escrituras, pero de lo contrario estamos bien. 5. Nuestros procesadores no están demasiado estresados ​​en absoluto. – Bryan

+0

¿Cómo se ven iostat y mongostat? ¿Estás corriendo en unidades EBS? ¿INCURRIDO? ¿Cómo es su desempeño? –

+0

mongostat muestra bloqueado% que flota alrededor del 90%, con actualizaciones que dominan los gráficos. Actualmente estamos ejecutando efimeras en los maestros y EBS en las secundarias. iostat muestra lecturas/s en 622 y 365 para escrituras/s, las lecturas son probablemente altas porque actualmente estamos recuperando 2 servidores de 32 GB. – Bryan

Cuestiones relacionadas