在单独部署的mysql数据库服务器中发现,在高并发的情况下发现内存不够用,进一步发现swap的利用率很高。
公司的DBA提了两点建议:
- 1、建议先减小数据库缓冲池(buffer pool)的大小;
- 2、进行数据库内存扩容
1、首先,不是内存不够用吗?swap利用率为什么高呢?swap是什么呢?
什么是swap?
swap space是磁盘上的一块区域,可以是一个分区,也可以是一个文件,或者是他们的组合。
简单点说,当系统物理内存吃紧时,Linux会将内存中不常访问的数据保存到swap上,这样系统就有更多的物理内存为各个进程服务,而当系统需要访问swap上存储的内容时,再将swap上的数据加载到内存中,这就是我们常说的swap out和swap in。
为什么需要swap?
要回答这个问题,就需要回答swap给我们带来了哪些好处。
对于一些大型的应用程序(如LibreOffice、video editor等),在启动的过程中会使用大量的内存,但这些内存很多时候只是在启动的时候用一下,后面的运行过程中很少再用到这些内存。有了swap后,系统就可以将这部分不这么使用的内存数据保存到swap上去,从而释放出更多的物理内存供系统使。
很多发行版(如ubuntu)的休眠功能依赖于swap分区,当系统休眠的时候,会将内存中的数据保存到swap分区上,等下次系统启动的时候,再将数据加载到内存中,这样可以加快系统的启动速度,所以如果要使用休眠的功能,必须要配置swap分区,并且大小一定要大于等于物理内存。
在某些情况下,物理内存有限,但又想运行耗内存的程序怎么办?这时可以通过配置足够的swap空间来达到目标,虽然慢一点,但至少可以运行。
虽然大部分情况下,物理内存都是够用的,但是总有一些意想不到的状况,比如某个进程需要的内存超过了预期,或者有进程存在内存泄漏等,当内存不够的时候,就会触发内核的OOM killer,根据OOM killer的配置,某些进程会被kill掉或者系统直接重启(默认情况是优先kill耗内存最多的那个进程),不过有了swap后,可以拿swap当内存用,虽然速度慢了点,但至少给了我们一个去debug、kill进程或者保存当前工作进度的机会。
如果看过Linux内存管理,就会知道系统会尽可能多的将空闲内存用于cache,以加快系统的I/O速度,所以如果能将不怎么常用的内存数据移动到swap上,就会有更多的物理内存用于cache,从而提高系统整体性能。
swap的缺点?
上面介绍了swap的优点,那swap的缺点呢?swap是存放在磁盘上的,磁盘的速度和内存比较起来慢了好几个数量级,如果不停的读写swap,那么对系统的性能肯定有影响,尤其是当系统内存很吃紧的时候,读写swap空间发生的频率会很高,导致系统运行很慢,像死了一样,这个时候添加物理内存是唯一的解决办法。
由于系统会自动将不常用的内存数据移到swap上,对桌面程序来说,有可能会导致最小化一个程序后,再打开时小卡一下,因为需要将swap上的数据重新加载到内存中来。
到底要不要swap?
上面介绍了什么是swap以及它们的优缺点,那么到底要不要配置swap呢?答案是:看情况。
下面分别讨论内存不够用、内存勉强够用和内存很充裕这三种情况下服务器和桌面环境对swap的选择。
内存不够用
不管是桌面还是服务器,当物理内存明显不够用,而又想跑程序的话,添加swap是唯一的选择,慢点总比不能工作强。
内存勉强够用
建议配置swap,这样内核会将不常用的数据从内存移到swap上,从而有更多的物理内存供系统调用,提升系统性能,同时也避免因偶尔的物理内存不够造成进程异常退出,提升系统稳定性,但对服务器来说,一定要限制或者监控swap空间的使用情况,当出现swap空间使用超预期或者swap in/out频繁时,要及时采取措施,不然对性能影响很大
内存充裕
理论上来说,如果物理内存足够多并且不需要休眠功能,那swap就没什么用,可关键问题是我们很难保证物理内存在任何情况下都够用,因为总有意想不到的情况发生,比如某些进程耗内存超预期,服务器压力超预期,内存泄漏等。
目前,我们是明显内存不够用了,是什么导致内存不够用了呢?为什么mysql会直接导致服务器内存不够了
那我们的mysql的服务器为什么会发生swap呢?
假设我们的物理内存是16G,swap是4G。如果MySQL本身已经占用了12G物理内存, 而同时其他程序或者系统模块又需要6G内存,这时候操作系统就可能把MySQL所拥有的一部分地址空间映射到swap上去。
说白了,就是系统认为你mysql占用的空间太大了,不允许你搞特殊,必须腾出空间让那个我的其它必要的进程区使用内存,所以你就去比较慢的swap去玩吧!
而mysql中占内存最大的就是innodb_buffer_pool_size了,所以第一时间应考虑到这个值是不是设置的不合理?
MySQL的内存消耗分为:
- 1.会话级别的内存消耗:如sort_buffer_size等,每个会话都会开辟一个sort_buffer_size来进行排序操作
- 2.全局的内存消耗:例如:innodb_buffer_pool_size等,全局共享的内存段
这也是我觉得我们DBA不专业的地方,并没有考虑第一种情况,去查看回话级别的内存消耗情况,而是直接跟我说要调小innodb_buffer_pool_size
InnoDB的缓冲池缓存什么?有什么用?设置多大合适呢?
缓存表数据与索引数据,把磁盘上的数据加载到缓冲池,避免每次访问都进行磁盘IO,起到加速访问的作用。
给 Buffer Pool 分配越大的内存,MySQL 的并发性能就越好。那是不是都应该将百分之九十九的机器的内存都分配给 Buffe Pool 呢?
当然不是!先不说操作系统内核也需要几个G内存,MySQL 除了 Buffer Pool 还有很多别的内存数据结构呢,这些都是需要内存的,所以说,上面的想法是绝对不行的!
比较合理的比例,应该是 Buffer Pool 的内存大小占机器总内存的 50% ~ 60%。
可以通过show engine innodb status\G; 查看命中情况. 当命中没达到97%以上,都可以考虑加内存,当然这个和业务也有关例如对一个master的写入量大,读少就是特例.
其它情况如果没达到97%以上,对于读取多的情况,如果没达到98%以上,都说明buffer不够.可以扩. 再从另一方面来讲如果给分了20%的内存命中都能达到100%了,而且还有大量的free page那说明,那就够用了,另外也可以跟据free page去算一下可以再减少点内存. 把那些内存用到别用呢
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持编程网。