运维经典案例学习之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% , 即每天几千 。 这比较好 , 但仍然高于期望 。 在解决其他一些操作问题之后 , 希望能够正式部署最小的变更 , 并且可以完全消除了错误 。
推荐阅读
- Ansible自动化运维
- 数据库紧急修复中 微盟系统遭遇自家核心运维破坏
- 爬虫学习之HttpClient练习
- 爬虫学习之HTTP协议初步了解
- 正则表达式学习之替换分组练习
- 正则表达式学习之分割字符及数量词练习
- Scala学习之基础函数
- Scala学习之数据类型和变量
- 编程学习之亲密数(C++描述)
- 企业级IT系统运维者如何才能体现真正价值?