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

Posted 2020-08-28 wade&luffy

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对此做了一次测试，以此反应内存的重要性，结果如图所示。

在上述的测试中，数据和索引总大小为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

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

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：发起读取请求的次数，每次读取可能需要读取多个页。

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

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

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