mysql数据库最大能支持多少并发量

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了mysql数据库最大能支持多少并发量相关的知识,希望对你有一定的参考价值。

MySQL服务器的最大并发连接数是16384。

受服务器配置,及网络环境等制约,实际服务器支持的并发连接数会小一些。主要决定因素有:

1、服务器CPU及内存的配置。

2、网络的带宽。互联网连接中上行带宽的影响尤为明显。

扩展资料:

优化数据库结构:

组织数据库的schema、表和字段以降低I/O的开销,将相关项保存在一起,并提前规划,以便随着数据量的增长,性能可以保持较高的水平。

设计数据表应尽量使其占用的空间最小化,表的主键应尽可能短。·对于InnoDB表,主键所在的列在每个辅助索引条目中都是可复制的,因此如果有很多辅助索引,那么一个短的主键可以节省大量空间。

仅创建需要改进查询性能的索引。索引有助于检索,但是会增加插入和更新操作的执行时间。

InnoDB的ChangeBuffering特性:

InnoDB提供了changebuffering的配置,可减少维护辅助索引所需的磁盘I/O。大规模的数据库可能会遇到大量的表操作和大量的I/O,以保证辅助索引保持最新。当相关页面不在缓冲池里面时,InnoDB的changebuffer将会更改缓存到辅助索引条目。

从而避免因不能立即从磁盘读取页面而导致耗时的I/O操作。当页面被加载到缓冲池时,缓冲的更改将被合并,更新的页面之后会刷新到磁盘。这样做可提高性能,适用于mysql5.5及更高版本。

参考资料来源:百度百科-MySQL数据库



参考技术A 获取数据不总是到数据库取的。
并发是同一时刻,有多少个请求在数据库上跑。数据库最大并发和在线人数没有确定的对应关系。举个例子,你登陆CSDN,验证账户信息,可能去取一次数据库,也可能不取(直接从MC里得到),这时候你有一次连接。然后你啥事都没做,当然也不可能对数据库有操作了,但是你还是在线的,因为你已经登陆了。
参考技术B

现象

Sysbench对MySQL进行压测, 并发数过大(>5k)时, Sysbench建立连接的步骤会超时.

猜想

猜想: 直觉上这很简单, Sysbench每建立一个连接, 都要消耗一个线程, 资源消耗过大导致超时.

验证: 修改Sysbench源码, 调大超时时间, 仍然会发生超时.

检查环境

