遇到个高并发的问题

2022-03-15 10:11:58 +08:00
 luxinfl

配置:5 个 slb ,10 台 16C64G 的服务器。
接口:一个天气页面的运营位查询接口。业务逻辑是本地缓存+一次 get 请求。本地缓存时间可以忽略不计。
后端服务配置:默认 tomcat 设置,200msms 的获取连接时间,200ms 建立连接时间,500ms 的数据传输时间,默认最大路由数 30 。
现状:六点到八点间每台 slb 的 ttps 稳定在 80w 左右,某个时间会升高到 100w+。此时服务时延会变高(10ms 升到 1600ms 左右),错误数也会升高,接口成功率在 99.95%左右。  

有什么办法可以让这段时间的时延降低麽

4698 次点击
所在节点    程序员
41 条回复
ymy3232
2022-03-15 15:24:21 +08:00
1.resttemplate 的连接池
2.带宽
3.获取用户标签的时长
ElmerZhang
2022-03-15 15:30:24 +08:00
首先就你的描述来看,tps 80w 是不可能的。tps 全称 Transactions per second ,单台限 30 连接,每个请求耗时 10ms 的话,单台理论最高 tps 是 1000 * 30 / 10 = 3000 。10 台后端加起来也就 30000 。
如果是 transactions per 5 minutes 的话还合理一点,那样 80W 的时候 tps 是 2666 ,100W 的时候 tps 是 3333 。

如果你的时延是在 slb 上统计的,先看看后端的连接数用满了没。
如果你的时延是在后端统计的话,有可能是所依赖的某项服务或者连接数之类的达到瓶颈了导致的。
byte10
2022-03-15 15:46:24 +08:00
@haython 我也觉得,单机 80w 不太可能,8w/s 感觉都难,除非真的是 hello world 。
@luxinfl 要不看看用 NIO 吧 https://www.bilibili.com/video/BV1FS4y1o7QB ,像你那样的机器,单机十万问题不大,另外 http 请求是一问一答的,所以你要大并发吞吐量,就需要增加很多连接数,你用的 tomcat 是多线程模式把?多线程设置多少?你可以看看 cpu 占用率和内存占用率。cpu 没满,那就是线程数不够了,IO 密集型,线程要多。不过最好还是 NIO 去实现把,看看我的视频有说明 NIO 是怎么解决网络 IO 时长的问题的。
luxinfl
2022-03-15 15:53:13 +08:00
@haython 我发现了,是这个 nginx 总的 tps 。。。
luxinfl
2022-03-15 15:59:40 +08:00
@ElmerZhang 是五分钟统计的一次。。而且还错看了整个 nginx 的 tps 。。
sampeng
2022-03-15 16:03:58 +08:00
为啥都在纠结 tps 是多少。。。不去给个思路排查?
就算是 tps8w ,难道就不算高并发就不是问题了?


这个链路有两个口,一个是 slb ,一个是应用程序。所以要先确定是 slb->应用程序这一条链路是否是通畅无延迟的。因为 slb 本身也是一个池子,他抖动一下你只能看着。所以要有手段检查 slb->应用程序的延迟。一般是在你的这一测也加监控,不是光去看 slb 的监控,而且顺便把应用程序的监控也加了也好分析应用程序本身有什么问题。

看是 tomact ,就是 java 。prometheus 挂起来。看看接口的 99%延迟是多少,看看每台 qps 是多少(其实不重要,tps 只是有比较才用,一直都是一个均值没啥用)。每台机器要挂一个 node exporter 。看机器的详细的指标。网络吞吐是不是到瓶颈,内存是不是到瓶颈,是不是那个时候在做 full gc 。等等。。这些信息都没有。。。让广大 v 友盲猜?
luxinfl
2022-03-15 16:09:15 +08:00
@sampeng 有 prometheus ,但是没有接监控平台,端口估计也没放开,现网查不到数据。看样子可以先考虑把这些东西都加上,新项目上线,一些外围服务都还没搞。
sampeng
2022-03-15 16:10:23 +08:00
@luxinfl 有 prometheus 。。直接 curl 就能拿到了。。没那么麻烦。。。
sampeng
2022-03-15 16:11:54 +08:00
@luxinfl 回车打快了。。
无所谓了。排查问题,一定要有监控。。盲猜都是秀操作
luxinfl
2022-03-15 16:32:46 +08:00
@sampeng 没权限,看不到,在想办法。。
defunct9
2022-03-15 21:35:32 +08:00
开 ssh ,让我上去看看
luxinfl
2022-03-16 09:29:39 +08:00
@sampeng 大佬,调用外部接口的 http 连接数应该是有上限的吧,这个能查出来麽
luxinfl
2022-03-16 09:31:18 +08:00
@byte10 大佬,http 连接池的连接和 cpu 线程都需要去看 cpu 和内存的占用率麽?是不是 http 连接越多,占用内存也越多,对其他参数有影响么
sampeng
2022-03-16 10:36:50 +08:00
@luxinfl 有没上限也是看要看监控。java 的 jvm 的监控能看得到。很简单。。你怀疑线程数,就设置更多的线程呗,碰碰运气嘛。

