swap深度多少比较好,swap大小跟开机速度有关不

目录
一、swap 案例测试
1、写入空设备，实际上只有磁盘的读请求
2、内存变化解释
二、如何影响内存回收的类型
1、swappiness
2、Swap 换出的是哪些进程的内存？
三、重新思考 "只有在内存不足时才会使用swap空间"这句话
四、如何关闭和开启swap
1、关闭swap
2、重启swap
五、思维导图
一、swap 案例测试
swap分区已在系统安装初期已经分配了swap分区。
[root@MiWiFi-R3L-srv opt]# lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTsdb 8:16 0 4G 0 disk sr0 11:0 1 4.4G 0 rom /run/media/root/CentOS 7 x86_64sda 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 availableMem: 954M 800M 69M 13M 85M 35MSwap: 2.0G 979M 1.0G1、写入空设备，实际上只有磁盘的读请求
opt]# dd if=/dev/sda2 of=/dev/null bs=1G count=204818+1 records in18+1 records out20400046080 bytes (20 GB) copied, 229.111 s, 89.0 MB/s运行 sar 命令，查看内存各个指标的变化情况
-r 表示显示内存使用情况，-S 表示显示 Swap 使用情况

文章插图
【swap深度多少比较好,swap大小跟开机速度有关不】

[root@MiWiFi-R3L-srv opt]# sar -r -S 1Linux 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 kbdirty09: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 kbdirty09:35:12 AM 85784 891816 91.23 40 272208 3997300 130.00 274444 415396 28 09:35:11 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:12 AM 1927452 169696 8.09 23276 13.72 09:35:12 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:13 AM 85784 891816 91.23 40 272208 3997300 130.00 274452 415396 28 09:35:12 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:13 AM 1927452 169696 8.09 23276 13.72 09:35:13 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:14 AM 98288 879312 89.95 55224 172936 5044044 164.05 345896 337468 28 09:35:13 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:14 AM 1910484 186664 8.90 21788 11.67 09:35:14 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:15 AM 71396 906204 92.70 13540 50140 5044044 164.05 356136 357736 28 09:35:14 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:15 AM 1873476 223672 10.67 26264 11.74 09:35:15 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:16 AM 48852 928748 95.00 13980 37700 5044044 164.05 367624 366716 28 09:35:15 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:16 AM 1749340 347808 16.58 54824 15.76 09:35:16 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:17 AM 50932 926668 94.79 8304 47412 5044044 164.05 363732 369396 0 09:35:16 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:17 AM 1584348 512800 24.45 62940 12.27 09:35:17 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:18 AM 53272 924328 94.55 14260 51760 5044044 164.05 365904 365524 0 09:35:17 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:18 AM 1468180 628968 29.99 50612 8.05 09:35:18 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:19 AM 49224 928376 94.96 13172 55504 5044044 164.05 368872 365920 0 09:35:18 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:19 AM 1371788 725360 34.59 14420 1.99 09:35:19 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:20 AM 48892 928708 95.00 10100 26964 5044044 164.05 367184 366388 0 09:35:19 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:20 AM 1239692 857456 40.89 47748 5.57 09:35:20 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:21 AM 48876 928724 95.00 14772 54496 5044044 164.05 368136 365364 0 09:35:20 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:21 AM 1101684 995464 47.47 47680 4.79 09:35:21 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:22 AM 60012 917588 93.86 12216 28456 5044044 164.05 359040 363484 0 09:35:21 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:22 AM 1099932 997216 47.55 54460 5.46 09:35:22 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:23 AM 63440 914160 93.51 24132 66228 5044044 164.05 361648 357520 8 09:35:22 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:23 AM 1055728 1041420 49.66 47376 4.55 09:35:23 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:24 AM 68136 909464 93.03 10888 32000 5044044 164.05 354028 360484 8 09:35:23 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09:35:24 AM 1099504 997644 47.57 46220 4.63 09:35:24 AM kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty09:35:25 AM 70392 907208 92.80 7616 32936 5044044 164.05 363100 348932 8 09:35:24 AM kbswpfree kbswpused %swpused kbswpcad %swpcad09: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/zoneinfoNode 0, zone Normalpages free 21328min 14896low 18620high 22344spanned 1835008present 1835008managed 1796710protection: (0, 0, 0, 0, 0)nr_free_pages 21328nr_zone_inactive_anon 79776nr_zone_active_anon 206854nr_zone_inactive_file 918561nr_zone_active_file 496695nr_zone_unevictable 2251nr_zone_write_pending 0

将Nornmal 换成DMA 也可监控到DMA区域的内存分配情况。
剩余内存（pages_free）在一个小范围内不停地波动。当它小于页低阈值（pages_low) 时，又会突然增大到一个大于页高阈值（pages_high）的值。
结合刚刚用 sar 看到的剩余内存和缓冲区的变化情况，我们可以推导出，剩余内存和缓冲区的波动变化，正是由于内存回收和缓存再次分配的循环往复。
结合图片理解更深刻。

文章插图
当剩余内存小于页低阈值时，系统会回收一些缓存和匿名内存，使剩余内存增大。其中，缓存的回收导致缓冲区减?。涿诖娴幕厥盏贾铝?Swap 的使用增大。
紧接着，由于 dd 还在继续，剩余内存又会重新分配给缓存，导致剩余内存减少，缓冲区增大。

文章插图
二、如何影响内存回收的类型
1、swappiness
cat /proc/sys/vm/swappiness60swappiness的值的大小对如何使用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 | headawk: cmd. line:1: fatal: cannot open file `/proc/26704/status' for reading (No such file or directory)klzagent 5583 81216 kBpostgres 9910 44568 kBpostgres 9904 44460 kBpostgres 10318 43472 kBpostgres 10750 43408 kBpython 63780 40876 kBpython 61114 40872 kBpython 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 availableMem: 977600 737252 80728 43944 159620 67384Swap: 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 availableMem: 954M 721M 67M 42M 165M 59MSwap: 2.0G 0B 2.0G[root@MiWiFi-R3L-srv opt]#

五、思维导图

文章插图