性能调优-CPU方面,内存方面

时间:2023-01-02 03:51:48

CPU调优

首先要清楚数据库应用的分类,一般分为两类:OLTP(Online Transaction Processing,在线事务处理)和OLAP(Online Analytical Processing,在线分析处理),这是两种完全不同的数据库应用。OLAP多用在数据仓库或数据集市中,一般需要执行复杂的SQL语句来进行查询;OLTP多用在日常的事物处理应用中,如银行交易、在线商品交易、Blog、网络游戏等应用。相对于OLAP,数据库的容量较小。

InnoDB存储引擎一般都应用于OLTP的数据库应用,这种应用的特点如下所示:

  1. 用户操作的并发量大。
  2. 事务处理的时间一般比较短。
  3. 查询的语句较为简单,一般都走索引。
  4. 复杂的查询较少。

可以看出,OLTP的数据库应用本身对CPU的要求并不高,因为复杂的查询可能需要执行比较、排序、连接等非常耗CPU的操作,这些操作在OLTP的数据库应用中很少发生。因此,可以说OLAP是CPU密集型的操作,而OLTP是IO密集型的操作。建议在采购设备时,应将更多的注意力放在提高IO的配置上。

此外,为了获得更多内存的支持,CPU必须支持64位的应用,否则无法支持64位操作系统的安装。因此,为新的应用选择64位的CPU是必要的前提。现在4核的CPU已经非常普遍,而今年Intel和AMD又都推出了6核的CPU,将来随着操作系统的升级,我们还可能看到128核的CPU,这都需要数据库更好地对其进行支持。

从InnoDB存储引擎的设计架构上来看,其主要的后台操作都是在一个单独的MASTER THREAD中完成的,因此并不能很好地支持多核的应用。当然,开源社区已经通过多种方法来改变这种局面,新的InnoDB Plugin版本在各种测试下已经显示对多核CPU的处理性能有了极大的提高。因此,如果你的CPU支持多核,InnoDB Plugin是更好的选择。另外,如果你的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 Vadim对此做了一次测试,以此反应内存的重要性,结果如图所示。

性能调优-CPU方面,内存方面

在上述的测试中,数据和索引总大小为18GB,然后将缓冲池的大小分别设为2GB、4GB、6GB、8GB、10GB、12GB、14GB、16GB、18GB、20GB、22GB,再进行sysbench的测试。可以发现,随着缓冲池的增大,测试结果TPS(Transaction Per Second)会线性增长。当缓冲池增大到20GB和22GB,数据库的性能有了极大的提高,因为这时缓冲池的大小已经大于数据文件本身的大小,所有对数据文件的操作都可以在内存中进行,因此这时的性能应该是最优的,再调大缓冲池并不能再提高数据库的性能。所以,应该在开发应用前预估“活跃”数据库的大小可能会是多少,并以此确定数据库服务器内存的大小。当然,要使用更多的内存,还必须使用64位的操作系统。

如何判断当前数据库的内存是否已经达到瓶颈了呢?可以通过查看当前服务器的状态,比较物理磁盘的读取和内存读取的比例来判断缓冲池的命中率,通常InnoDB存储引擎的缓冲池的命中率不应该小于99%,如:

show global status like 'innodb%read%'\G

性能调优-CPU方面,内存方面

上述参数的具体含义如下所示:

Innodb_buffer_pool_reads:表示从物理磁盘读取页的次数。

Innodb_buffer_pool_read_ahead:预读的次数。

Innodb_buffer_pool_read_ahead_evicted:预读的页,但是没有被读取就从缓冲池中被替换的页的数量,一般用来判断预读的效率。

Innodb_buffer_pool_read_requests:从缓冲池中读取页的次数。

Innodb_data_read:总共读入的字节数。

Innodb_data_reads:发起读取请求的次数,每次读取可能需要读取多个页。

以下公式可以计算各种对缓冲池的操作:

性能调优-CPU方面,内存方面

从上面的例子看,缓冲池命中率=66946 /(66946+0+713)=99.92%,可见当前内存的压力并不是很大。

即使缓冲池的大小已经大于数据库文件的大小,这也不意味着没有磁盘操作。数据库的缓冲池只是一个用来存放热点的区域,后台的master线程还负责将脏页异步地写入磁盘,每次事务提交时还需要立即写入重做日志文件。