这里有一个误区,并不是线城数越多越好。只要足够快,1 个线程也够用。要看 jvm 监控里面堵塞线程数,max 线程数等等。。就算没监控,你们也要有 ssh 权限上去看 jstack ,如果能正好撞上有问题的时候线程的问题可以看得出来。

没有监控都是盲猜,运气好撞上,运气不好就找不到。详细监控才是追查这种问题的办法。还有可以把 GC 日志打开,是不是在 GC ,但你们什么权限都没有。。查个鬼
byte10
2022-03-16 11:21:55 +08:00
@luxinfl 不是啊。。。你可以去看下我的那个视频。

1 、首先确保你的这个接口业务代码是否有网络 IO 的代码?(比如查询 redis ,查询数据库,查询第三方接口),你说是用本地缓存,那么不存在 redis 的 IO 时间。但是你说的另外 : ”有个场景,需要用设备号去查询用户标签信息,会根据这个筛选,这一步省略不了。“ 那么这一步的 IO 是可能存在瓶颈的,假设这个网络 IO 耗时 10ms ,那么你 100 个 tomcat 线程,也就是 1w/s 的并发,还只是理论的情况。如果你增加 1000 个线程,那么 cpu 处理的效率也会有点下降,频繁的线程上下文切换。

2 、如果业务代码存在网络 IO ,那么怎么改?那么可以使用 NIO 异步的方式去调用 数据库,redis ,第三方 http 接口等。但是也要注意那个连接数的问题,有一些协议不支持多路复用,比如 http 。如果你调用外部第三方接口是 http 接口,那么就需要设置比较大的 http 连接数,这个数量一般几千上万都可以,对方的服务也一般支持。

3 、但是你的服务应该有其他的接口的吗?假设你只有 8 个线程,其他 B 接口进来之后,有几个线程被这几个 B 接口长时间 IO 阻塞了,那么就会导致你的天气接口吞吐量下降。所以也需要预留部分线程给这些 B 接口。

这么大的吞吐量,有可能是你的服务出现瓶颈,所以先让你看看是不是 cpu 满了,如果满了,可能就是服务机器的性能达到一定的瓶颈了。下游的数据库服务或者第三方服务等也可能是瓶颈。上游只有 slb ,那么问题不大。
luxinfl
2022-03-17 19:16:43 +08:00
@byte10 对方的接口网络 io 大部分在 10ms ,偶尔有波动。我关掉外部调用,纯走本地缓存,碰到个奇怪的现象,tomcat 的 maxTread 调到 400 ,maxConnection 调到 2 万,关掉外部接口调用,跑了几次压测,cpu 和内存和几乎没有变化,按道理,线程数越多,cpu 和内存使用率不应该越高麽。。
luxinfl
2022-03-17 19:18:57 +08:00
@sampeng 今天一堆领导在排查了,访问量越来越高,一天都快 30 亿次接口调用,后端服务没啥问题,在扩容 slb ,不知道最后结果会是啥样。。
sampeng
2022-03-17 19:31:25 +08:00
@luxinfl 我才看见前面说的。。5 个 SLB 。。。slb 还能按个数说的? nginx 吧?
sampeng
2022-03-17 19:32:38 +08:00
@luxinfl max 不代表说一定要用那么多。。我前面也说了,误区是线程越多越好。其实如果足够快。1 个线程也够用。。想象 redis
luxinfl
2022-03-18 09:27:30 +08:00
@sampeng 这边习惯这么说,其实就是 nginx

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/840400

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX