知识库

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 警告通常意味着集群的工作负载过高。

此外，在 LEADER 上，我们可能会观察到这种情况

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

这组消息表明 LEADER 无法将 Raft 消息复制到 FOLLOWER。

同样，这表明集群的工作负载过高。事务到达 LEADER，然后 LEADER 将这些事务复制到所有 FOLLOWER。复制遵循此处描述的 Raft 协议：https://raft.github.io/raft.pdf

然而，工作负载过大，导致 FOLLOWER 队列填满，最终导致 LEADER 上的复制丢弃出站消息。

故障排除与监控

首先，诊断此问题可能很复杂，因此我建议您联系 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_EXCECEEDED 的出现相对应？

解决方法

解决此问题的方法取决于具体的问题。

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

然而，最终原因可能是工作负载配置文件过高，超出了集群的物理资源承受能力。

© . All rights reserved.