知识库

Neo4j 调试日志 (debug.log) 中 E_COUNT_EXCEEDED 警告消息的解释。

本文档旨在解释 Neo4j 可能写入其 debug.log 文件的 `E_COUNT_EXCEEDED` 警告消息。它还提供了一些监控和故障排除选项。

在运行 Neo4j 因果集群时，您可能会在 FOLLOWER 上看到以下错误

021-05-05 20:42:43.349+0530 WARN [o.n.c.c.BatchingMessageHandler] Raft in-queue dropping messages after: E_COUNT_EXCEEDED
2021-05-05 20:42:45.465+0530 INFO [o.n.c.c.BatchingMessageHandler] Raft in-queue not dropping messages anymore. Dropped 771 messages.
2021-05-05 20:42:46.250+0530 WARN [o.n.c.c.BatchingMessageHandler] Raft in-queue dropping messages after: E_COUNT_EXCEEDED
2021-05-05 20:42:48.461+0530 INFO [o.n.c.c.BatchingMessageHandler] Raft in-queue not dropping messages anymore. Dropped 958 messages.
2021-05-05 20:42:49.587+0530 WARN [o.n.c.c.BatchingMessageHandler] Raft in-queue dropping messages after: E_COUNT_EXCEEDED
2021-05-05 20:42:50.829+0530 INFO [o.n.c.c.BatchingMessageHandler] Raft in-queue not dropping messages anymore. Dropped 541 messages.
2021-05-05 20:42:59.392+0530 WARN [o.n.c.c.BatchingMessageHandler] Raft in-queue dropping messages after: E_COUNT_EXCEEDED
2021-05-05 20:42:59.744+0530 INFO [o.n.c.c.BatchingMessageHandler] Raft in-queue not dropping messages anymore. Dropped 163 messages.

您也可能经常看到这些消息

2021-05-05 20:42:59.392+0530 INFO [o.n.c.c.s.CommandApplicationProcess] BatchSize{min=1.0, max=7.0, avg=1.1328449328449361, count=4096}
2021-05-05 20:42:59.398+0530 INFO [o.n.c.c.s.CommandApplicationProcess] BatchSize{min=15.0, max=15.0, avg=15.0, count=1}

`BatchSize` 信息消息报告应用了几个包含 >4000 个操作的批次，队列的默认大小为 4096（`causal_clustering.state_machine_flush_window_size` 参数）。每当我们超过队列的大小，我们就会看到 `E_COUNT_EXCEEDED`。

实际上，这意味着 Raft 消息正在进入队列以进行处理，但队列的填充速度快于 Neo4j 处理 Raft 消息的速度。

此队列的大小由 `causal_clustering.raft_in_queue_size` 设置。在上面的示例中，我们看到队列正在填满。结果，消息被丢弃，然后排空足够的空间以再次接受消息，然后再次填满。Neo4j 不断重复此过程。

此问题等同于临时网络分区。它应该能够恢复，但它表明存在性能问题。

`E_COUNT_EXCEEDED` 警告通常表示工作负载对于集群来说过高。

此外，在领导者节点上，我们可能会观察到这种情况

2021-05-05 20:42:59.658+0530 INFO [o.n.c.c.r.RaftReplicator] Replication attempt 2 to leader MemberId{46531432}: DistributedOperation{content=TransactionRepresentationReplicatedTransaction{tx=PhysicalTransactionRepresentation[masterId:-1,authorId:-1,timeStarted:1620227030656,latestCommittedTxWhenStarted:3999325909,timeCommitted:1620227030657,lockSession:2,additionalHeader:[]commands.length:2}, globalSession=GlobalSession{sessionId=2d76658e-cb25-4d33-b46d-4f163c2e04c4, owner=MemberId{46531432}}, operationId=LocalOperationId{localSessionId=821, sequenceNumber=525762}}
2021-05-05 20:42:59.789 INFO [o.n.c.c.r.RaftReplicator] Replication attempt 2 to leader MemberId{46531432}: DistributedOperation{content=TransactionRepresentationReplicatedTransaction{tx=PhysicalTransactionRepresentation[masterId:-1,authorId:-1,timeStarted:1620227030659,latestCommittedTxWhenStarted:3999325909,timeCommitted:1620227030662,lockSession:2,additionalHeader:[]commands.length:2}, globalSession=GlobalSession{sessionId=2d76658e-cb25-4d33-b46d-4f163c2e04c4, owner=MemberId{46531432}}, operationId=LocalOperationId{localSessionId=218, sequenceNumber=569728}}

这组消息表明领导者节点无法将 Raft 消息复制到跟随者节点。

同样，这表明工作负载对于集群来说过高。事务正在影响领导者节点，而领导者节点又将这些事务复制到所有跟随者节点。复制遵循此处描述的 Raft 协议：https://raft.github.io/raft.pdf

但是，工作负载过高，导致跟随者节点的队列填满，最终导致领导者节点上的复制丢弃出站消息。

故障排除和监控

首先，诊断此问题可能很复杂，因此我建议您向 Neo4j 支持团队提交工单。

在与支持团队合作之前，您可以探查以下区域以查找瓶颈迹象

1) 磁盘。我们正在将 Raft 队列排空到磁盘，因此您需要确保有足够的 I/O 容量来满足对集群的写入操作。我建议使用 iostat 监控磁盘。以下命令将提供最佳概述

iostat -x -c -d -t 1 600 >> $(hostname -i)-iostat.out

此处最重要的指标是队列深度。队列深度是指挂起的访问操作数。对于较长时间内 > 1 的任何值，我倾向于将其视为瓶颈的指示。这意味着成员在写入事务和读取数据时都会变慢。

还需要确定相关 Neo4j 目录的映射位置。例如，`dbms.directories.data` 和 `dbms.directories.transaction.logs.root` 将存储在某些设备上，但除非我们知道哪些设备，否则我们无法确定饱和的设备是否是我们感兴趣的设备。它们可能与其他应用程序或进程完全无关！

技术支持可以对此提供建议，并且它确实取决于设备类型。

2) 有一些 Raft 消息处理指标可能提供有关什么内容缓慢或被阻塞的见解。`neo4j.causal_clustering.core.message_processing_delay` 和 `neo4j.causal_clustering.core.message_processing_timer` 在这种情况下将很有帮助。

3) 事务的历史监控。我建议使用您首选的监控工具绘制一段时间内的事务数量图表。此处的目的是发现可能与问题开始时间相吻合的任何趋势。也许事务数量出现激增，这对应于 `E_COUNT_EXCEEDED` 的开始？

解决方案

解决此问题的方法取决于问题的根本原因。

如果问题是由 I/O 瓶颈引起的，则可以隔离 Neo4j 目录以使用其自己的设备。例如，您可以将 `~data` 和 `~transactions` 分割到单独的磁盘上。Neo4j 4.2 及更高版本允许操作员将 Raft 日志放在单独的设备上。

但最终，它可能是由超出集群物理资源的工作负载配置文件引起的。