Cassandra 错误:检测到泄漏

Posted

技术标签:

【中文标题】Cassandra 错误:检测到泄漏【英文标题】:Cassandra ERROR: LEAK DETECTED 【发布时间】:2017-11-21 02:07:45 【问题描述】:

我有一个两节点 Cassandra 集群(版本:3.10)。 我试图从 SQL 读取数据并写入 Cassandra。一切都很好,但在某些时候我收到了这个错误 -

Exception in thread "main" com.datastax.driver.core.exceptions.TransportException: [/192.168.22.231:9042] Connection has been closed
        at com.datastax.driver.core.exceptions.TransportException.copy(TransportException.java:38)
        at com.datastax.driver.core.exceptions.TransportException.copy(TransportException.java:24)
        at com.datastax.driver.core.DriverThrowables.propagateCause(DriverThrowables.java:37)
        at com.datastax.driver.core.DefaultResultSetFuture.getUninterruptibly(DefaultResultSetFuture.java:245)
        at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:68)
        at com.datastax.driver.core.AbstractSession.execute(AbstractSession.java:43)
        at TableCreator.insertDataToCassandra(TableCreator.java:1037)
        at TableCreator.createTable(TableCreator.java:356)
        at DbMigration.main(DbMigration.java:25)
Caused by: com.datastax.driver.core.exceptions.TransportException: [/192.168.22.231:9042] Connection has been closed
        at com.datastax.driver.core.Connection$ConnectionCloseFuture.force(Connection.java:1215)
        at com.datastax.driver.core.Connection$ConnectionCloseFuture.force(Connection.java:1200)
        at com.datastax.driver.core.Connection.defunct(Connection.java:450)

Nodetool 状态显示两个节点都已启动且健康 -

Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address         Load       Tokens       Owns (effective)  Host ID                               Rack
UN  192.168.22.229  77.39 GiB  256          100.0%            335fc3a2-c21f-44ad-a937-487ba457c2fa  rack1
UN  192.168.22.231  77.39 GiB  256          100.0%            a5eaf96c-eaf9-4e2e-bd6b-6186ce944cd0  rack1

现在我无法连接到我的第一个节点 -

cqlsh --connect-timeout=30 192.168.22.231
Connection error: ('Unable to connect to any servers', '192.168.22.231': error(111, "Tried connecting to [('192.168.22.231', 9042)]. Last error: Connection refused"))

但我可以连接到第二台服务器。我试图检查 system.log 和 debug.log syatem.log

INFO [CompactionExecutor:4003] 2017-06-19 07:25:19,676 NoSpamLogger.java:91 - 达到最大内存使用量 (1.000GiB),不能 分配 1.000MiB 信息块 [IndexSummaryManager:1] 2017-06-19 07:28:02,222 IndexSummaryRedistribution.java:75 - 重新分配索引 摘要信息 [CompactionExecutor:4009] 2017-06-19 07:40:42,023 NoSpamLogger.java:91 - 达到最大内存使用量 (1.000GiB),不能 分配 1.000MiB 信息块 [CompactionExecutor:4015] 2017-06-19 07:56:04,582 NoSpamLogger.java:91 - 达到最大内存使用量 (1.000GiB),无法分配 1.000MiB INFO 的块 [CompactionExecutor:4021] 2017-06-19 08:11:26,674 NoSpamLogger.java:91 - 达到最大内存使用量 (1.000GiB),无法分配 1.000MiB 的块 INFO [服务线程] 2017-06-19 08:21:48,726 GCInspector.java:284 - ConcurrentMarkSweep GC 在 225 毫秒内。 CMS 老一代: 5813642680 -> 3194404296; Par Eden 空间:10360904 -> 347594616;面值 幸存者空间:83886080 -> 42514752

INFO [CompactionExecutor:4027] 2017-06-19 08:26:49,414 NoSpamLogger.java:91 - 达到最大内存使用量 (1.000GiB),不能 分配 1.000MiB 信息块 [IndexSummaryManager:1] 2017-06-19 08:28:02,341 IndexSummaryRedistribution.java:75 - 重新分配索引 摘要信息 [CompactionExecutor:4031] 2017-06-19 08:42:12,733 NoSpamLogger.java:91 - 达到最大内存使用量 (1.000GiB),不能 分配 1.000MiB INFO 的块 [服务线程] 2017-06-19 08:52:33,145 GCInspector.java:284 - ConcurrentMarkSweep GC 在 215 毫秒内。 CMS 老一代:5868761104 -> 3186639968; Par Eden 空间:9853592 -> 423279080; Par Survivor Space: 83886080 -> 45608368

