MySQL(InnoDB剖析):53---性能调优之（CPU的选择、内存的重要性、磁盘对数据库性能的影响）
2024-05-15 21:08:49
一、CPU的选择
- 用户首先需要清楚当前数据库的应用类型。一般而言，可分为两大类：OLTP（Online Transaction Processing，在线事务处理）和OLAP（Online analytical Processing，在线分析处理）。这是两种截然不同的数据库应用
- OLAP多用在数据仓库或数据集市中，一般需要执行复杂的SQL语句来进行查询
- OLTP多用在日常的事物处理应用中，如银行交易、在线商品交易、Blog、网络游戏等应用。相对于OLAP，数据库的容量较小
- InnoDB存储引擎一般都应用于OLTP的数据库应用，这种应用的特点如下：
- 用户操作的并发量大
- 事务处理的时间一般比较短
- 查询的语句较为简单,一般都走索引
- 复杂的查询较少
- 可以看出，OLTP的数据库应用本身对CPU的要求并不是很高，因为复杂的查询可能需要执行比较、排序、连接等非常耗CPU的操作，这些操作在OLTP的数据库应用中较少发生。因此，可以说OLAP是CPU密集型的操作，而OLTP是IO密集型的操作建议在采购设备时，将更多的注意力放在提高IO的配置上
- 此外，为了获得更多内存的支持，用户采购的CPU必须支持64位，否则无法支持64位操作系统的安装。因此，为新的应用选择64位的CPU是必要的前提。现在4核的CPU已经非常普遍，如今 Intel和AMD又相继推出了8核的CPU，将来随着操作系统的升级我们还可能看到128核的CPU，这都需要数据库更好地对其提供支持
- 从 InnoDB存储引擎的设计架构上来看：
- 其主要的后台操作都是在一个单独的master thread中完成的，因此并不能很好地支持多核的应用
- 当然，开源社区已经通过多种方法来改变这种局面，而InnoDB1.0版本在各种测试下已经显示出对多核CPU的处理性能的支持有了极大的提高
- 而 InnoDB1.2版本又支持多个purge线程，以及将刷新操作从 master thread中分离出来
- 因此，若用户的CPU支持多核，InnoDB的版本应该选择1.1或更高版本。另外，如果CPU是多核的，可以通过修改参数 innodb_read_io_threads和innodb_write_io_threads来增大IO的线程，这样也能更充分有效地利用CPU的多核性能
- 在当前的 MySQL数据库版本中，一条SQL查询语句只能在一个CPU中工作，并不支持多CPU的处理。OLTP的数据库应用操作一般都很简单，因此对OLTP应用的影响并不是很大。但是，多个CPU或多核CPU对处理大并发量的请求还是会有帮助
二、内存的重要性
- 内存的大小是最能直接反映数据库的性能。通过之前的介绍，已经了解到InnoDB存储引擎既缓存数据，又缓存索引，并且将它们缓存于一个很大的缓冲池中，即InnoDB Buffer Pool。因此，内存的大小直接影响了数据库的性能
性能测试
- Percona公司的CTO Vadin对此做了一次测试，以此反映内存的重要性，结果如下图所示：
- 在上述测试中，数据和索引总大小为18GB，然后将缓冲池的大小分别设为2GB、4GB、6GB、8GB、10GB、12GB、14GB、16GB、18GB、20GB、22GB，再进行sysbench的测试
- 可以发现：
- 随着缓冲池的增大，测试结果TPS(Transaction Per Second)会线性增长
- 当缓冲池增大到20GB和2GB时，数据库的性能有了极大的提高，因为这时缓冲池的大小已经大于数据文件本身的大小，所有对数据文件的操作都可以在内存中进行。因此这时的性能应该是最优的，再调大缓冲池并不能再提高数据库的性能
- 所以，应该在开发应用前预估“活跃”数据库的大小是多少，并以此确定数据库服务器内存的大小。当然，要使用更多的内存还必须使用64位的操作系统
- 如何判断当前数据库的内存是否已经达到瓶颈了呢？可以通过查看当前服务器的状态，比较物理磁盘的读取和内存读取的比例来判断缓冲池的命中率，通常 InnoDB存储引擎的缓冲池的命中率不应该小于99%，如：
- 上述参数的具体含义如下所示：
- 可以通过以下公式计算InnoDB缓存池的命中率：
- 从上面例子可以看出，缓冲池命中率=167051313/(167051313+129236+0)=99.92%
- 如果命中率太低，则应考虑扩充内存，增加innodb_buffer_pool_size的值
- 即使缓冲池的大小已经大于数据库文件的大小，这也并不意味着没有磁盘操作。数据库的缓冲池只是一个用来存放热点的区域，后台的线程还负责将脏页异步地写入到磁盘。此外，每次事务提交时还需要将日志写入重做日志文件
三、磁盘对数据库性能的影响
传统机械硬盘
- 当前大多数数据库使用的都是传统的机械硬盘。机械硬盘的技术目前已非常成熟，在服务器领域一般使用SAS或SATA接口的硬盘。服务器机械硬盘开始向小型化转型，目前大部分使用25寸的SAS机械硬盘。
- 机械硬盘有两个重要的指标：一个是寻道时间，另一个是转速。当前服务器机械硬盘的寻道时间已经能够达到3ms，转速为15000RM(rotate per minute)。传统机械硬盘最大的问题在于读写磁头，读写磁头的设计使硬盘可以不再像磁带一样，只能进行顺序访问，而是可以随机访问。但是，机械硬盘的访问需要耗费长时间的磁头旋转和定位来查找，因此顺序访问的速度要远高于随机访问。传统关系数据库的很多设计也都是在尽量充分地利用顺序访问的特性
- 通常来说，可以将多块机械硬盘组成RAID来提高数据库的性能，也可以将数据文件分布在不同硬盘上来达到访问负载的均衡。
固态硬盘
- 固态硬盘，更准确地说是基于闪存的固态硬盘，是近几年出现的一种新的存储设备，其内部由闪存( Flash Memory)组成。因为闪存的低延迟性、低功耗，以及防震性，闪存设备已在移动设备上得到了广泛的应用。企业级应用一般使用固态硬盘，通过并联多块闪存来进一步提高数据传输的吞吐量。传统的存储服务提供商EMC公司已经开始提供基于闪存的固态硬盘的TB级别存储解决方案。数据库厂商 Oracle公司最近也开始提供绑定固态硬盘的 Exadata服务器。
- 不同于传统的机械硬盘，闪存是一个完全的电子设备，没有传统机械硬盘的读写磁头。因此，固态硬盘不需要像传统机械硬盘一样,需要耗费大量时间的磁头旋转和定位来查找数据，所以固态硬盘可以提供一致的随机访问时间。固态硬盘这种对数据的快速读写和定位特性是值得研究的。
- 另一方面，闪存中的数据是不可以更新的，只能通过扇区(sector)的覆盖重写，而在覆盖重写之前，需要执行非常耗时的擦除(erase)操作。擦除操作不能在所含数据的扇区上完成，而需要在删除整个被称为擦除块的基础上完成，这个擦除块的尺寸大于扇区的大小，通常为128KB或者256KB。此外，每个擦除块有擦写次数的限制。已经有一些算法来解决这个问题。但是对于数据库应用，需要认真考虑固态硬盘在写入方面存在的问题
- 因为存在上述写人方面的问题，闪存提供的读写速度是非对称的。读取速度要远快于写人的速度，因此对于固态硬盘在数据库中的应用，应该好好利用其读取的性能，避免过多的写入操作
- 下图显示了一个双通道的固态硬盘架构，通过支持4路的闪存交叉存储来降低固态硬盘的访问延时，同时增大并发的读写操作。通过进一步增加通道的数量，固态硬盘的性能可以线性地提高,例如我们常见的 Intel X25M固态硬盘就是10通道的固态硬盘
- 由于闪存是一个完全的电子设备，没有读写磁头等移动部件，因此固态硬盘有着较低的访问延时。当主机发布一个读写请求时，固态硬盘的控制器会把IO命令从逻辑地址映射成实际的物理地址，写操作还需要修改相应的映射表信息。算上这些额外的开销，固态硬盘的访问延时一般小于0.1ms左右。下图显示了传统机械硬盘、 内存、固态硬盘的随机访问延时之间的比较
- 对于固态硬盘在 InnoDB存储引擎中的优化，可以增加innodb_io_capacity变量的值达到充分利用固态硬盘带来的高IOPS特性。不过这需要用户根据自己的应用进行有针对性的调整。在 InnoSQL及 InnoDB1.2版本中，可以选择关闭邻接页的刷新，同样可以为数据库的性能带来一定效果的提升
- 此外，还可以使用 InnoSQL开发的L2 Cache解决方案，该解决方案可以充分利用固态硬盘的超高速随机读取性能，在内存缓冲池和传统存储层之间建立一层基于闪存固态硬盘的二级缓冲池，以此来扩充缓冲池的容量，提高数据库的性能。与基于磁盘的固态硬盘 Cache类似的解决方案还有 Facebook Flash Cache和 bcache，只不过它们是基于通用文件系统的，对 InnoDB存储引擎本身的优化较少
MySQL(InnoDB剖析):53---性能调优之（CPU的选择、内存的重要性、磁盘对数据库性能的影响）相关推荐
- SQL Server 性能调优（cpu）
SQL Server 性能调优(cpu) 研究cpu压力工具 perfom SQL跟踪 性能视图 cpu相关的waitevent Signal wait time SOS_SCHEDULER_YIEL ...
- 发布即巅峰：Java性能调优六大工具：MAT内存分析工具
MAT内存分析工具 MAT是MemoryAnalyzerTool的简称,它是一款功能强大的Java堆内存分析器,可以用于查找内存泄漏以及查看内存消耗情况.MAT是 基于Eclipse开发的一款免费的性 ...
- Spark商业案例与性能调优实战100课》第20课：大数据性能调优的本质和Spark性能调优要点分析
Spark商业案例与性能调优实战100课>第20课:大数据性能调优的本质和Spark性能调优要点分析 基于本元想办法,大智若愚,大巧若拙!深入彻底的学习spark技术内核!
- gateway 内存溢出问题_带你学习jvm java虚拟机 arthas/性能调优/故障排除/gc回收/内存溢出等...
学完本课程,您将掌握: 内存溢出问题实战 CPU飙升问题实战 阿里巴巴Arthas在线诊断 Class字节详细拆解 手写类加载器.四种类加载器.双亲委托模型 对象创建.存储.访问.加载解析 性能调优. ...
- server sql top速度变慢解决方案_SQL Server的性能调优：解决查询速度慢的五种方法-数据库...
编辑推荐: 本文主要通过一下几个方面介绍:使用SQL DMV查找慢速查询.通过APM解决方案查询报告.SQL Server扩展事件.SQL Azure查询性能洞察等相关内容. 本文来自博客园,由火龙果 ...
- JVM性能调优2_垃圾收集器与内存分配策略__享学课堂
判断对象的存活 引用计数法: 优点:快,方便,实现简单: 缺点:对象相互引用时,很难判断对象是否该回收. 可达性分析: 这个算法的基本思路就是通过一系列的称为"GC Roots"的 ...
- JVM性能调优3_垃圾收集器与内存分配策略__享学课堂
Stop The World现象 GC收集器和我们GC调优的目标就是尽可能的减少STW的时间和次数. 内存分配与回收策略 对象优先在Eden分配,如果说Eden内存空间不足,就会发生Minor GC ...
- Android性能调优篇之探索JVM内存分配
开篇废话 今天我们一起来学习JVM的内存分配,主要目的是为我们Android内存优化打下基础. 一直在想以什么样的方式来呈现这个知识点才能让我们易于理解,最终决定使用方法为:图解+源代码分析. 欢迎访 ...
- jvm性能调优实战 - 34十万QPS的社交APP 如何优化GC性能提升3倍？
文章目录 Pre 案例背景 高并发查询导致对象快速进入老年代 老年代必然会触发频繁GC 优化前的线上系统JVM参数 频繁Full GC导致的大量内存碎片 如何进行优化? 思考题 Pre 这篇文章开始, ...
最新文章
- 数据结构与算法(十二)：八大经典排序算法再回顾
- php根据宽度显示html,我怎样才能动态地改变PHP的HTML div的宽度？
- C语言经典例20-小球反弹高度问题
- csdn在markdown笔记中复制代码格式混乱的解决办法
- Qt Creator将UI项目转换为应用程序
- 流水线问题--计算机体系结构
- happens-before通俗理解
- 润乾报表使用问题总结
- Linux系统性能检测
- ubuntu16.04安装pycharm，并设置快捷启动方式
- iOS开发字符串倒序，倒序单词字母，不倒序单词位置
- 推荐几款屏幕录制工具（可录制GIF）
- python有限元传热求解_用python实现简单的有限元方法（一）
- 词消歧算法：使用WordNet和Lesk算法进行英文消歧义
- 即时通讯系统开发的问题详解
- DevC++实现代码高亮复制进word
- 甲骨文oracle兴学,甲骨文 Oracle Bone Inscription
- 正确使用GPU服务器gpu服务器和普通服务器的不同之处
- EasyUI 系列之 combobox 默认选中第一个 添加请选择选项
- android名字最长,AaaaaAAaaa...体验史上名字最长的游戏