HAProxy的热重新配置仍会导致请求失败,有什么建议吗?

Jas*_*son 3 configuration reload haproxy

我发现当流量很高时,使用这样的命令仍然有失败的请求

haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
Run Code Online (Sandbox Code Playgroud)

热重新加载更新的配置文件.

以下是使用webbench的压力测试结果:

/usr/local/bin/webbench -c 10 -t 30 targetHProxyIP:1080
Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET targetHProxyIP:1080
10 clients, running 30 sec.

Speed=70586 pages/min, 13372974 bytes/sec.
**Requests: 35289 susceed, 4 failed.**
Run Code Online (Sandbox Code Playgroud)

我跑命令

haproxy -f /etc/haproxy.cfg -p /var/run/haproxy.pid -sf $(cat /var/run/haproxy.pid)
Run Code Online (Sandbox Code Playgroud)

在压力测试期间多次.

在haproxy文档中,它提到了

他们将收到SIGTTOU 611信号,要求他们暂时停止收听端口,以便新的612进程可以抓住它们

所以有一个时间段旧的进程没有在PORT上监听(比如说80)并且新的进程还没有开始收听PORT(比如80),并且在这个特定的时间段内,它将导致新的进程连接失败,有意义吗?

那么是否有任何方法可以使haproxy的配置重新加载,而不会影响现有连接和新连接?

Wil*_*eau 7

在最近实现SO_REUSEPORT(3.9+)的最新内核中,此死时间不再存在.虽然已有10年的旧内核可用补丁,但很明显许多用户无法修补其内核.如果您的系统更新,那么新进程将在请求前一个进程释放端口之前成功尝试bind(),然后有一个时间段,两个进程都绑定到端口而不是进程.

在关闭它时,连接到达离开进程的队列的可能性仍然很小.但是没有可靠的方法可以阻止这种情况发生.