Apache Storm地址占用异常问题求助及原因排查

问题现象 #

部署Apache Storm拓扑时反复出现端口占用报错，导致新拓扑无法启动：

2022-11-07 06:34:30.977 o.a.s.m.n.Server main [INFO] Create Netty Server Netty-server-localhost-6704, buffer_size: 5242880, maxWorkers: 1
2022-11-07 06:34:31.566 o.a.s.u.Utils main [ERROR] Received error in thread main.. terminating worker...
java.lang.Error: java.security.PrivilegedActionException: java.net.BindException: Address already in use
    at org.apache.storm.utils.Utils.handleUncaughtException(Utils.java:663) ~[storm-client-2.4.0.jar:2.4.0]
    at org.apache.storm.utils.Utils.handleWorkerUncaughtException(Utils.java:671) ~[storm-client-2.4.0.jar:2.4.0]
    at org.apache.storm.utils.Utils.lambda$createWorkerUncaughtExceptionHandler$3(Utils.java:1058) ~[storm-client-2.4.0.jar:2.4.0]
    at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1055) [?:?]
    at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1050) [?:?]
    at java.lang.Thread.dispatchUncaughtException(Thread.java:2002) [?:?]

排查发现：

• Supervisor机器的/storm/workers目录存在未清理的旧worker文件夹
• Supervisor启动worker后很快进入kill-blob-update状态并清理资源，但worker实际尚未完成加载，导致残留进程占用端口；生产环境中甚至出现启动2秒就被清理的情况

深层原因分析 #

1. changingBlobs触发逻辑
   当Nimbus推送的拓扑Blob资源（如拓扑代码包、依赖配置）发生变更时，Supervisor会将dynamicState.changingBlobs标记为非空，触发当前slot的container杀死逻辑。这种变更可能来自：

• 拓扑重新部署时的Blob更新
• Nimbus侧的Blob存储异常导致的重复推送
• Supervisor与Nimbus间的网络抖动，引发重复的Blob状态同步

2. 启动-清理时序不匹配
   小型QA环境资源（CPU、内存）有限，worker加载拓扑依赖、初始化组件的耗时远超过生产环境，但Supervisor的相关超时配置未适配：

• 默认的worker启动超时过短，Supervisor判定worker启动失败或需要更新，提前触发kill
• worker被kill后，进程未完全终止（如JVM优雅关闭耗时过长、线程僵死），残留进程持续占用端口

3. 残留资源清理不彻底
   Supervisor在kill worker后，仅等待supervisor.worker.shutdown.sleep.secs时长就结束清理流程，未确认进程是否完全退出；同时旧worker目录未被自动删除，残留文件可能影响后续启动。

解决方案 #

一、调整Blob相关配置，避免误触发kill #

1. 延长Nimbus Blob删除延迟，减少不必要的变更推送：
   在storm.yaml中修改：

   nimbus.topology.blobstore.deletion.delay.ms: 300000  # 从120000调整为5分钟
   

2. 调整Supervisor的Blob更新检测间隔，降低检测频率：
   添加配置：

   supervisor.blobstore.check.interval.secs: 60  # 默认可能为10秒，调整为1分钟
   

二、优化worker启动与清理的时序配置 #

1. 增加worker启动超时时间，适配QA环境的慢启动：
   添加配置：

   supervisor.worker.start.timeout.secs: 120  # 默认可能为60秒，调整为2分钟
   

2. 延长worker关闭等待时长，并启用强制清理：
   修改现有配置：

   supervisor.worker.shutdown.sleep.secs: 120  # 从60调整为2分钟
   supervisor.worker.shutdown.force.kill.after.secs: 30  # 添加，等待120秒后强制kill进程
   

三、手动清理残留资源（应急方案） #

1. 查找并杀死占用端口的残留进程：

   # 替换为实际端口号，如6704
   lsof -i :6704 | grep -v PID | awk '{print $2}' | xargs kill -9
   

2. 删除残留的worker目录：

   rm -rf /data/ansible/storm/workers/*
   

四、补充进程健康检查配置 #

添加Supervisor对worker进程的健康检测，及时清理僵死进程：

supervisor.worker.health.check.interval.secs: 30
supervisor.worker.health.check.timeout.secs: 10

当前配置参考（已标注建议修改项） #

storm.zookeeper.servers:
  - storm-nimbus-cloud-qa1
  - storm-nimbus-cloud-qa2
  - storm-nimbus-cloud-qa3

nimbus.seeds: ["storm-nimbus-cloud-qa1", "storm-nimbus-cloud-qa2", "storm-nimbus-cloud-qa3"]
storm.local.dir: /data/ansible/storm
supervisor.slots.ports:
  - 6700
  - 6701
  - 6702
  - 6703
  - 6704

storm.log.dir: "/data/ansible/storm_logging"

nimbus.childopts: "-Xmx512m -Djava.net.preferIPv4Stack=true"

ui.childopts: "-Xmx512m -Djava.net.preferIPv4Stack=true"
ui.port: 8080

supervisor.childopts: "-Xmx512m -Djava.net.preferIPv4Stack=true"
supervisor.cpu.capacity: 200.0
supervisor.memory.capacity.mb: 3072.0

worker.childopts: "-Djava.net.preferIPv4Stack=true"
worker.heap.memory.mb: 512

topology.component.cpu.pcore.percent: 5.0

blacklist.scheduler.assume.supervisor.bad.based.on.bad.slot: false
# 建议修改：延长Blob删除延迟
nimbus.topology.blobstore.deletion.delay.ms: 300000
# 建议修改：延长关闭等待时长
supervisor.worker.shutdown.sleep.secs: 120
# 建议添加：强制kill超时
supervisor.worker.shutdown.force.kill.after.secs: 30
# 建议添加：worker启动超时
supervisor.worker.start.timeout.secs: 120
# 建议添加：Blob检测间隔
supervisor.blobstore.check.interval.secs: 60
scheduler.display.resource: true
storm.scheduler: "org.apache.storm.scheduler.resource.ResourceAwareScheduler"

logviewer.cleanup.interval.secs: 3600
logviewer.max.per.worker.logs.size.mb: 512
logviewer.max.sum.worker.logs.size.mb: 2560
logviewer.cleanup.age.mins: 20160

storm.messaging.netty.max_retries: 300
storm.messaging.netty.max_wait_ms: 10000
storm.messaging.netty.min_wait_ms: 1000

内容的提问来源于stack exchange，提问作者Mykyta Piddubskiy