Spring Data Cassandra驱动程序在几个小时后被卡住，同一节点上有单节点数据库

Question

我通过spring数据Cassandra访问Apache Cassandra数据库时遇到了问题：

• 有时服务器在开始时无法连接到数据库-通常它在第二次尝试中工作
• 一旦开始，每小时几次，在随机时刻，很少有请求因超时而失败，然后它继续正常工作
• 最后，几个小时后，驱动程序开始持续拒绝请求，报告超时-需要重新启动服务器

该应用程序是一个使用Spring Data Cassandra的小型Spring Boot (1.4.0)服务器应用程序(试用过1.4.2和1.4.4)。该应用程序从远程客户端收集数据，并在服务器端基于REST接口实现一些管理GUI，包括通过使用Spring @Scheduled tasks每10秒准备一个仪表板，并通过websocket协议将数据传递给客户端(浏览器)。通过使用HTTPS和双向身份验证(服务器客户端证书)来保护流量。

应用程序的当前状态正在具有数据库（2.2.8）的设置中进行测试，该数据库（通过环回127.0.0.1地址连接）上运行，具有Ubuntu 14.04 OS。几个测试客户端会产生负载，导致每小时插入大约 300k 个数据库记录（50k 主记录和 5x50k 详细信息记录），每 5 秒左右上传一次数据。仪表板正在拖曳最后一小时的流量并创建统计信息。sar 实用程序的平均 CPU 使用率约为 10%。当前数据库大小约为 25GB。

数据插入是小批量进行的 - 我也尝试过单个写入，但问题并没有消失，只是在使用单个写入进行测试时CPU使用率增加了约50%。

我在Google上做了很多关于这个主题的“研究”，但没有发现任何具体的问题，但尝试了很多建议，例如在所有查询中输入模式名称和一些配置选项-显然对最终结果没有影响（阻塞的服务器需要重新启动）。服务器已运行了30小时左右，但有时会在1-2小时内被阻塞，通常在驱动程序被卡住之前运行7-10小时，在运行期间没有明显的模式。

我一直在监视堆 - 没有什么特别要看的，没有数据结构随着时间的推移而堆积。服务器使用 -Xms2g -Xmx3g -XX 运行：打印GC详细信息

最终出现的错误是：

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

我还注意到，cassandra进程报告的虚拟内存大小与数据库的大小大致匹配——我注意到数据库大约为12GB，它一直忠实地遵循数据库大小——不确定这是否与服务器问题有关。数据库的驻留部分在2到3GB之间。服务器的驻留部分通常为1.5-2.5GB。云服务器的总内存为8GB。

在直接在主机VM操作系统中运行Cassandra之前，我在Docker中运行它并遇到了同样的问题 - 从Docker中移出是为了将Docker从“嫌疑人列表”中排除。

如果有人有类似的东西，我将不胜感激。

Answer 1

这个问题显然已经通过升级Netty并提供支持要使用的epoll协议而不是默认回退到NIO来解决。最初在pom中.xml有：

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

现在已将其更改为：

    <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>

添加第二个规范，明确包含epoll支持，如这里所建议的。

此更改后，原始文件中将显示原始消息：

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

已更改为:

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

从那以后就没有出现过随机故障——几次试图通过创建超大查询来“杀死”DB连接——它忠实地报告了内存错误——然后就恢复了。