INFO [CompactionExecutor:4037] 2017-06-19 08:57:34,632 NoSpamLogger.java:91 - 达到最大内存使用量 (1.000GiB),不能 分配 1.000MiB 的块

Debug.log

调试 [SlabPoolCleaner] 2017-06-19 09:12:59,260 ColumnFamilyStore.java:899 - size_estimates 的队列刷新: 78.229MiB (4%) on-heap, 0.000KiB (0%) off-heap DEBUG [PerDiskMemtableFlushWriter_0:6285] 2017-06-19 09:12:59,575 Memtable.java:461 - 写作 Memtable-size_estimates@1285230058(21.550MiB序列化字节,150876 ops, 4%/0% of on/off-heap limit), flushed range = (最小值(-9223372036854775808),最大值(9223372036854775807)]

调试 [MemtableFlushWriter:6230] 2017-06-19 09:12:59,618 ColumnFamilyStore.java:1197 - 刷新到 [BigTableReader(路径='/var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21460-big-Data.db')] (1 sstables, 2.340MiB), 最大 2.340MiB, 最小 2.340MiB

调试 [PerDiskMemtableFlushWriter_0:6285] 2017-06-19 09:12:59,895 Memtable.java:490 - 完成刷新 /var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21461-big-Data.db (15.813MiB) 用于提交日志位置 CommitLogPosition(segmentId=1496885272130, position=32411980)

调试 [MemtableFlushWriter:6231] 2017-06-19 09:13:00,077 ColumnFamilyStore.java:1197 - 刷新到 [BigTableReader(路径='/var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21461-big-Data.db')] (1 sstables, 2.340MiB), 最大 2.340MiB, 最小 2.340MiB

调试 [CompactionExecutor:4043] 2017-06-19 09:13:02,440 CompactionTask.java:255 - 压缩 (0b5956b0-5484-11e7-b5a8-01c062b805b9) 4 sstables [/var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21458-big,] 到水平= 0。在 6,349 毫秒内从 20.780MiB 到 13.916MiB(约为原始的 66%)。 读取吞吐量 = 3.273MiB/s,写入吞吐量 = 2.192MiB/s,行 吞吐量 = ~131,062/s。 12 个分区合并为 5 个。分区 合并计数为 2:4, 4:1,

调试 [CompactionExecutor:4043] 2017-06-19 09:13:02,440 CompactionTask.java:155 - 压缩 (0f221e81-5484-11e7-b5a8-01c062b805b9) [/var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21461-big-Data.db:level=0, /var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21460-big-Data.db:level=0, /var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21459-big-Data.db:level=0, /var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21458-big-Data.db:level=0, ]

调试 [CompactionExecutor:4043] 2017-06-19 09:13:08,453 CompactionTask.java:255 - 压缩 (0f221e81-5484-11e7-b5a8-01c062b805b9) 4 sstables [/var/lib/cassandra/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/mc-21462-big,] 到水平= 0。在 6,012 毫秒内从 20.775MiB 到 13.923MiB(约为原始的 67%)。 读取吞吐量 = 3.455MiB/s,写入吞吐量 = 2.316MiB/s,行 吞吐量 = ~131,059/s。总共 8 个分区合并为 5 个。分区 合并计数为 1:4, 4:1,

任何建议都会有所帮助和赞赏。

【问题讨论】:

【参考方案1】:

您的内存不足(日志的第一行)。奇怪的是,这是一个信息,而不是一个警告。当您内存不足时,系统可能仍然健康,但无法接受任何新连接。添加更多内存,直到您有足够的内存来稳定运行。

【讨论】:

感谢您的回复,我将 file_cache_size_in_mb 从 1024 更改为 2048 并重新启动 Cassandra,重新启动日志指出“SSTable..打开的文件太多”,我试图通过增加打开文件描述符的数量来管理它使用命令 ulimit -n 100000.

以上是关于Cassandra 错误:检测到泄漏的主要内容,如果未能解决你的问题,请参考以下文章

cassandra 查询超时

Oracle 到 Apache Cassandra 数据迁移

cassandra集群缩容与剔除问题节点

cassandra安装配置

Cassandra 不使用本机方法

java.lang.Exception:检测到明显的连接泄漏错误