<转>数据库连接池性能优化,连接数到底应该设置多大?

1. 数据库连接数测试
        假如你有一个网站,压力有个1万上下的并发访问——也就是说差不多2万左右的TPS。那么这个网站的数据库连接池应该设置成多大呢?可能更正确的问法是:这个网站的数据库连接池应该设置成多小呢?下面请看一下这个测试视频 http://www.dailymotion.com/video/x2s8uec,(视频是英文解说且没有字幕,简单概括一下如下)

主题:视频中对Oracle数据库进行压力测试,9600并发线程进行数据库操作,每两次访问数据库的操作之间sleep 550ms

一开始设置的线程池大小为2048。每个请求要在连接池队列里等待33ms,获得连接后执行SQL(吞吐量)需要77ms

然后设置线程池大小为1024。能看到,中间件连接池从2048减半之后,连接池队列里等待事件没怎么变,但执行SQL耗时减少了一半。

接下来,设置线程池大小为96,并发线程数仍然是9600不变。连接池队列里等待事件几乎没了,吞吐量被优化到了2ms。查询性能得到了巨大提升!

没有调整任何其他东西,仅仅只是缩小了中间件层的数据库连接池,就把请求响应时间从77ms左右缩短到了2ms。 还有同样的案例:nginx只用4个线程发挥出的性能就大大超越了100个进程的Apache HTTPD。这是为什么呢?

2. 透过现象看原理
        从上面的测试,我们发现数据库连接数越小,性能越好。下面来探讨一下现象下的本质。

        即使是单核CPU的计算机也能“同时”运行数百个线程。但我们都知道这只不过是操作系统用时间分片玩的一个小把戏。一颗CPU核心同一时刻只能执行一个线程,然后操作系统切换上下文,核心开始执行另一个线程的代码,以此类推。给定一颗CPU核心,其顺序执行A和B永远比通过 时间分片“同时”执行A和B要快,因为顺序执行不需要上下文切换,上下文切换也是耗时的。这是一条计算机科学的基本法则。一旦线程的数量超过了CPU核心的数量,再增加线程数系统就只会更慢,而不是更快。

        上面的说法只能说是接近真理,但还并没有这么简单,有一些其他的因素需要加入。当我们寻找数据库的性能瓶颈时,总是可以将其归为三类:CPU、磁盘、网络。把内存加进来也没有错,但比起磁盘和网络,内存的带宽要高出好几个数量级,所以就先不加了。

        如果我们无视磁盘和网络,那么结论就非常简单。在一个8核的服务器上,设定连接/线程数为8能够提供最优的性能,再增加连接数就会因上下文切换的损耗导致性能下降。但数据库通常把数据存储在磁盘上,磁盘又通常是由一些旋转着的金属碟片和一个装在步进马达上的读写头组成的。它必须“寻址”到另外一个位置来执行另一次读写操作。所以就有了寻址的耗时,此外还有旋回耗时,读写头需要等待碟片上的目标数据“旋转到位”才能进行操作。在磁盘寻址这一时间段(即"I/O等待")内,线程是在“阻塞”着等待磁盘,此时操作系统可以将那个空闲的CPU核心用于服务其他线程。所以,由于线程总是在I/O上阻塞,我们可以让线程/连接数比CPU核心多一些,这样能够在同样的时间内完成更多的工作。

        那么让线程/连接数比CPU核心多多少呢?这要取决于磁盘。较新型的SSD不需要寻址,也没有旋转的碟片。可别想当然地认为“SSD速度更快,所以我们应该增加线程数”,恰恰相反,无需寻址和没有旋回耗时意味着更少的阻塞,所以更少的线程,更接近于CPU核心数会发挥出更高的性能。只有当阻塞创造了更多的执行机会时,更多的线程数才能发挥出更好的性能。

3. 如何合理设置数据库连接数
        明白了原理后,就可以合理的设置连接数来优化性能。

        计算公式:连接数 = (核心数 * 2) + 有效磁盘数

        按这个公式,你的4核i7数据库服务器的连接池大小应该为((4 * 2) + 1) = 9。取个整就算是是10吧。不要觉得太小,它能轻松搞定3000用户以6000TPS的速率并发执行简单查询的场景。如果连接池大小超过10,你会看到响应时长开始增加,TPS开始下降。因为随着连接数增多,cpu上下文切换频繁,增加请求耗时,而遵循这个公式,可以在当前线程进行IO阻塞时,适当的就行上下文切换,避免了切换频繁带来的耗时!*当然,这也不是一个万能公式,具体设置的值还需要进行实际压力测试才能决定!

        在上面Oracle的视频中,他们把连接数从2048降到了96,提升了大量想能。实际上96都太高了,除非服务器有16或32颗核心。

