一、swap 案例测试
swap分区已在系统安装初期已经分配了swap分区。
[root@MiWiFi-R3L-srv opt]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb 8:16 0 4G 0 disk sr0 11:0 1 4.4G 0 rom /run/media/root/CentOS 7 x86_64 sda 8:0 0 20G 0 disk ├─sda2 8:2 0 19G 0 part │ ├─centos-swap 253:1 0 2G 0 lvm [SWAP] │ └─centos-root 253:0 0 17G 0 lvm / └─sda1 8:1 0 1G 0 part /boot
swap分区总共2GB。
[root@MiWiFi-R3L-srv opt]# free -h total used free shared buff/cache available Mem: 954M 800M 69M 13M 85M 35M Swap: 2.0G 979M 1.0G
1、写入空设备，实际上只有磁盘的读请求
opt]# dd if=/dev/sda2 of=/dev/null bs=1G count=2048 18+1 records in 18+1 records out 20400046080 bytes (20 GB) copied, 229.111 s, 89.0 MB/s
运行 sar 命令，查看内存各个指标的变化情况
-r 表示显示内存使用情况，-S 表示显示 Swap 使用情况
[root@MiWiFi-R3L-srv opt]# sar -r -S 1 Linux 5.8.0-1.el7.elrepo.x86_64 (MiWiFi-R3L-srv) 08/16/2020 _x86_64_ (1 CPU) 09:34:56 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:58:56 AM 351048 626552 64.09 15812 216168 3963104 128.89 121256 302304 0 09:35:11 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:12 AM 85784 891816 91.23 40 272208 3997300 130.00 274444 415396 28 09:35:11 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:12 AM 1927452 169696 8.09 23276 13.72 09:35:12 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:13 AM 85784 891816 91.23 40 272208 3997300 130.00 274452 415396 28 09:35:12 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:13 AM 1927452 169696 8.09 23276 13.72 09:35:13 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:14 AM 98288 879312 89.95 55224 172936 5044044 164.05 345896 337468 28 09:35:13 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:14 AM 1910484 186664 8.90 21788 11.67 09:35:14 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:15 AM 71396 906204 92.70 13540 50140 5044044 164.05 356136 357736 28 09:35:14 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:15 AM 1873476 223672 10.67 26264 11.74 09:35:15 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:16 AM 48852 928748 95.00 13980 37700 5044044 164.05 367624 366716 28 09:35:15 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:16 AM 1749340 347808 16.58 54824 15.76 09:35:16 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:17 AM 50932 926668 94.79 8304 47412 5044044 164.05 363732 369396 0 09:35:16 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:17 AM 1584348 512800 24.45 62940 12.27 09:35:17 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:18 AM 53272 924328 94.55 14260 51760 5044044 164.05 365904 365524 0 09:35:17 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:18 AM 1468180 628968 29.99 50612 8.05 09:35:18 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:19 AM 49224 928376 94.96 13172 55504 5044044 164.05 368872 365920 0 09:35:18 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:19 AM 1371788 725360 34.59 14420 1.99 09:35:19 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:20 AM 48892 928708 95.00 10100 26964 5044044 164.05 367184 366388 0 09:35:19 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:20 AM 1239692 857456 40.89 47748 5.57 09:35:20 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:21 AM 48876 928724 95.00 14772 54496 5044044 164.05 368136 365364 0 09:35:20 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:21 AM 1101684 995464 47.47 47680 4.79 09:35:21 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:22 AM 60012 917588 93.86 12216 28456 5044044 164.05 359040 363484 0 09:35:21 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:22 AM 1099932 997216 47.55 54460 5.46 09:35:22 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:23 AM 63440 914160 93.51 24132 66228 5044044 164.05 361648 357520 8 09:35:22 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:23 AM 1055728 1041420 49.66 47376 4.55 09:35:23 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:24 AM 68136 909464 93.03 10888 32000 5044044 164.05 354028 360484 8 09:35:23 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:24 AM 1099504 997644 47.57 46220 4.63 09:35:24 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 09:35:25 AM 70392 907208 92.80 7616 32936 5044044 164.05 363100 348932 8 09:35:24 AM kbswpfree kbswpused %swpused kbswpcad %swpcad 09:35:25 AM 1097724 999424 47.66 47872 4.79
主要参数解释：
kbcommit，表示当前系统负载需要的内存。它实际上是为了保证系统内存不溢出，对 需要内存的估计值。%commit，就是这个值相对总内存的百分比。 kbactive，表示活跃内存，也就是最近使用过的内存，一般不会被系统回收。 kbinact，表示非活跃内存，也就是不常访问的内存，有可能会被系统回收 注： kbcommit就是进程申请的内存之和，kbmemused还包括了buffer和cache
2、内存变化解释
总的内存使用率（%memused）在不断增长，从开始的 64% 一直长到了 95%，并且主要内存都被缓冲区（kbbuffers）占用
刚开始，剩余内存（kbmemfree）不断减少，而缓冲区（kbbuffers）则不断增大，由此可知，剩余内存不断分配给了缓冲区。
一段时间后，剩余内存已经很小，而缓冲区占用了大部分内存。这时候，Swap 的使用开始逐渐增大，缓冲区和剩余内存则只在小范围内波动。
为什么 Swap 也跟着升高了呢？直观来说，缓冲区占了系统绝大部分内存，还属于可回收内存，内存不够用时，不应该先回收缓冲区？
观察/proc/zoneinfo
# -d 表示高亮变化的字段
# -A 表示仅显示 Normal 行以及之后的 15 行输出
$ watch -d grep -A 15 'Normal' /proc/zoneinfo Node 0, zone Normal pages free 21328 min 14896 low 18620 high 22344 spanned 1835008 present 1835008 managed 1796710 protection: (0, 0, 0, 0, 0) nr_free_pages 21328 nr_zone_inactive_anon 79776 nr_zone_active_anon 206854 nr_zone_inactive_file 918561 nr_zone_active_file 496695 nr_zone_unevictable 2251 nr_zone_write_pending 0
将Nornmal 换成DMA 也可监控到DMA区域的内存分配情况。
剩余内存（pages_free）在一个小范围内不停地波动。当它小于页低阈值（pages_low) 时，又会突然增大到一个大于页高阈值（pages_high）的值。
结合刚刚用 sar 看到的剩余内存和缓冲区的变化情况，我们可以推导出，剩余内存和缓冲区的波动变化，正是由于内存回收和缓存再次分配的循环往复。
结合图片理解更深刻。
当剩余内存小于页低阈值时，系统会回收一些缓存和匿名内存，使剩余内存增大。其中，缓存的回收导致缓冲区减小，而匿名内存的回收导致了 Swap 的使用增大。
紧接着，由于 dd 还在继续，剩余内存又会重新分配给缓存，导致剩余内存减少，缓冲区增大。
二、如何影响内存回收的类型
1、swappiness
cat /proc/sys/vm/swappiness 60
swappiness的值的大小对如何使用swap分区是有着很大的联系的。swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。
这是一个相对中和的配置，所以系统会根据实际运行情况，选择合适的回收类型，比如回收不活跃的匿名页，或者不活跃的文件页。
2、Swap 换出的是哪些进程的内存？
查看进程 Swap 换出的虚拟内存大小可以在/proc/pid/status 中的 VmSwap 中查看
按 VmSwap 使用量对进程排序，输出进程名称、进程 ID 以及 SWAP 用量
opt]# for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head awk: cmd. line:1: fatal: cannot open file `/proc/26704/status' for reading (No such file or directory) klzagent 5583 81216 kB postgres 9910 44568 kB postgres 9904 44460 kB postgres 10318 43472 kB postgres 10750 43408 kB python 63780 40876 kB python 61114 40872 kB python 62813 40864 kB
使用 Swap 比较多的是 postgres 进程，所以，当 postgres再次访问这些换出到磁盘的内存时，也会比较慢。
三、重新思考 "只有在内存不足时才会使用swap空间"这句话
此时再看这句话并不是完全正确的，我们平时看到的情景可能是缓存还有很多，为什么有的进程还是会使用swap空间，不应该是回收缓冲区内存来使用吗？
1、swap非内存不足使用场景
大文件拷贝这类场景下，系统还是会用 Swap 机制来回收匿名内存，而不仅仅是回收占用绝大部分内存的文件页。
四、如何关闭和开启swap
1、关闭swap
opt]# swapoff -a [root@MiWiFi-R3L-srv opt]# free total used free shared buff/cache available Mem: 977600 737252 80728 43944 159620 67384 Swap: 0 0 0 [root@MiWiFi-R3L-srv opt]#
2、重启swap
关闭 Swap 后再重新打开，也是一种常用的 Swap 空间清理方法
[root@MiWiFi-R3L-srv opt]# swapoff -a && swapon -a [root@MiWiFi-R3L-srv opt]# free -h total used free shared buff/cache available Mem: 954M 721M 67M 42M 165M 59M Swap: 2.0G 0B 2.0G [root@MiWiFi-R3L-srv opt]#
五、思维导图
