为什么300的并发能把支持最大连接数4000数据库压死?

问: 为什么300的并发能把支持最大连接数4000数据库压死?

 

     买了一台数据库,最大连接数的参数是 4000,看起来很棒!但是 cpu 和内存并不咋好!是 2c4g的超低配制。

     但是想着反正业务量也不大,不如先扛着,等业务量上来再进行升配!

 

     没过多久,进行一次小量的营销活动。精力计算想了下,大量3-4台应用服务器就没问题了;然后再考虑下数据库,应该没有问题。

 

考虑到数据库没问题的原因有二:

      1. 应用服务器数量少,对数据库压力不会太大;

      2. 每个应用都设置了最大连接池限制,单台一般不会100的连接,与4000的并发连接指标还很远;

 

活动开始后,开始一切都很正常,应用服务器监控正常,前端响应正常。以为一切尽在掌握之中,结果却是一场灾难!

 

      前端页面响应越来越慢了,监控应用服务器却一点压力没上来!我知道是数据库出问题了!

 

     于是,直接开了个db客户端查看情况,自己试着运行了直sql,响应的确很慢,但是也能几十秒内返回;所以我数粗浅的结论是,应用响应会很慢,但是应该能响应完整!

 

      其实,我想错了。前端访问是有超时限制的,超过一段时间后,会自行断开连接,所以后端超级卡顿时,前端用户侧是会无法提供服务的!

      其二,除去前端会有超时限制断开外,应用api也会在一段时间没有收到数据库响应后,超时断开返回,然而数据库对断开请求则可能收不到,从而继续保持操作运行;从而应用服务器会再次发起下一个请求,从而使连接超过应用设置的连接池大小,进一步挑战db极限;所以,前端仍然是不能正常服务的。

 

 

回到前面数据库问题,为什么在还远低于最大连接数的情况下,db就开始不工作了呢?

 

其实,db的运行指标,不止有最大连接数一个!cpu,内存,磁盘,网络 都是其运行指标,这些指标都会限制其能力!

 

第一层,磁盘io。

      因为所有的数据都是存储在磁盘的,所以,在高并发的场景下,一定会受到磁盘能力的限制,普通磁盘 sata 可能只有7-10M/s 的能力,只要要求加载的数据远远大于这个速度,磁盘瓶颈就出来了。当然了,磁盘读取后,结果是会缓存到内存的,所以又和内存有关了!

 

第二层,内存。

      磁盘读取出来的数据必定会放到内存进行数据运算处理,然后才能得到结果。内存的速度当然是特别快了,咱们不考虑它这方面的能力问题。但是,速度再快,没有内存空间就没办法了,就像上面的配置 4g 的内存其实稍微几个大点的数据查询,基于就装满了。而且,在一次查询完成后,还要负责将结果缓存起来。当内存运行不够的时候,cpu会进行磁盘的swap操作,将需要运算的数据换入内存,从而保证运算正常进行,但是这个操作就很慢了,从而导致正常的查询都变得缓慢起来。(索引会稍微好点,因其数据量比较小,内存swap概率也低)。 所以,低配内存将是一大致命弱点,不要期望太高;

第三层,cpu。

      其实整个过程的调度都是由cpu来运筹帷幄的。只是,cpu运算速度往往都会很快,所以我们把它稍微放后点!因为前面磁盘和内存,导致cpu会不停地运算操作。另外,由于外部请求大量涌入,导致cpu要进行多线程的维护,即会有量上下文切换,这个切换增加了cpu压力,同时也使请求的响应变差,cpu也就越来越高,直到彪升到90+%,连操作系统的调度都很困难了。所以,只会雪上加霜地,降低请求的处理能力,从而导致db直接假死!可能只有重启才能解决问题了!

 

第四层,网络层。

      一般来说,只是数据库和应用是部署在一个内网里,那么,网络一般不会限制能力(非绝对);但是对于一些远程数据库,就直接要小心了,比如一个数据包就是3M+,那么如果是 10Mb/s 的带宽,仅能传输3-4个数据包,从而使响应能力完全限死;所以,数据库一般需要部署内网机房,或者买云数据库时,最好在同一区。网络层一般我们可以忽略,但是要知道这里的原理!

 

最后,我们来讨论下,mysql中的最大连接数到底是什么?

1. 查看最大连接数

show variables like '%max_connections%'

2. 修改最大连接数

set GLOBAL max_connections = 200;

那么,最大连接是什么原理呢?

一般对于处理快速的情况下,每个连接进来后,会从mysql的线程池中取出线程来处理任务。但是当线程不够用的时候,它会创建新的线程池来处理。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zyygdx.html