结论:尽量设置一个小的连接池,和一个充满了等待连接的线程的队列
-----------------------------------
©著作权归作者所有:来自51CTO博客作者知识分子_的原创作品,请联系作者获取转载授权,否则将追究法律责任
数据库连接池性能优化,连接数到底应该设置多大?
https://blog.51cto.com/u_15281317/3008763

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
数据库优化方案设计 XX信息管理平台从大型数据库环境四个不同级别的调整分析入手,分析数据库平台的系 统结构和工作机理,从九个不同方面设计数据库的优化方案。 对于数据库据优化,主要有四个不同的调整级别,第一级调整是操作系统级包括硬 件平台,第二级调整是RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级 是SQL级。通常依此四级调整级别对数据库进行调整、优化,数据库的整体性能会得到很 大的改善。下面从九个不同方面介绍数据库优化设计方案。 一、数据库优化自由结构 数据库的逻辑配置对数据库性能有很大的影响。为此,数据库平台一般对表空间设计提 出有相的优化结构,如ORACLE公司的OFA(Optimal flexible Architecture),使用这种结构进行设计会大大简化物理设计中的据管理。优化自由结 构,简单地讲就是在数据库中可以高效自由地分布逻辑据对象,因此首先要对数据库 中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包 括将系统据和用户据分开、一般据和索引据分开、低活动表和高活动表分开等 等。 数据库逻辑设计的结果当符合下面的准则: 把以同样方式使用的段类型存储在一起; 按照标准使用来设计系统; 存在用于例外的分离区域; 最小化表空间冲突; (5)将据字典分离。 二、充分利用系统全局区域 系统全局区域是数据库平台的心脏,如Oracle数据库的SGA(SYSTEM GLOBAL AREA) 。用户的进程对这个内存区发送事务,并且以这里作为高速缓存读取命中的据 ,以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA包括以下几个部分 : 1、据块缓冲区(data block buffer cache)是SGA中的一块高速缓存,占整个数据库大小的1%- 2%,用来存储从数据库重读取的据块(表、索引、簇等),因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号据、据文件名、段名、盘区位置、 表说明和权限,它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法管 理。如果设置过小,语句将被连续不断地再装入到库缓存,影响系统性能。 另外,SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这些 内存缓冲区的合理设置,可以大大加快据查询速度,一个足够大的内存区可以把绝大 多据存储在内存中,只有那些不怎么频繁使用的据,才从磁盘读取,这样就可以 大大提高内存区的命中率。 三、规范与反规范设计数据库 1、规范化 范式是符合某一级别的关系模式的集合,根据约束条件的不同,一般有1NF、2NF、3NF三 种范式。规范化理论是围绕这些范式而建立的。规范化的基本思想是逐步消除据依赖 中不合适的部分,使模式中的各关系模式达到某种程度的"分离",即采用"一事一地"的 模式设计原则,因此,所谓规范化实质上就是概念的单一化。数据库据规范化的优 点是减少了据冗余,节约了存储空间,相逻辑和物理的I/O次减少,同时加快了增 、删、改的速度。但是一个完全规范化的设计并不总能生成最优的性能,因为对数据库 查询通常需要更多的连接操作,从而影响到查询的速度。故有时为了提高某些查询或 用的性能而有意破坏规范规则,即反规范化。 2、反规范化 反规范的必要性 是否规范化的程度越高越好呢?答案是否定的,根据实际需要来决定,因为"分离"越 深,产生的关系越多,结构越复杂。关系越多,连接操作越频繁,而连接操作是最费时 间的,在数据库设计中特别对以查询为主的数据库设计来说,频繁的连接会严重影响查 询速度。所以,在数据库的设计过程中有时故意保留非规范化约束,或者规范化以后又 反规范,这样做通常是为了改进数据库的查询性能,加快数据库系统的响速度。 反规范技术 在进行反规范设计之前,要充分考虑据的存取需求,常用表的大小、特殊的计算、 据的物理存储等。常用的反规范技术有合理增加冗余列、派生列,或重新组表几种。反 规范化的好处是降低连接操作的需求、降低外码和索引目,减少表的个,从而提高 查询速度,这对于性能要求相对较高的数据库系统来说,能有效地改善系统的性能,但 相的问题是可能影响据的完整性,加快查询速度的同时降低修改速度。 3、数据库设计中的优化策略 当按两种类别进行组织:频繁访问的据和频繁修改的据。对于频繁访问但是 不频繁修改的据,内部设计当物理不规范化。对于频繁修改但并不频繁访问的据 ,内部设计当物理规范化。比较复杂的方法是将规范
服务器监控及性能优化 技术创新,变革未来 服务器监控及性能优化全文共27页,当前为第1页。 目录 MMO游戏的常用架构 服务器系统用健康监控体系 游戏内常用的效率分析及对的优化手段 与其他互联网产品的互通性思考 Q&A 环节 服务器监控及性能优化全文共27页,当前为第2页。 MMO游戏的常用架构 架构和业务是相互促进的 服务器监控及性能优化全文共27页,当前为第3页。 运营系统架构 服务器监控及性能优化全文共27页,当前为第4页。 游戏内监控体系 监控信息汇总到CMS 每个服务器定时汇报自身 各个指标信息 运营系统记录汇总绘图 服务器监控及性能优化全文共27页,当前为第5页。 服务器系统健康监控体系 硬件监控项 CPU使用率 内存使用率 硬盘使用率 内网网卡使用率 外网网卡使用率 磁盘IO 服务器监控及性能优化全文共27页,当前为第6页。 服务器系统健康监控体系 服务器监控及性能优化全文共27页,当前为第7页。 服务器系统健康监控体系 软件监控项 帧速率 网络包 目 网络连 接目 房间 线程 状态 NPC 量 道具 量 在线玩 家量 存档 状态 数据库 状态 激活对 象量 服务器监控及性能优化全文共27页,当前为第8页。 服务器系统健康监控体系 软件信息 监控服务 汇总 阀值判定 各类报警 记录日志 健康监控体系报警,然后呢? ---分析 各种开源工具、内嵌API、心跳等多种检测方式 硬件信息 服务器监控及性能优化全文共27页,当前为第9页。 游戏内分析系统设计与实现 帧速率 网络包 目 网络连 接目 房间 线程 状态 NPC 学 计算 在线玩 家量 存档 状态 数据库 状态 激活对 象量 聚集 状态 监测和分析 是基于业务的 服务器监控及性能优化全文共27页,当前为第10页。 游戏内分析系统设计与实现 服务器监控及性能优化全文共27页,当前为第11页。 游戏内分析系统设计与实现 服务器监控及性能优化全文共27页,当前为第12页。 MMO服务器常用的优化手段 写在之前 对于在运行系统,优化可能牵一发而动全身, 尽快利用各种手段解决问题,保证项目运行。 服务器监控及性能优化全文共27页,当前为第13页。 MMO服务器常用的优化手段 逻辑帧速率优化(尽量控制150ms) ----找到最耗时的函,内嵌检测,运行超时LOG 对象量过多,大量道具,NPC等 学计算过多,位置计算,子弹碰撞,伤害计算等 异常聚集,不可控的玩家行为 跨线程访问,不合理的线程粒度 锁操 作 减小粒度 减少锁时间 同步 同帧合并 减少聚集 大量 对象 分批计算 设置激活 据 结构 服务器监控及性能优化全文共27页,当前为第14页。 MMO服务器常用的优化手段 流畅 控制 同步 同帧 合并 重点 压缩 大量的网络包优化 ----找到发送最多的包,流量统计,LOG记录 同步的消息在同逻辑帧合并发送,减少投递次 大量的网络IO重点优化包 MMO的大量包产生在同步,控制范围 使用内存池,大量小内存的申请释放消耗很大 异常来回发送等逻辑BUG 服务器监控及性能优化全文共27页,当前为第15页。 MMO服务器常用的优化手段 网络链接优化 创建链接开销大,使用网络连接池解决 开服、积分墙刷广告,从设计上支持动态增加网关服务器解决 撞库等异常的网络攻击,及时彻底释放,封IP解决 创建销毁 的开销 极限情况 的控制 安全处理 的手段 服务器监控及性能优化全文共27页,当前为第16页。 MMO服务器常用的优化手段 线程操作优化 ----尽量减少锁的时间 尽可能的少调用锁 减小锁粒度 线程控制,线程间切换开销 利用析构自解锁,防止死锁 网络 数据库 存读档 内部LOG 系统 游戏场景 。。。 一次交换收到的 消息到处理线程 写比读要频繁 分成读写锁 一次交换到写线 程批次写入 不频繁操作, 注意锁定时间 游戏服务器的线程处理 服务器监控及性能优化全文共27页,当前为第17页。 MMO服务器常用的优化手段 存档数据库操作优化 ---尽量保证不回档 存档 正确 设计存读档缓冲,减少直接对据操作 增加存档频率,设定重要存档节点 控制存档据大小,可压缩 据表设计合理 按战区分存档库 缓存 存档 关键点 存档 压缩 据 合理 表结构 服务器监控及性能优化全文共27页,当前为第18页。 MMO服务器常用的优化手段 内存优化 单个对象的内存占用尽量少,比如使用标记位 频繁申请释放的对象使用对象池,消息,道具,子弹,NPC等 碎内存控制,长时间运行后会积累 重写new delete,用于统计和分析效率点和泄露 根据功能分多进程 控制申请 次大小 使用 内存池 统计 内存使用 服务器监控及性能优化全文共27页,当前为第19页。 MM

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值