运维经典案例学习之GitLab官网在线仓库SSH连接故障排查和经验总结( 八 )_GitLab在线仓库服务是世界上最大的Git

HAProxy为其前端侦听器提供了一个很好的\"速率限制会话\"选项。配置后，它会限制前端将传递给后端的每秒新TCP连接数，并在TCP套接字上保留其他连接。如果传入速率超过限制（每毫秒测量），则新连接将被延迟。 TCP客户端（在这种情况下为SSH）只是在建立TCP连接之前看到延迟，这样不会有太大影响，只要总体从未超过限制太长时间。由于Gitlab有27个SSH后端和18个HAproxy前端（16个主要，两个alt-ssh），并且前端之间没有做过速率限制优化，调整比较麻烦，必须考虑新的SSH会话需要多长时间通过身份验证：假设MaxStartups为150 ，如果auth阶段需要两秒钟，每秒只能向每个后端发送75个新会话。计算速率限制需要四个数量：两种服务器类型的数量， MaxStartups的值和T ，这是SSH会话进行身份验证所需的时间。 T值很关键，但只能估计。最后配置为每个前端的速率限制大约为112.5 ，并向下舍入到110 。

调整部署后，一切都OK了？错误连接数应该为零，但是，实际上，这个配置并没有对错误率有明显影响。陷入深深的沉思，一定错过了了啥！

所以回到日志（最终是HAProxy指标），确保能够验证速率限制是否生效了，并且历史显示这个数字已经更高，所以成功地约束了发送连接的速率。但显然这个比率仍然太高，它还不足以接近正确的数字，以产生可衡量的影响。