赞
踩
在工作的时候经常有同事找我处理mysql优化的问题,其实数据库维护在日常的运维中是非常考验一名运维工程师是否熟悉计算机的各个方面。所以这次我会系统的、全面的讲解该如何深度优化mysql数据库。
在生产环境中,可能已经部署了相应的mysql服务器,或者即将部署mysql服务器正在选择硬件的时候,我们会选择是运算速度快的CPU还是核心数高的CPU呢?
可能有些人第一反应是选择更贵的CPU,这往往是一个误区。我们应当考虑到硬件环境与成本的问题。可能过于昂贵的CPU却干着最简单的活造成浪费,又或者过于廉价的CPU干着最累的活造成业务的损失。这些都是我们运维工程师需要考虑到的。
** 1.追求低延时和高吞吐量 **
低延时表示了CPU的运算速度快,在单位时间内处理请求的个数越高,处理负载能力越高。即CPU运算速度快,处理请求的延时低,吞吐量就越高。所以可以追求运算速度快的CPU。
** 2.判断当前工作负载是CPU密集型还是I/O密集型 **
在选择CPU的时候需要考虑,承接的业务的工作负载是CPU密集型,还是I/O密集型。这里可以通过一些命令或者监控去查看当前的负载情况,以及一些其他参数。
比如:top命令;
命令:vmstat 1
我们通过查看这些监控可以查看到当前系统正在运行的进程数,阻塞的进程数;内存和磁盘的交换量;内核的用户空间与内核空间的比值;上下文切换数量、软中断和硬中断的数量等因素来判断工作负载是什么。
一般的,需要进行数据分析、数据挖掘的时候是需要CPU的运算能力。而需要进行数据的读取,像一些网站、注册等业务往往需要大量的I/O流,和随机读取,这往往需要I/O能力。
如果CPU经常出现闲置,而I/O流有非常的繁忙,则有可能是当前工作负载是I/O密集型。
如果CPU的占用率在70%以上,即CPU非常繁忙,I/O子系统又不是处于平静的状态这说明当前是CPU密集型的工作模式。
如果当前出现CPU非常繁忙,I/O不忙。但是出现了大量的阻塞进程,这说明CPU的核心数不够。
** 3.当前CPU是32位还是64位 **
这里可能有人会有疑问,为什么好好的64位系统不用,要用32位的系统?只能说有一些企业还在用非常古老的操作系统和使用非常远古的数据库版本4.0左右。这时如果要更换64位CPU则需要主板、操作系统等一系列的硬件和软件的更换,并且还有可能会导致旧版本数据库与系统不兼容等问题,之前在旧版本的基础上开发的一些前端代码,也有可能不兼容新的数据库。所以这些企业往往会考虑到成本、数据安全的角度。所以只能跟换相对应的CPU。
** 4.CPU的核心数 **
在mysql5.1以前数据库的核心利用率是很低的,一般在服务器上的核心利用率在4核左右。极低利用率导致了当时的工程师会在一台服务器上开多个mysql的实例,即运行多个mysql服务。通过与多个核心绑定这个手段来提高核心利用率。但这种手段提高效率非常有局限性。
知道mysql5.6版本之后,CPU的利用率大幅提升,根据经验总结CPU的核心数在:16-24左右mysql的工作效率最好。而更多的核心数反而会导致数据库工作效率的下降。
mysql数据库对磁盘的I/O大部分是随机性写入,随机性写入往往会导致需要大量的内存作为磁盘的缓冲。而多大的内存合适呢。这需要我们进行基准测试进行评估,比如当前服务器数据库需要多少内存,每个数据库的连接大概需要消耗多少内存。再通过一段时间的运行之后查看数据库发展到多少个连接,这时我们就可以估算出数据库的内存需求。
我们可以通过一些命令去监控mysql的内存使用情况。
命令:top -p 进程号
通过查看VIRT数值代表了mysql向内核申请虚拟内存的大小。
接着进入数据库,通过:
show processlist;
查看mysql的进程数。
再通过刚才VIRT的高德数据可以平均得出每个mysql线程所需要的的内存大小,之后再运行一段时间后查看连接数就可以大致得出mysql所需要的内存大小。
** 尽可能不去使用swap **
在计算机中会将一部分磁盘空间划分出来和内存一起当做虚拟内存来使用。当内存不够用的时候,计算机会将一部分数据存储在磁盘中,我们知道磁盘的读写速度远不如内存的读写速度。所以当时用swap时,读写磁盘中的数据会耗费大量的I/O流,这大大影响了mysql的运行效率。
所以,我们可以修改Linux的内核参数来关闭swap。即修改参数降低系统使用swap的倾向,倾向的值越高,系统越会去使用swap,将数据写入到swap之中。但是同时我们也需要扩大内存来保重有足够的内存空间供mysql使用。
echo 0 > /proc/sys/vm/swappiness
在修改swappiness时不能使用vim文本编辑器,否则会出错。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。