Cassandra 错误：检测到泄漏

Posted 2023-03-22

【中文标题】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.