运维经典案例学习之GitLab官网在线仓库SSH连接故障排查和经验总结( 十 )

经验四:尽管很违常理 , 但是MaxStartups似乎对性能影响很小 , 即使它的提升远远高于默认值时 。

如果有必要 , 这可能是未来可以提供的一个更大水平 。 如果它提高到成千上万或数万 , 可能会注意到其影响问题 。

这说明对T的估计 , 建立和验证SSH会话的时间是什么?通过测试知道200对MaxStartups来说还不够 , 250就足够了 , 可以计算出T可能在2.7到3.4秒之间 。 。

善后

事后通过查看日志 , 经过一番思考后 , 发现可以识别出一个特定的故障模式:t_state为SD , b_read(客户端读取的字节数)为0 。 如上所述 , GitLab每天处理大约26-28万个SSH连接 。 令人不快的是 , 在最严重情况下 , 大约有1.5%的连接被严重丢弃 。 显然 , 问题比开始时意识到的要大 , 之前无法确定这一点(当发现t_state =\"SD\"表示问题时 , 没有想到这一点) 。

经验六:尽早测量错误占比

如果能意识到问题的严重程度 , 可能会更早地优先考虑该问题 , 尽管它仍然依赖于了解识别特征 。 从好的方面来看 , 在遇到MaxStartups和速率限制后 , 错误率降至0.001% , 即每天几千 。 这比较好 , 但仍然高于期望 。 在解决其他一些操作问题之后 , 希望能够正式部署最小的变更 , 并且可以完全消除了错误 。

推荐阅读