configuration neo4j server database-performance

configuration - El servidor Neo4j se cuelga cada 2 horas constantemente. Por favor, ayúdame a entender si algo está mal con la configuración



server database-performance (2)

No fue completamente sobre sus consultas. Debería examinar cada una de las consultas que envía a menudo prefijando con PROFILE o EXPLAIN para ver el plan de consulta y obtener una idea de cuántos accesos ocasionan.

Por ejemplo, la segunda coincidencia en la siguiente consulta parece costosa ya que los dos patrones no están conectados entre sí:

MATCH (a:TypeA{param:{param}})-[r:RELD]->(a1)-[:RELH]->(h) where r.param1=true with a,a1,h match (m)-[:RELL]->(d:TypeI) where (d.param2/2)%2=1 optional match (a)-[:RELB]-(b)-[:RELM {param3:true}]->(c) return a1.param,id(a1),collect(b.bid),c.bPhoto

También habilite el registro de recolección de basura en neo4j-wrapper.conf y verifique si está sufriendo largas pausas. Si es así, considere reducir el tamaño del montón.

Tenemos una base de datos de gráficos neo4j con alrededor de 60 millones de nodos y una relación equivalente.

Nos hemos enfrentado a constantes caídas de paquetes y retrasos en el procesamiento y un servidor colgado completo después de 2 horas. Tuvimos que apagar y reiniciar nuestros servidores cada vez que esto sucede y estamos teniendo problemas para entender dónde nos equivocamos con nuestra configuración.

