pilote de données Spring Cassandra se coince après quelques heures, avec base de données unique nœud sur le même noeud

Question

J'ai eu des problèmes avec l'accès de base de données Apache Cassandra via printemps-données-cassandra:

• Parfois, le serveur ne peut pas se connecter à la base de données au début - en général, il travaille dans la 2ème tentative
• une fois commencé, deux ou trois fois une heure, dans les moments aléatoires, quelques requêtes échouent avec délai d'attente et il continue à travailler bien
• Enfin, après quelques heures, le conducteur commence à refuser systématiquement demandes, les délais d'attente de rapports - et le serveur doit être redémarré

L'application est une petite application serveur Spring Boot (1.4.0) à l'aide de données Cassandra Spring (et essayé 1.4.4 1.4.2). L'application recueille les données des clients distants et implémente une interface graphique d'administration basée sur une interface REST côté serveur, incluant un tableau de bord préparé toutes les 10 secondes en utilisant Spring @Scheduled et en fournissant des données aux clients (navigateurs) via le protocole websocket. Le trafic est sécurisé en utilisant HTTPS et l'authentification bilatérale (certificats serveur + client). L'état actuel de l'application est testé dans une configuration avec une base de données (2.2.8), fonctionnant sur le même serveur de nuage (connexion via l'adresse de boucle de retour 127.0.0.1) ayant Ubuntu 14.04 OS. Un couple de clients de test crée une charge entraînant l'insertion d'environ 300 000 enregistrements de base de données par heure (enregistrements de détails 50k maître et 5x50k), en téléchargeant des données toutes les 5 secondes environ. Le tableau de bord traque la dernière heure de trafic et crée des statistiques. L'utilisation moyenne du processeur de l'utilitaire sar est d'environ 10%. La taille actuelle de la base de données est d'environ 25Go.

Les insertions de données sont faites en petites séries - j'ai essayé aussi des écritures individuelles mais le problème n'a pas disparu, juste l'utilisation du CPU a augmenté d'environ 50% tout en testant avec des écritures simples.

J'ai fait beaucoup de recherches de Google sur le sujet et je n'ai rien trouvé de spécifique, mais j'ai essayé pas mal de conseils, par exemple. mettre le nom du schéma dans toutes les requêtes et quelques options de configuration - avec apparemment aucun effet sur le résultat final (serveur bloqué nécessitant un redémarrage). Le serveur a fonctionné pendant environ 30 heures, mais il est parfois bloqué dans un délai de 1 à 2 heures, généralement de 7 à 10 heures avant que le pilote ne soit bloqué, sans motif évident dans la période de fonctionnement.

J'ai surveillé le tas - rien de particulier à voir, aucune structure de données s'accumulant avec le temps. Server est exécuté avec -Xms2g -Xmx3g -XX: + PrintGCDetails

L'erreur apparaissant est finalement:

Caused by: com.datastax.driver.core.exceptions.NoHostAvailableException: All host(s) tried for query failed (tried: inpresec-cassandra/127.0.1.1:9042 (com.datastax.driver.core.OperationTimedOutException: [inpresec-cassandra/127.0.1.1:9042] Operation timed out)) 
     at com.datastax.driver.core.RequestHandler.reportNoMoreHosts(RequestHandler.java:217) ~[cassandra-driver-core-2.1.9.jar!/:na] 
     at com.datastax.driver.core.RequestHandler.access$1000(RequestHandler.java:44) ~[cassandra-driver-core-2.1.9.jar!/:na] 
     at com.datastax.driver.core.RequestHandler$SpeculativeExecution.sendRequest(RequestHandler.java:276) ~[cassandra-driver-core-2.1.9.jar!/:na] 
     at com.datastax.driver.core.RequestHandler$SpeculativeExecution$1.run(RequestHandler.java:374) ~[cassandra-driver-core-2.1.9.jar!/:na] 
     ... 3 common frames omitted 

Ce que j'ai aussi remarqué que le processus cassandra rapporte le correspondant de la taille de la mémoire virtuelle à peu près la taille de la base de données - je l'ai remarqué quand la base de données était autour de 12GB et il a fidèlement suivi la taille de la base de données - pas sûr si cela a quelque chose à voir avec le problème du serveur. La partie résidente de la base de données est comprise entre 2 et 3 Go. La partie résidente du serveur est généralement comprise entre 1,5 et 2,5 Go. La mémoire totale du serveur de cloud est de 8 Go. Avant d'exécuter Cassandra directement dans le système d'exploitation VM hôte, je l'exécutais dans Docker et j'avais le même problème - quitter Docker pour exclure Docker de la "liste des suspects".

Si quelqu'un avait quelque chose de similaire, j'apprécierais des informations ou des conseils.

Answer 1

Le problème a apparemment été résolu en mettant à jour Netty et en fournissant la prise en charge du protocole epoll à utiliser à la place du repli par défaut sur NIO. A l'origine il y avait en pom.xml:

<dependency> 
    <groupId>io.netty</groupId> 
    <artifactId>netty-all</artifactId> 
    <version>4.0.9.Final</version> 
</dependency> 

Maintenant, cela a été changé à:

<dependency> 
     <groupId>io.netty</groupId> 
     <artifactId>netty-all</artifactId> 
     <version>4.0.29.Final</version> 
    </dependency> 

    <dependency> 
     <groupId>io.netty</groupId> 
     <artifactId>netty-transport-native-epoll</artifactId> 
     <version>4.0.29.Final</version> 
     <!-- Explicitly bring in the linux classifier, test may fail on 32-bit linux --> 
     <classifier>linux-x86_64</classifier> 
     <scope>test</scope> 
    </dependency> 

ajouter la deuxième spécification pour l'inclusion explicite du soutien epoll, comme sugested here.

Après ce changement, le message d'origine figurant dans le fichier journal:

com.datastax.driver.core.NettyUtil  : Did not find Netty's native epoll transport in the classpath, defaulting to NIO. 

a changé en:

com.datastax.driver.core.NettyUtil  : Found Netty's native epoll transport in the classpath, using it 

Depuis lors, il n'y a pas eu des échecs aléatoires - essayé « tuer » le DB connexion en créant des requêtes extra-larges plusieurs fois - il a consciencieusement signalé une erreur de mémoire - puis récupéré.