Bash脚本运行若干次后停滞问题求助

这种在VM快照重置+Siege压测场景下的间歇性SSH失效问题，我在运维自动化脚本里碰到过好几次，结合你的情况，给你几个针对性的排查和修复思路：

1. 开启SSH会话复用，规避连接限制 #

ESXi的SSH服务默认对频繁创建的新连接可能有隐性限制，多次自动化连接容易触发防护机制。建议开启SSH会话复用，减少新连接的创建频率：
在你的SSH命令中加入以下参数：

ssh -o ControlMaster=auto -o ControlPath=/tmp/ssh-%r@%h:%p -o ControlPersist=60s 10.204.15.168 "your_vm_reset_command"

这样后续的SSH请求会复用已建立的会话，既提升执行效率又降低连接被拒绝的概率。

2. 增加VM重置后的网络就绪等待逻辑 #

快照重置后，VM的网卡初始化、IP配置可能需要几秒时间完全就绪，如果脚本立刻执行后续操作，很容易因为网络未就绪导致后续SSH失败。可以在重置快照后加入等待检查：

# 等待VM SSH端口开放
until nc -zv 10.204.15.168 22; do
    echo "等待VM SSH端口就绪..."
    sleep 2
done

或者用ping检查网络连通性，确保VM完全恢复后再进行Siege压测。

3. 排查ESXi宿主机资源占用情况 #

虽然最后一次Siege看似正常，但压测可能耗尽了ESXi宿主机的CPU、内存或网络带宽，导致SSH服务无法响应。建议在脚本中加入资源监控：

# 压测前记录资源状态
ssh 10.204.15.168 'esxtop -n 1 | grep -E "CPU used|Mem used|Net throughput"' >> test_logs.txt
# 执行Siege压测
siege -c 50 -t 10m http://your_web_server
# 压测后再次记录资源状态
ssh 10.204.15.168 'esxtop -n 1 | grep -E "CPU used|Mem used|Net throughput"' >> test_logs.txt

如果发现压测后资源占用过高，可以调整Siege的并发数，或者给ESXi宿主机扩容资源，同时在压测后增加一段等待资源释放的时间（比如sleep 30）。

4. 重置VM后重启ESXi SSH服务 #

频繁的VM快照操作可能导致ESXi的SSH服务出现异常，比如连接池耗尽或进程挂起。可以在每次重置VM快照后，重启SSH服务：

ssh 10.204.15.168 '/etc/init.d/SSH restart'

如果长期出现这个问题，建议修改ESXi的SSH配置（/etc/ssh/sshd_config），调整MaxStartups参数（比如设置为10:30:60），允许更多的并发连接尝试。

5. 给SSH命令增加重试机制 #

脚本中缺少错误处理和重试逻辑，会导致单次SSH失败直接终止流程。可以给关键的SSH操作加上循环重试：

MAX_RETRIES=3
RETRY_COUNT=0
until [ $RETRY_COUNT -ge $MAX_RETRIES ]; do
    ssh 10.204.15.168 "your_command" && break
    RETRY_COUNT=$((RETRY_COUNT+1))
    echo "SSH操作失败，第$RETRY_COUNT次重试..."
    sleep 5
done
if [ $RETRY_COUNT -eq $MAX_RETRIES ]; then
    echo "SSH操作多次失败，终止脚本"
    exit 1
fi

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