乐趣区

关于mysql:技术分享-MemAvailable-是怎么计算的

jiezi

作者：胡呈清

爱可生 DBA 团队成员，善于故障剖析、性能优化，集体博客：https://www.jianshu.com/u/a95…，欢送探讨。

本文起源：原创投稿

* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

背景

前两天装置 OceanBase 时遇到一个小问题：

很显著，装置 OB 时要求服务器可用内存至多 8G，不达标就无奈装置。为了凑这 3 台 10G 内存的服务器我曾经费了不少劲了，free -m 输入中 free 不是有 9G 吗，为什么还报错？

认真一看上图，available 只有 6.3G，而 OB 装置报错的 Free 其实是 available。

那为什么 free -m 输入中：free 有 9.3G，而 available 只有 6.3G 呢？

通常咱们会把 MemAvailable 看成是 buffer/cache、free 之和。但实际上不是，它其实还跟 min_free_kbytes 有着密切关系。

min_free_kbytes

kswapd 是专门用来定期回收内存的过程。为了掂量内存的应用状况，定义了三个内存阈值（watermark，也称为水位），别离是 watermark[min/low/high]：

上图根本揭示了几个水位的含意，当 MemFree 低于 watermark[low] 时，kswapd 进行内存回收，直到闲暇内存达到 watermark[high] 后进行回收。如果申请内存的速度太快，导致闲暇内存降至 watermark[min] 后，内核就会进行 direct reclaim（间接回收），用回收上来的闲暇页满足内存申请，这样会阻塞应用程序。而 watermark[min] 的大小等于内核参数 min_free_kbytes 的值，其余几个水位的关系是：

  • watermark[low] = watermark[min]*5/4
  • watermark[high] = watermark[min]*3/2

MemAvailable

显然 watermark[min] 以下的内存属于零碎的自留内存，不会给一般过程申请应用。而 MemAvailable 意为能够调配应用的内存，因而它不该当蕴含这一块内存。实际上其计算公式为：

MemAvailable = MemFree - watermark[LOW] + (PageCache - min(PageCache / 2, watermark[LOW]))

晓得了 MemAvailable 是怎么计算的，接下来就很简略了，先查看 min_free_kbytes 的设置：

[[email protected] ~]# cat /proc/sys/vm/min_free_kbytes
2097152

2G 是 OB 的部署标准，因为是测试环境，将它批改为 64M 后，MemAvailable 就符合要求了：

min_free_kbytes 设置倡议

OB 的部署标准中，规定 min_free_kbytes=2G，不得不说这个点很细节，因为：

  1. 零碎会依据内存大小主动计算出 min_free_kbytes 大小，但并不是线性关系，取值范畴是 128K-64M，如果零碎开启了大页，则最大值通常会超过 64M，但也不会很大，以上面这台服务器为例，256G 内存，min_free_kbytes 只有 132M：
[email protected]:~# cat /proc/sys/vm/min_free_kbytes
135168
[email protected]:~# free -m
              total        used        free      shared  buff/cache   available
Mem:         257897       60060        2068       18161      195768      178009
Swap:           616           6         610
  1. 如果 min_free_kbytes 设置的很小，则零碎残余可用内存容易触底，direct reclaim 会造成性能重大升高。相同如果设置的很大，则 watermark[min/low/high] 这 3 个水位都会很大，常常触发内存回收，使内存利用率升高。

所以为零碎预留 2G 内存非常正当，是一个很容易被疏忽的优化点。

参考资料

https://git.kernel.org/pub/sc…

退出移动版