RocketMQ报Send message timeout是Broker磁盘满了吗？-常见问题-PHP中文网

“send message timeout”不直接等于磁盘满，但磁盘使用率≥90%会触发disk_full_bit导致broker只读，引发超时；需结合df、日志、jvm、网络、i/o及管理命令综合排查。

rocketmq报send message timeout是broker磁盘满了吗？

如果您尝试发送消息到RocketMQ，但收到“Send message timeout”错误，并不确定是否由Broker磁盘满导致，则需注意：该超时异常本身不直接等同于磁盘满，但磁盘满可能间接引发超时。以下是识别与区分该问题的步骤：

一、确认是否为磁盘满引发的连锁反应

当Broker磁盘使用率超过90%（默认阈值）时，RocketMQ会置位DISK_FULL_BIT标志，使broker进入只读状态，拒绝新消息写入；此时Producer若持续重试发送，可能因等待响应超时而抛出“Send message timeout”。该现象常伴随日志中明确提示“service not available now. It may be caused by one of the following reasons: the broker's disk is full [CL: 0.91 CQ: 0.91 INDEX: 0.91]”。

1、登录Broker所在服务器，执行df -h命令，检查/home、/var或storePathRootDir所在挂载点的使用率。

2、若任一关键路径使用率≥85%，则触发强制清理逻辑；≥90%则阻断写入，此时即使df显示仍有空间，也可能因文件系统预留块或inode耗尽导致实际不可写。

3、查看Broker日志（如logs/rocketmqlogs/broker.log），搜索disk is full或DISK_FULL_BIT关键词，确认是否存在相关标记事件。

二、排查非磁盘因素导致的超时

“Send message timeout”更常见于网络或服务响应延迟场景，而非存储瓶颈。Broker虽未报磁盘满，但若其线程阻塞、GC频繁、CommitLog刷盘卡顿或网络链路丢包，均会导致响应延迟超过客户端设置的sendMsgTimeout（默认3000ms）。

1、检查Broker进程JVM状态：执行jstat -gc <pid></pid>，观察YGC次数、FGC频率及堆内存使用率，确认是否存在频繁GC或OOM前兆。

2、验证网络连通性与延迟：在Producer机器上对Broker监听端口（如10911）执行telnet <broker-ip> 10911</broker-ip>或nc -zv <broker-ip> 10911</broker-ip>；再用ping <broker-ip></broker-ip>和mtr <broker-ip></broker-ip>定位网络抖动节点。

3、审查Broker端请求处理线程池：在logs/rocketmqlogs/broker.log中搜索TIMEOUT_CLEAN_QUEUE或dispatch behind，判断是否因消费队列分发延迟或CommitLog落盘滞后造成响应积压。

三、检查客户端配置与行为

超时可能是客户端侧参数失配所致，与Broker磁盘状态无关。Producer若未正确配置重试与超时策略，在短暂服务抖动时即快速失败，掩盖真实根因。

1、确认Producer实例中DefaultMQProducer.setSendMsgTimeout(3000)是否被误设为过小值（如500ms），导致正常网络往返亦超时。

2、检查是否启用了同步发送（send()）且未配置合理重试次数：DefaultMQProducer.setRetryTimesWhenSendFailed(2)；若关闭重试且首次即超时，日志将仅显示timeout而不暴露底层SERVICE_NOT_AVAILABLE。

3、核实Topic路由信息是否完整：执行sh mqadmin topicRoute -n <nameserver-addr> -t <topic-name></topic-name></nameserver-addr>，确认返回的Broker地址列表中包含预期节点，排除因路由缺失导致请求发往不可达地址而空等超时。