Le serveur Neo4j se bloque régulièrement toutes les 2 heures. S’il vous plaît aidez-moi à comprendre si quelque chose ne va pas avec la configuration

Nous avons une firebase database graphique neo4j avec environ 60 millions de nœuds et des relations équivalentes.

Nous avons été confrontés à des pertes de paquets constantes et à des retards de traitement et à un serveur bloqué complet après 2 heures. Nous avons dû arrêter et redémarrer nos serveurs chaque fois que cela se produisait et nous avons du mal à comprendre où nous nous sums trompés avec notre configuration.

Nous voyons les types d’exceptions suivants dans le fichier console.log –

1. java.lang.IllegalStateException: s = DISPATCHED i = true a = null 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 – Décès de thread inattendu: org.eclipse.jetty.util.thread.QueuedThreadPool$3@59d5a975 dans qtp1667455214 {STARTED, 14 <= ​​21 <= 21, i = 0, q = 58}
5. org.eclipse.jetty.server.Response – Validé avant 500 org.neo4j.server.rest.repr.OutputFormat$1@39beaadf
6. oejetty.servlet.ServletHandler – / db / data / cypher java.lang.IllegalStateException: Validé à org.eclipse.jetty.server.Response.resetBuffer (Response.java:1253) ~ [jetty-server-9.2.
7. org.eclipse.jetty.server.HttpChannel – / db / data / cypher java.lang.IllegalStateException: Validé à org.eclipse.jetty.server.Response.resetBuffer (Response.java:1253) ~ [jetty-server-9.2.
8. org.eclipse.jetty.server.HttpChannel – Impossible d’envoyer une erreur de réponse 500: java.lang.IllegalStateException: validée oejetty.server.ServerConnector – Arrêtée
9. oejetty.servlet.ServletHandler – / db / data / cypher org.neo4j.graphdb.TransactionFailureException: la transaction a été marquée comme réussie, mais incapable de valider la transaction annulée.

Nous utilisons le serveur neo4j enterprise edition 2.2.5 en mode SINGLE / NON CLUSTER sur un processeur Azure D series à 8 cœurs, 56 Go de RAM UBUNTU 14.04 LTS avec un disque de données de 500 Go associé.

• Le serveur Neo4j ne parvient pas à démarrer avec une extension non gérée

Voici un aperçu des tailles des fichiers neostore

• 8.5G Oct 2 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 Oct 2 15:07 neostore.schemastore.db
• 145 oct 2 15:07 neostore.labeltokenstore.db
• 170 oct 2 15:07 neostore.relationshiptypestore.db

La configuration de Neo4j est la suivante –

1. 30 Go alloués au cache de fichiers (dbms.pagecache.memory = 30G)
2. Mémoire de tas allouée de 20 Go à la machine virtuelle Java (wrapper.java.initmemory = 20480, wrapper.java.maxmemory = 20480)
3. Utilisation du cache de type hpc (hautes performances) par défaut.
4. Forcer le planificateur RULE par défaut (dbms.cypher.planner = RULE)
5. Le nombre maximal de requêtes de traitement de threads est de 16 (deux fois le nombre de cœurs) – org.neo4j.server.webserver.maxthreads = 16
6. Délai de transaction de 60 secondes – org.neo4j.server.transaction.timeout = 60
7. Guard Timeout si le temps d’exécution de la requête est supérieur à 10 secondes – org.neo4j.server.webserver.limit.executiontime = 10000

Le rest des parameters sont par défaut

Nous voulons en fait configurer un cluster de 3 nœuds, mais avant cela, nous voulons être sûrs que notre configuration de base est correcte. Aidez nous s’il vous plaît

————————————————– ————————

EDITED to ADD Query Sample

En règle générale, notre fréquence de requête de chiffrement est de 18 000 requêtes par heure avec une moyenne d’environ 5 à 6 requêtes par seconde. Il y a aussi des moments où il y a environ 80 requêtes par seconde.

Nos requêtes typiques ressemblent à celles ci-dessous

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)(p:TypeE)<-[:RELE]-(b1:TypeB)(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)(b1) where b1.param7 in [0,1] and exists((b1)-[:RELF|RELE]->()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)(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);

Ajout de quelques autres choses étranges que j’ai remarquées ….

J’ai arrêté tous mes serveurs Web. Donc, actuellement, il n’y a pas de demandes entrantes à neo4j. Cependant, je constate qu’il y a environ 40K de descripteurs de fichiers ouverts dans l’état de fermeture / attente TCP, ce qui implique que le client a fermé sa connexion à cause du dépassement de délai et que Neo4j ne l’a pas traité et a répondu à cette requête. Je vois également (à partir de messages.log) que le serveur Neo4j est toujours en train de traiter les requêtes et que, ce faisant, le traitement des fichiers ouverts de 40K est en train de diminuer lentement. Au moment où j’écris ce post, il y a environ 27K de fichiers ouverts dans l’état de fermeture / attente TCP.

Je vois également que les requêtes ne sont pas traitées en continu. De temps en temps, je vois une pause dans messages.log et je vois ces messages à propos de la rotation des journaux en raison d’une séquence en panne comme ci-dessous

Version du journal tournant: 5630

2015-10-04 05: 10: 42.712 + 0000 INFO [onkLogRotationImpl]: Rotation du journal [5630]: en attente de toutes les transactions fermées …

2015-10-04 05: 10: 42.712 + 0000 INFO [onkisStoreFactory]: Attente de la fermeture de toutes les transactions …

commis: séquence de désordre: 95494483 [95494476]

commettant: 95494483

fermé: séquence de désordre: 95494480 [95494246]

2015-10-04 05: 10: 43.293 + 0000 INFO [onkLogRotationImpl]: Rotation du journal [5630]: démarrage du magasin vider …

2015-10-04 05: 10: 44.941 + 0000 INFO [onkisStoreFactory]: À propos de la rotation du magasin de comptes à la transaction 95494483 vers [/datadrive/graph.db/neostore.counts.db.b], à partir de [/ datadrive / graph. db / neostore.counts.db.a].

2015-10-04 05: 10: 44.944 + 0000 INFO [onkisStoreFactory]: magasin de comptes ayant fait l’object d’une rotation à la transaction 95494483 vers [/datadrive/graph.db/neostore.counts.db.b], depuis [/datadrive/graph.db /neostore.counts.db.a].

Je vois aussi ces messages de temps en temps

2015-10-04 04: 59: 59.731 + 0000 DEBUG [onkEmbeddedGraphDatabase]: NodeCache array: 66890956 purge: 93 taille: 1.3485746GiB raté: 0.80978173% collisions: 1.9829895% (345785) av.purge attend: 13 purge attend: 0 moy . temps de purge: 110ms

ou

2015-10-04 05: 10: 20.768 + 0000 DEBUG [onkEmbeddedGraphDatabase]: Array RelationshipCache: 66890956 purge: 0 taille: 257.883MiB manqués: 10.522135% des collisions: 11.121769% (5442101) av.purge attend: 0 purge attende: 0 moy . temps de purge: N / A

Tout cela se produit lorsqu’il n’y a pas de demandes entrantes et que neo4j traite les anciennes requêtes 40K en attente, comme je l’ai mentionné ci-dessus.

Puisqu’il s’agit d’un serveur dédié, le serveur ne devrait-il pas traiter les requêtes de manière continue sans une telle queue en attente? Est-ce que j’ai râté quelque chose? Aidez-moi, s’il vous plaît

 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