Solr parece bloquear las solicitudes de actualización al cometer

Question

Estamos ejecutando una configuración maestro-esclavo con Solr 3.6 usando las siguientes opciones de auto-entrega:

maxdocs: 500000

MaxTime: 600000

Nosotros tiene aproximadamente 5 millones de documentos en nuestro índice que ocupa aproximadamente 550 GB. Estamos ejecutando tanto el maestro como el esclavo en instancias de Amazon EC2 XLarge (4 núcleos virtuales y 15 GB). No tenemos un rendimiento de escritura particularmente alto, unos 100 documentos nuevos por minuto.

Estamos utilizando Jetty como un contenedor que tiene 6GB asignados.

El problema es que una vez que se ha iniciado una confirmación, todas nuestras solicitudes de actualización comienzan el tiempo de espera (no estamos realizando consultas en este recuadro). El compromiso en sí parece demorar aproximadamente 20-25 minutos, tiempo durante el cual no podemos agregar ningún documento nuevo a Solr.

Una de las respuestas en la siguiente pregunta sugiere utilizar 2 núcleos e intercambiarlos una vez que estén completamente actualizados. Sin embargo, esto parece un poco exagerado.

Solr requests time out during index update. Perhaps replication a possible solution?

¿Hay algo más que debería buscar en cuanto a por qué Solr parece ser peticiones de bloqueo? Estoy optimista con la esperanza de que hay una bandera "dontBlockUpdateRequestsWhenCommitting" en la configuración que he pasado por alto ...

Muchas gracias,

Answer 1

De acuerdo a la razón que los frutos y el problema mencionado en la pregunta aquí es una solución de Solr:

Solr tiene una capacidad llamada SolrCloud que comienza con la versión 4.x de Solr. En lugar de la arquitectura anterior maestro/esclavo, hay líderes y réplicas. Los líderes son responsables de indexar documentos y replicar consultas. El sistema es administrado por Zookeeper. Si un líder baja, una de sus réplicas se selecciona como nuevo líder.

Con todo, si desea dividir su proceso de indexación que está bien con SolrCloud de forma automática porque existe un líder para cada fragmento y ellos son responsables de la indexación de los documentos de sus fragmentos. Cuando envíe una consulta al sistema, habrá algunos nodos Solr (por supuesto, si hay nodos Solr más que fragmentos) que no son responsables de la indexación, sin embargo, están listos para responder la consulta. Cuando agrega más réplicas, obtendrá un resultado de consulta más rápido (pero causará más tráfico de red entrante al indexar, etc.)

Answer 2

Para aquellos que enfrentan un problema similar, la causa de mi problema fue que tuve demasiados campos. en el documento, utilicé campos automáticos * _t, y el número de campos crece bastante rápido, y cuando eso alcanza un cierto número, solo consume la solución y el compromiso tomaría una eternidad.

En segundo lugar, me tomé un esfuerzo para hacer un perfil, la mayor parte del tiempo lo consume la llamada a la función string.intern(), parece que importa el número de campos en el documento, cuando ese número aumenta, el string.intern() parece cada vez más lento.

La fuente solr4 ya no utiliza el string.intern(). Pero una gran cantidad de campos aún mata el rendimiento con bastante facilidad.