Solr usa demasiada memoria

Question

Tenemos una instancia de Solr 3.4 ejecutándose en Windows 2008 R2 con Oracle Java 6 Hotspot JDK que deja de responder. Cuando miramos la máquina, notamos que la memoria física disponible se fue a cero.

El proceso Tomcat7.exe estaba usando ~ 70Gigs (Private Working Set) pero Working Set (Memory) estaba usando toda la memoria del sistema. No hubo errores en los registros de Tomcat/Solr. Usamos VMMap para identificar que la memoria se estaba utilizando para mapear la memoria de los archivos de secuencia de Solr.

Reiniciar Tomcat solucionó el problema temporalmente, pero finalmente regresó.

Intentamos disminuir el tamaño de JVM para dar más espacio a los archivos mapeados en la memoria, pero luego el Solr finalmente deja de responder con la generación anterior al 100%. Nuevamente, el restablecimiento solucionó el problema, pero no arrojó una excepción de falta de memoria antes de reiniciar.

Actualmente nuestro sentido spidey nos dice que la memoria caché no se contrae cuando hay presión de memoria, y que tal vez haya demasiados MappedByteBuffers dando vueltas para que el sistema operativo no pueda liberar la memoria de los archivos mapeados en la memoria.

Answer 1

Probablemente se deba a la nueva política predeterminada que SOLR utiliza para los directorios (intenta asignarlos a la RAM o algo así).

leyeron:
http://grokbase.com/t/lucene/solr-user/11789qq3nm/virtual-memory-usage-increases-beyond-xmx-with-solr-3-3

Answer 2

Hay demasiados parámetros y muy poca información para ayudar con cualquier detalle. Esta respuesta también es bastante antigua, como lo son los sistemas mencionados.

Aquí hay algunas cosas que ayudaron en mi experiencia:

• vez disminuir el uso de memoria RAM en Tomcat, así como en la SOLR para disminuir el riesgo de cambiar. Deje el espacio del sistema para respirar.
• si esto "comienza" a aparecer sin ningún cambio en Tomcat o en la configuración de SOLR, quizás se deba a que la cantidad de datos que SOLR tiene para indexar y consultar ha aumentado. Esto puede significar que la configuración original nunca fue buena para comenzar o que el límite de los recursos actuales se ha alcanzado y debe revisarse. ¿Cuál es?
• compruebe las consultas (si puede influir en ellas): mueva las construcciones de subconsulta que a menudo se solicitan en las filtraciones, mueva construcciones de solicitud muy individuales en el parámetro de consulta habitual. Disminuya el caché de consultas, aumente/mantenga el caché de consultas de filtro o disminuya el caché del filtro en caso de que las consultas de filtro no se usen tanto en su sistema.
• verifique el schema.xml de SOLR en los errores de configuración (podrían ser realmente ideas erróneas). Me encontré con esto una vez: mientras que la importación de campos se crearía en masa causando que la RAM se desborde.
• si ocurre durante la importación: verifique si el proceso de importación está configurado para autocommitirse y se compromete con bastante frecuencia y también se optimiza; es posible que se cometa menos veces y se optimice solo una vez al final.
• actualización de Java, Tomcat y SOLR