今天暴风雨袭击了杭州, 而昨天暴风雨 (高并发问题) 席卷了园子, 留下一片狼藉.
在前天傍晚, 我们进行了 .net core 版博客站点的第二次发布尝试, 在发布后通过 kestrel 直接监听取代 nginx 转发解决了高并发下的 1 秒延迟问题, 成功地顶住了下班前的访问小高峰, 但这只是一场大雨, 第二天的上午和下午的暴风雨 (访问高峰中的高并发) 才是真正的考验.
昨天, 面对暴风雨, 我们哼都不敢哼一声 "让暴风雨来得更猛烈些吧", 只是一直不停地默念 "让暴风雨快点过去吧", 尤其在下午的暴风雨袭击下, 跑在 docker swarm 上 .net core 版博客系统溃不成军, 大量请求响应速度极不稳定, 时而快如闪电(10ms 左右), 时而慢如蜗牛(10s, 30s 甚至超时). 与第一次发布时不一样, 不仅博客应用容器外是暴风雨, 容器内也是暴风雨, 在容器内用 curl 命令访问与外部用浏览器访问问题一样(难不成真的是 docker swarm 网络的问题? kestrel 监听取代 nginx 转发只是将网络并发负载从 nginx 容器转到了 kestrel 所在的博客应用容器... 有待验证.)
昨天 17:30 左右并发量回落到一定程度之后, 暴风雨飘然而去, 园中立刻风平浪静, 晴空万里, 下午的那场暴风雨宛如梦中.
在暴风雨过后, 我们查看了服务器的 Linux 系统日志, 发现很多下面的日志, 而且都发生在暴风雨期间.
- Aug 8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet
- Aug 8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet
- Aug 8 15:57:12 blog-swarm-n3 kernel: nf_conntrack: table full, dropping packet
当时 docker swarm 集群中一共 5 台 worker 节点服务器, 统计了一下每台服务器出现 "table full" 日志的数量.
- blog-swarm-n3: 2149
- blog-swarm-n4: 1964
- blog-swarm-n5: 2451
- blog-swarm-n6: 2095
- blog-swarm-n7: 0
咦, 怎么有 1 台服务器为 0? 哦, 原来是这台没有挂上所有负载均衡, 只承受了 2/3 左右的流量, 虽然下的暴风雨, 但对这台服务器来说只是一场大雨.
针对上面的日志, 昨天我们晚上我们调整了 Linux 内核的 2 个设置置(参考文档), 在 /etc/sysctl.conf 中添加
- net.netfilter.nf_conntrack_max = 655350
- net.netfilter.nf_conntrack_tcp_timeout_established = 1200
这个调整成为我们今天唯一的希望, 但早上访问高峰来临的时候, 迎接我们的不是喜出望外, 而是昔日重来...
在熟悉的暴风雨面前, 我们面临着艰难的选择, 放弃 - 退回 Windows 上的 .net framework 版博客系统, 还是坚持 - 至少要找到一种能抵挡一定程度暴风雨的临时解决方法?
那台没有 "table full" 日志的服务器给了我们启发 -- 分而治之, 将暴风雨变成每一台服务器的大雨, 拆分流量到不同的服务器, 减少每台服器的并发连接数, 今天就是通过这个临时的笨方法扛住了暴风雨, 大量减少了响应速度慢的情况, 所以到现在 .net core 版博客站点依然在线.
在抗过了今天上下午访问高峰的暴风雨后, 杭州也被暴风雨袭击了, 因为有了房子, 任凭外面风吹雨打, 我们可以坐在房间里一边敲着代码, 一边凝听窗外的风声雨声. 对于这次遇到的高并发问题, 我们相信总有一天会为我们的博客系统建造好房子, 在暴风雨的风吹雨打中潇洒地在日志中写着 "让暴风雨来得更猛烈些吧".
来源: https://www.cnblogs.com/cmt/p/11328141.html