Estamos viendo el siguiente tipo de excepciones en el archivo console.log -

  1. java.lang.IllegalStateException: s = DISPATCHED i = verdadero a = nulo oejetty.server.HttpConnection - HttpConnection @ 609c1158 {FILLING}
  2. java.lang.IllegalStateException: s = DISPATCHED i = true a = null oejutil.thread.QueuedThreadPool
  3. java.lang.IllegalStateException: org.eclipse.jetty.util.SharedBlockingCallback $ BlockerTimeoutException
  4. oejutil.thread.QueuedThreadPool - Muerte de hilo inesperada: org.eclipse.jetty.util.thread.QueuedThreadPool$3@59d5a975 en qtp1667455214 {STARTED, 14 <= ​​21 <= 21, i = 0, q = 58}
  5. org.eclipse.jetty.server.Response: cometido antes de 500 org.neo4j.server.rest.repr.OutputFormat$1@39beaadf
  6. oejetty.servlet.ServletHandler - / db / data / cypher java.lang.IllegalStateException: cometido en org.eclipse.jetty.server.Response.resetBuffer (Response.java:1253) ~ [embarcadero-servidor-9.2.
  7. org.eclipse.jetty.server.HttpChannel - / db / data / cypher java.lang.IllegalStateException: cometido en org.eclipse.jetty.server.Response.resetBuffer (Response.java:1253) ~ [embarcadero-servidor-9.2.
  8. org.eclipse.jetty.server.HttpChannel: no se pudo enviar el error de respuesta 500: java.lang.IllegalStateException: cometido oejetty.server.ServerConnector - Stopped
  9. oejetty.servlet.ServletHandler - / db / data / cypher org.neo4j.graphdb.TransactionFailureException: la transacción se marcó como correcta, pero no se pudo confirmar la transacción.

Estamos utilizando el servidor neo4j enterprise edition 2.2.5 en el modo SINGLE / NON CLUSTER en la CPU Azure D serie 8, la máquina UBUNTU 14.04 LTS de 56 GB RAM con un disco de datos adjunto de 500 GB.

Aquí hay una instantánea de los tamaños de los archivos de Neostore

  • 8.5G 02 de octubre 15:48 neostore.propertystore.db
  • 15G Oct 2 15:48 neostore.relationshipstore.db
  • 2.5G Oct 2 15:48 neostore.nodestore.db
  • 6.9M Oct 2 15:48 neostore.relationshipgroupstore.db
  • 3.7K 2 de octubre 15:07 neostore.schemastore.db
  • 145 oct 2 15:07 neostore.labeltokenstore.db
  • 170 oct 2 15:07 neostore.relationshiptypestore.db

La configuración de Neo4j es la siguiente:

  1. Asignado 30GB a la memoria caché del buffer (dbms.pagecache.memory = 30G)
  2. Asignó 20 GB a la memoria de almacenamiento JVM (wrapper.java.initmemory = 20480, wrapper.java.maxmemory = 20480)
  3. Uso de la memoria caché de hpc (alto rendimiento) predeterminada.
  4. Forzar el planificador RULE de forma predeterminada (dbms.cypher.planner = RULE)
  5. El número máximo de consultas de procesamiento de subprocesos es 16 (el doble del número de núcleos) - org.neo4j.server.webserver.maxthreads = 16
  6. Tiempo de espera de transacción de 60 segundos - org.neo4j.server.transaction.timeout = 60
  7. Guard Timeout si el tiempo de ejecución de la consulta es superior a 10 segundos - org.neo4j.server.webserver.limit.executiontime = 10000

El resto de la configuración está predeterminada

De hecho, queremos configurar un clúster de 3 nodos, pero antes queremos asegurarnos de que nuestra configuración básica sea la correcta. Por favor ayudenos

-------------------------------------------------- ------------------------

EDITADO para ADD Query Sample

Normalmente, nuestra frecuencia de consulta de cifrado es de 18 consultas en una hora con un promedio de aproximadamente 5-6 consultas por segundo. También hay momentos en los que hay alrededor de 80 consultas por segundo.

Nuestras consultas típicas se parecen a las siguientes

match (a:TypeA {param:{param}})-[:RELA]->(d:TypeD) with distinct d,a skip {skip} limit 100 optional match (d)-[:RELF]->(c:TypeC)<-[:RELF]-(b:TypeB)<-[:RELB]-(a) with distinct d,a,collect(distinct b.bid) as bids,collect(distinct c.param3) as param3Coll optional match (d)-[:RELE]->(p:TypeE)<-[:RELE]-(b1:TypeB)<-[:RELB]-(a) with distinct d as distD,bids+collect(distinct b1.bid) as tbids,param3Coll,collect(distinct p.param4) as param4Coll optional match (distD)-[:RELC]->(f:TypeF) return id(distD),distD.param5,exists((distD)<-[:RELG]-()) as param6, tbids,param3Coll,param4Coll,collect(distinct id(f)) as fids

match (a:TypeA {param:{param}})-[:RELB]->(b) return count(distinct b)

MATCH (a:TypeA{param:{param}})-[r:RELD]->(a1)-[:RELH]->(h) where r.param1=true with a,a1,h match (h)-[:RELL]->(d:TypeI) where (d.param2/2)%2=1 optional match (a)-[:RELB]-(b)-[:RELM {param3:true}]->(c) return a1.param,id(a1),collect(b.bid),c.param5

match (a:TypeA {param:{param}}) match (a)-[:RELB]->(b) with distinct b,a skip {skip} limit 100 match (a)-[:RELH]->(h1:TypeH) match (b)-[:RELF|RELE]->(x)<-[:RELF|RELE]-(h2:TypeH)<-[:RELH]-(a1) optional match (a1)<-[rd:RELD]-(a) with distinct a1,a,h1,b,h2,rd.param1 as param2,collect(distinct x.param3) as param3s,collect(distinct x.param4) as param4s optional match (a1)-[:RELB]->(b1) where b1.param7 in [0,1] and exists((b1)-[:RELF|RELE]->()<-[:RELF|RELE]-(h1)) with distinct a1,a,b,h2,param2,param3s,param4s,b1,case when param2 then false else case when ((a1.param5 in [2,3] or length(param3s)>0) or (a1.param5 in [1,3] or length(param4s)>0)) then case when b1.param7=0 then false else true end else false end end as param8 MERGE (a)-[r2:RELD]->(a1) on create set r2.param6=true on match set r2.param6=case when param8=true and r2.param9=false then true else false end MERGE (b)-[r3:RELM]->(h2) SET r2.param9=param8, r3.param9=param8

MATCH (a:TypeA {param:{param}})-[:RELI]->(g:TypeG {type:''type1''}) match (g)<-[r:RELI]-(a1:TypeA)-[:RELJ]->(j)-[:RELK]->(g) return distinct g, collect(j.displayName), collect(r.param1), g.gid, collect(a1.param),collect(id(a1))

match (a:TypeA {param:{param}})-[r:RELD {param2:true}]->(a1:TypeA)-[:RELH]->(b:TypeE) remove r.param2 return id(a1),b.displayName, b.firstName,b.lastName match (a:TypeA {param:{param}})-[:RELA]->(b:TypeB) return a.param1,count(distinct id(b))

MATCH (a:TypeA {param:{param}}) set a.param1=true;

match (a:TypeE)<-[r:RELE]-(b:TypeB) where a.param4 in {param4s} delete r return count(b);

MATCH (a:TypeA {param:{param}}) return id(a);

Agregando algunas cosas más extrañas que he estado notando ...

He detenido todos mis servidores web. Entonces, actualmente no hay solicitudes entrantes para neo4j. Sin embargo, veo que hay aproximadamente 40 KB de identificadores de archivo abiertos en el estado cerrar / esperar TCP, lo que implica que el cliente ha cerrado su conexión debido a un tiempo de espera y Neo4j no lo ha procesado y respondido a esa solicitud. También veo (desde messages.log) que el servidor Neo4j todavía está procesando consultas y, mientras lo hace, los manejadores de archivos abiertos de 40K se están reduciendo lentamente. En el momento en que escribo esta publicación, hay aproximadamente 27,000 manejadores de archivos abiertos en estado de cierre / espera de TCP.

También veo que las consultas no se procesan continuamente. De vez en cuando veo una pausa en messages.log y veo estos mensajes sobre la rotación de registros debido a alguna secuencia fuera de orden como la siguiente

Versión de registro giratorio: 5630

2015-10-04 05: 10: 42.712 + 0000 INFO [onkLogRotationImpl]: Log Rotation [5630]: en espera de que se cierren todas las transacciones ...

2015-10-04 05: 10: 42.712 + 0000 INFO [onkisStoreFactory]: Esperando que se cierren todas las transacciones ...

cometido: secuencia fuera de orden: 95494483 [95494476]

cometiendo: 95494483

cerrado: secuencia fuera de orden: 95494480 [95494246]

2015-10-04 05: 10: 43.293 + 0000 INFO [onkLogRotationImpl]: rotación del registro [5630]: inicio de la descarga de la tienda ...

2015-10-04 05: 10: 44.941 + 0000 INFO [onkisStoreFactory]: a punto de rotar los recuentos almacenados en la transacción 95494483 a [/datadrive/graph.db/neostore.counts.db.b], desde [/ datadrive / graph. db / neostore.counts.db.a].

2015-10-04 05: 10: 44.944 + 0000 INFO [onkisStoreFactory]: el recuento de recuentos rotados correctamente en la transacción 95494483 a [/datadrive/graph.db/neostore.counts.db.b], desde [/datadrive/graph.db /neostore.counts.db.a].

También veo estos mensajes de vez en cuando

2015-10-04 04: 59: 59.731 + 0000 DEPURACIÓN [onkEmbeddedGraphDatabase]: NodeCache array: 66890956 purga: 93 tamaño: 1.3485746GiB falla: 0.80978173% colisiones: 1.9829895% (345785) av.purge espera: 13 espera de purga: 0 promedio . tiempo de purga: 110 ms

o

2015-10-04 05: 10: 20.768 + 0000 DEPURACIÓN [onkEmbeddedGraphDatabase]: RelationshipCache array: 66890956 purga: 0 tamaño: 257.883MiB falla: 10.522135% colisiones: 11.121769% (5442101) av.purge espera: 0 espera de purga: 0 promedio . tiempo de purga: N / A

Todo esto está sucediendo cuando no hay solicitudes entrantes y neo4j está procesando antiguas solicitudes pendientes de 40K como mencioné anteriormente.

Dado que es un servidor dedicado, ¿no debería el servidor procesar las consultas continuamente sin una larga cola pendiente? ¿Me estoy perdiendo de algo? por favor, ayúdame

Parece que este problema requiere más investigación de tu parte, pero hay algunas cosas de mi experiencia.

TL; DR; - Tuve un problema similar con mi propia extensión no administrada, donde las transacciones no se manejaron correctamente.

Idioma / conector

¿Qué idioma / conector se usa en su aplicación?

Debes verificar que:

  • Si se utiliza alguna biblioteca popular de código abierto, su aplicación está utilizando la última versión. Probablemente hay un error en su conector.
  • Si tiene su propia solución escrita a mano que funciona con API REST, verifique que TODAS las solicitudes http estén cerradas en el lado del cliente.

Extensión / complementos

Es bastante fácil complicar las cosas, si se utilizan extensiones / complementos escritos a medida.

Lo que debe verificarse:

  • Todas las transacciones siempre están cerradas (se usa try-with-resource )

Configuraciones de Neo4j

Verifica la configuración de tu servidor . Por ejemplo, si tiene un gran valor para org.neo4j.server.transaction.timeout y no maneja las transacciones correctamente en el lado del cliente, puede terminar con muchas transacciones en ejecución.

Supervisión

Estás usando la versión Enterprise. Eso significa que tienes acceso a JMX . Es una buena idea verificar la información sobre bloqueos y transacciones activos.

Otra versión de Neo4j

Tal vez puedas probar con otra versión de Neo4j. Por ejemplo, 2.3.0-M03.
Esto dará respuestas para preguntas como:

  • ¿Es este error Neo4j 2.2.5?
  • ¿Esta configuración de Neo4j existente es incorrecta?

Configuración de Linux

Verifica tu configuración de Linux.

  • ¿Qué hay en tu /etc/sysctl.conf ? ¿Hay alguna configuración no válida / no relacionada?

Otro servidor

Puede intentar hacer girar otro servidor (es decir, máquina virtual en Digital Ocean), implementar una base de datos allí y cargarla con Gatling .
Tal vez su servidor tiene alguna configuración no válida?

Intente deshacerse de todo, puede ser la causa del problema, para que sea más fácil encontrar un problema.