猜想失败, 回到常规的环境检查:

    MySQL error log 未见异常.

    syslog 未见异常.

    tcpdump 观察网络包未见异常, 连接能完成正常的三次握手; 只观察到在出问题的连接中, 有一部分的TCP握手的第一个SYN包发生了重传, 另一部分没有发生重传.

    自己写一个简单的并发发生器, 替换sysbench, 可重现场景. 排除sysbench的影响

    猜想2

    怀疑 MySQL 在应用层因为某种原因, 没有发送握手包, 比如卡在某一个流程上:

    检查MySQL堆栈未见异常, 仿佛MySQL在应用层没有看到新连接进入.

    通过strace检查MySQL, 发现 accept() 调用确实没有感知到新连接.

    怀疑是OS的原因, Google之, 得到参考文档: A TCP “stuck” connection mystery【http://www.evanjones.ca/tcp-stuck-connection-mystery.html

    分析

    参考文档中的现象跟目前的状况很类似, 简述如下:

    正常的TCP连接流程:

    Client 向 Server 发起连接请求, 发送SYN.

    Server 预留连接资源, 向 Client 回复SYN-ACK.

    Client 向 Server 回复ACK.

    Server 收到 ACK, 连接建立.

    在业务层上, Client和Server间进行通讯.

    当发生类似SYN-flood的现象时, TCP连接的流程会使用SYN-cookie, 变为:

    Client 向 Server 发起连接请求, 发送SYN.

    Server 不预留连接资源, 向 Client 回复SYN-ACK, 包中附带有签名A.

    Client 向 Server 回复ACK, 附带 f(签名A) (对签名进行运算的结果).

    Server 验证签名, 分配连接资源, 连接建立.

    在业务层上, Client和Server间进行通讯.

    当启用SYN-cookie时, 第3步的ACK包因为 某种原因 丢失, 那么:

    从Client的视角, 连接已经建立.

    从Server的视角, 连接并不存在, 既没有建立, 也没有”即将建立” (若不启用SYN-cookie, Server会知道某个连接”即将建立”)

    发生这种情况时:

    若业务层的第一个包应是从 Client 发往 Server, 则会进行重发或抛出连接错误

    若业务层的第一个包应是从 Server 发往 Client的, Server不会发出第一个包. MySQL的故障就属于这种情况.

    TCP握手的第三步ACK包为什么丢失

    参考文档中, 对于TCP握手的第三步ACK包的丢失原因, 描述为:

    Some of these packets get lost because some buffer somewhere overflows.

    我们可以通过Systemtap进一步探究原因. 通过一个简单的脚本:

    probe kernel.function("cookie_v4_check").return

    source_port = @cast($skb->head + $skb->transport_header, "struct tcphdr")->source

    printf("source=%d, return=%d\\n",readable_port(source_port), $return)

    function readable_port(port)

    return (port & ((1<<9)-1)) << 8 | (port >> 8)

    观察结果, 可以确认cookie_v4_check (syn cookie机制进行包签名检查的函数)会返回 NULL(0). 即验证是由于syn cookie验证不通过, 导致TCP握手的第三步ACK包不被接受.

    之后就是对其中不同条件进行观察, 看看是哪个条件不通过. 最终原因是accept队列满(sk_acceptq_is_full):

    static inline bool sk_acceptq_is_full(const struct sock  *sk)   return sk->sk_ack_backlog > sk-   >sk_max_ack_backlog;

    恢复故障与日志的正关联

    在故障处理的一开始, 我们就检查了syslog, 结论是未见异常.

    当整个故障分析完成, 得知了故障与syn cookie有关, 回头看syslog, 里面是有相关的信息, 只是和故障发生的时间不匹配, 没有正关联, 因此被忽略.

    检查Linux源码:

    if (!queue->synflood_warned &&

    sysctl_tcp_syncookies != 2 &&

    xchg(&queue->synflood_warned, 1) == 0)

    pr_info("%s: Possible SYN flooding on port %d. %s.

    Check SNMP counters.\\n",

    proto, ntohs(tcp_hdr(skb)->dest), msg);

    可以看到日志受到了抑制, 因此日志与故障的正关联被破坏.

    粗看源码, 每个listen socket只会发送一次告警日志, 要获得日志与故障的正关联, 必须每次测试重启MySQL.

    解决方案

    这种故障一旦形成, 难以检测; 系统日志中只会出现一次, 在下次重启MySQL之前就不会再出现了; Client如果没有合适的超时机制, 万劫不复.

    解决方案:
    1. 修改MySQL的协议, 让Client先发握手包. 显然不现实.
    2. 关闭syn_cookie. 有安全的人又要跳出来了.
    3. 或者调高syn_cookie的触发条件 (syn backlog长度). 降低系统对syn flood的敏感度, 使之可以容忍业务的syn波动.

    有多个系统参数混合影响syn backlog长度, 参看【http://blog.dubbelboer.com/2012/04/09/syn-cookies.html】

    下图为精华总结

    请点击输入图片描述

参考技术C 这个看你服务器处理能力了。淘宝就是用mysql,这么多用户访问都没问题。本回答被提问者采纳

tomcat支持多少并发

  Tomcat的最大并发数是可以配置的,实际运用中,最大并发数与硬件性能和CPU数量都有很大关系的。更好的硬件,更多的处理器都会使Tomcat支持更多的并发。

  Tomcat默认的HTTP实现是采用阻塞式的Socket通信,每个请求都需要创建一个线程处理,当一个进程有500个线程在跑的话,那性能已经是很低很低了。Tomcat 默认配置的最大请求数是150,也就是说同时支持150个并发。具体能承载多少并发,需要看硬件的配置,CPU 越多性能越高,分配给JVM的内存越多性能也就越高,但也会加重GC的负担。当某个应用拥有 250 个以上并发的时候,应考虑应用服务器的集群。

操作系统对于进程中的线程数有一定的限制:

    Windows 每个进程中的线程数不允许超过 2000

    Linux 每个进程中的线程数不允许超过 1000

    在Java中每开启一个线程需要耗用1MB的JVM内存空间用于作为线程栈之用,此处也应考虑。  

参考技术A Tomcat 默认配置的最大请求数是 150,也就是说同时支持 150 个并发,当然了,也可以将其改大。

当某个应用拥有 250 个以上并发的时候,应考虑应用服务器的集群。

具体能承载多少并发,需要看硬件的配置,CPU 越多性能越高,分配给 JVM 的内存越多性能也就越高,但也会加重 GC 的负担。

操作系统对于进程中的线程数有一定的限制:

Windows 每个进程中的线程数不允许超过 2000
Linux 每个进程中的线程数不允许超过 1000

另外,在 Java 中每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用。本回答被提问者和网友采纳
参考技术B 自己设置呗!理论上是无限制的!

以上是关于mysql数据库最大能支持多少并发量的主要内容,如果未能解决你的问题,请参考以下文章

mysql连接数和并发量的关系

腾讯云的mysql 2核4G大概能支撑多少并发?

MYSQL 支持的最大并发线程数是多少

MySQL到底能支持多大的数据量

小型电商网站多少并发量合适

如何修改mysql并发数