数据库压死

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

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

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

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

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

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

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

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

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

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

  其实,我想错了。

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

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

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

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

第一层,磁盘io。

  指标专业名词:IOPS;因为所有的数据都是存储在磁盘的,所以,在高并发的场景下,一定会受到磁盘能力的限制,普通磁盘 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的线程池中取出线程来处理任务。但是当线程不够用的时候,它会创建新的线程池来处理。

  所以,并发连接数越大,则往往意味着mysql的线程会越多(不一定是一对一);线程越多意味着上下文切换将越频繁,cpu压力越大,服务器性能越差。所以,合理设置最大连接数,使服务器处于高效状态,是一个优化方向!

查看线程相关的状态变量:

      SHOW STATUS LIKE ‘Threads%‘;

那么问题来了,为什么阿里云上的rds设置了这么高的最大连接数呢?我估计,他是为了兼容最快速和最小数据量的并发连接情况,而设置的。自己可以压测下!

综上,四个指标。只要有一个成为瓶颈,其他指标也就失去了意义!

其实真正有过mysql调优经验的同学,深入理解过mysql,上面这些问题自然明白。而不明白的同学,则要多多实践才行!

一句话总结:纸上得来终觉浅,绝知此事要躬行!

原文地址:https://www.cnblogs.com/Leo_wl/p/10674270.html

时间: 2024-10-11 17:43:18

数据库压死的相关文章

骆驼真的会被最后一根稻草压死吗?

骆驼真的会被最后一根稻草压死吗?答案是肯定的,那如果把软件系统和服务比作骆驼的话,怎么样知道骆驼的极限呢?这个时候性能测试显得尤为重要,性能测试相信作为程序猿的我们并不会陌生,性能测试是指通过自动化的测试工具模拟多种正常.峰值以及异常负载条件来对系统的各项性能指标进行测试.负载测试和压力测试都属于性能测试,两者也可以结合进行,但是在日常工作中真正需要性能测试时,我们真的会玩的很溜么?你们有没有遇到如下的一些问题? 本期分享团队 质量解决方案组 主要职责: 提供质量解决方案,提高测试工作效率, 主

[转帖]商用数据库之死:Oracle 面临困境

商用数据库之死:Oracle 面临困境 投递人 itwriter 发布于 2019-10-20 08:22 评论(1) 有238人阅读 原文链接 [收藏] « » https://news.cnblogs.com/n/644400/ 感觉自己眼光太浅了 这些事情 应该有所感觉的 但是一直没有学习了解到. 作者:John Freeman.Fred McClimans 和 Zach Mitchell 我们预计到 2021 年,年产值 296 亿美元的商业数据库市场会收缩 20% 至 30%,认为 O

Jmeter数据库压测

a)   加载数据库驱动程序 在测试计划中添加Oracle数据库的驱动程序jar包,添加的jar包要与所压测的Oracle数据库版本一致,jar包放在Jmeter的lib目录下,我们用的是ojdbc6.jar这个jar包.示例如下: b)   添加线程组:右键测试计划——添加——Threads(users)——线程组 c)    右键线程组——添加——配置元件——JDBC Connection Configuration 在次界面进行连接具体数据库的配置,示例如下: Variable Name:

压死骆驼的最后一根稻草——写下自己的阶段感受与总结

感觉是应该写点东西了,这段时间一直在疑惑,关于考研的问题,其实心里也明白,只要自己实力强,到哪都有希望,不过毕竟想有个更好 的平台,更好的学校罢了,最近在浏览一些牛人的百科时,总是会很留意的看下是哪所院校毕业的,也无一例外的都是国内外的一流名校, 真的很羡慕的想去那样的大学,但是自己冷静下来思考一下,然而连个高数题都不会做的我又有什么资格谈考研呢.其实的确有些后悔,自 己大学没能够好好学习公共课,我知道即使努力学了也不一定能够保上研,毕竟牛人那么多,学霸之所以是学霸,他们拥有过人的毅力与坚 持,

移动团购:压死骆驼的救命稻草

各大银行.第三方支付机构.电信运营商在去年全力推进.角逐移动支付市场,更让移动团购最大的难题--支付瓶颈有了打破的希望,但似乎还没有打破. 文/张书乐 本文刊载于<销售与市场>杂志评论版2013年03期,转载请注明出处. 支付宝公司人士称,2012年团购市场总体交易比2011年有80%的增长,其中移动团购交易增幅惊人,比上一年劲升27倍,占到整个团购市场15%的份额.从资本层面看,截至2012年12月31日,美团网.拉手网.窝窝团等10家团购网站已累计获得2.2亿元人民币以及5.36亿美元以上

【真实面试经历】我和阿里面试官的一次“邂逅”(附问题详解)

本文的内容都是根据读者投稿的真实面试经历改编而来,首次尝试这种风格的文章,花了几天晚上才总算写完,希望对你有帮助. 本文主要涵盖下面的内容: 分布式商城系统:架构图讲解: 消息队列相关:削峰和解耦: Redis 相关:缓存穿透问题的解决: 一些基础问题: 网络相关:1.浏览器输入 URL 发生了什么? 2.TCP 和 UDP 区别? 3.TCP 如何保证传输可靠性? Java 基础:1. 既然有了字节流,为什么还要有字符流? 2.深拷贝 和 浅拷贝有啥区别呢? 下面是正文! 面试开始,坐在我前面

【转】数据库军规

做过一些数据库优化,但是很多小伙伴再设计数据库的时候都会有或多或少的问题,自己曾经也有过类似的问题.从网上看到一篇58沈剑老师的文章,深深的感觉沈剑老师的这篇文章还是比较接地气的,转载分享一下.还是那句话,具体问题要具体分析. 数据库30条军规解读 (1)必须使用InnoDB存储引擎 解读:支持事务.行级锁.并发性能更好.CPU及内存缓存页优化使得资源利用率更高 (2)必须使用UTF8字符集 解读:万国码,无需转码,无乱码风险,节省空间 (3)数据表.数据字段必须加入中文注释 解读:N年后谁tm

记录一次经历的数据库从单库到分库分表的过程

前言 目前所在的的项目组,由于项目正在处于一个业务爆发期,每天数据的增长量已经给我们数据库乃至系统造成了很多不确定的因数,前期依靠优化业务和SQL等方式暂时还能够支撑住.但是最近发现某些表数据达到500W+以后查询统计性能严重下降,高峰时段出现了很多SQL阻塞的情况例如: 这种阻塞带来的灾难是滚雪球的,由于越堆越多基本上把数据库已经拖死,所以我们就面临数据库切分的问题. 技术选型 既然要分库分表那数据库集群是少不了的,那我们的项目怎样和这些集群打交道呢?我调研了大概分为以下几种来完成这个功能(仅

【mysql】数据库使用的一些规范

一.MySQL存在的问题 优化器对复杂SQL支持不好 对SQL标准支持不好 大规模集群方案不成熟,主要指中间件 ID生成器,全局自增ID 异步逻辑复制,数据安全性问题 Online DDL HA方案不完善 备份和恢复方案还是比较复杂,需要依赖外部组件 展现给用户信息过少,排查问题困难 众多分支,让人难以选择 二.数据库环境介绍 通常来讲,各个互联网公司的数据库分为5个数据库环境: dev : 开发环境, 开发可读写,可修改表结构; 常用的163的数据库表; 开发人员可以修改表结构, 可以随意修改