Apache Pulsar 中异常日志导致的性能问题分析与解决方案

问题背景

在 Apache Pulsar 2.10 版本中，当系统遇到网络连接问题时，特别是与远程复制集群或生产者连接失败的情况下，会出现严重的性能下降问题。这一问题表现为：

• 异常高的发布延迟
• 频繁且长时间的 GC 停顿（超过1分钟）
• 大量 CPU 资源被占用

问题根源分析

问题的核心在于异常处理机制的设计缺陷。当 Pulsar 客户端或 broker 遇到连接问题时，会生成大量嵌套的异常对象，这些异常对象在转换为字符串时会产生指数级增长的字符串处理操作。

具体表现为：

1. 当创建全局主题时，如果远程复制集群不可达，系统会不断尝试启动复制生产者
2. 每次尝试失败都会生成包含完整调用栈的异常对象
3. 这些异常对象在转换为字符串时递归调用 toString() 方法
4. 最终生成的异常字符串可能达到数万字符长度

技术细节

从线程转储中可以清楚地看到问题所在：

• IO 线程大部分时间都消耗在 java.lang.StringLatin1.replace() 方法上
• 异常对象的 toString() 方法被递归调用多达15层
• 每个异常对象都包含完整的错误链信息，导致字符串处理复杂度呈指数增长

这种设计导致了三个严重后果：

1. CPU 资源被大量消耗在字符串处理上
2. 生成了大量临时字符串对象，引发频繁GC
3. IO 线程被阻塞，无法处理正常请求，导致整体延迟上升

解决方案

要解决这一问题，需要从以下几个方面进行改进：

1. 异常信息简化：重写 PulsarClientException 的 toString() 方法，避免递归调用和完整错误链的输出

2. 日志级别调整：对于预期的连接失败情况，应该使用 DEBUG 级别而非 WARN 级别记录日志

3. 连接重试优化：实现指数退避机制，避免短时间内频繁重试

4. 资源隔离：将复制相关的操作与核心IO操作隔离，使用独立的线程池处理

5. 异常对象池化：对于频繁抛出的相同类型异常，考虑使用对象池减少对象创建开销

实施建议

对于正在使用 Pulsar 2.10 版本的用户，建议：

1. 监控系统中是否存在大量 "Failed to create remote producer" 警告日志
2. 检查是否有不可达的复制集群配置
3. 临时解决方案可以调整相关日志级别为 ERROR 或关闭
4. 长期解决方案是升级到修复该问题的后续版本

总结

这个案例展示了异常处理不当可能导致的系统性性能问题。在分布式系统中，网络问题是常态而非异常，因此异常处理路径必须经过精心设计，确保不会因为错误处理而影响系统核心功能。Apache Pulsar 社区已经意识到这一问题，并在后续版本中进行了优化。