• Linux下swap升高的原因分析案例


    机器配置:2 CPU,8GB 内存

    需要预先安装 sysstat 等工具,如 yum  install sysstat

    终端中运行 free 命令,查看 Swap 的使用情况。

    $ free
                 total        used        free      shared  buff/cache   available
    Mem:        8169348      331668     6715972         696     1121708     7522896
    Swap:             0           0           0
    

      从这个 free 输出你可以看到,Swap 的大小是 0,这说明我的机器没有配置 Swap。为了继续 Swap 的案例, 就需要先配置、开启 Swap。如果你的环境中已经开启了 Swap,那你可以略过下面的开启步骤,继续往后走。要开启 Swap,我们首先要清楚,Linux 本身支持两种类型的 Swap,即 Swap 分区和 Swap 文件。以 Swap 文件为例,在第一个终端中运行下面的命令开启 Swap,这里配置 Swap 文件的大小为 8GB:

    # 创建Swap文件
    $ fallocate -l 8G /mnt/swapfile
    # 修改权限只有根用户可以访问
    $ chmod 600 /mnt/swapfile
    # 配置Swap文件
    $ mkswap /mnt/swapfile
    # 开启Swap
    $ swapon /mnt/swapfile
    

      再执行 free 命令,确认 Swap 配置成功:

    $ free
                 total        used        free      shared  buff/cache   available
    Mem:        8169348      331668     6715972         696     1121708     7522896
    Swap:       8388604           0     8388604
    

      现在,free  输出中,Swap 空间以及剩余空间都从 0 变成了 8GB,说明 Swap 已经正常开启。接下来,在第一个终端中,运行下面的 dd 命令,模拟大文件的读取:

    # 写入空设备,实际上只有磁盘的读请求
    $ dd if=/dev/sda1 of=/dev/null bs=1G count=2048
    

      接着,在第二个终端中运行 sar 命令,查看内存各个指标的变化情况。

    # 间隔1秒输出一组数据
    # -r表示显示内存使用情况,-S表示显示Swap使用情况
    $ sar -r -S 1
    04:39:56    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
    04:39:57      6249676   6839824   1919632     23.50    740512     67316   1691736     10.22    815156    841868         4
    
    04:39:56    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
    04:39:57      8388604         0      0.00         0      0.00
    
    04:39:57    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
    04:39:58      6184472   6807064   1984836     24.30    772768     67380   1691736     10.22    847932    874224        20
    
    04:39:57    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
    04:39:58      8388604         0      0.00         0      0.00
    
    …
    
    
    04:44:06    kbmemfree   kbavail kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
    04:44:07       152780   6525716   8016528     98.13   6530440     51316   1691736     10.22    867124   6869332         0
    
    04:44:06    kbswpfree kbswpused  %swpused  kbswpcad   %swpcad
    04:44:07      8384508      4096      0.05        52      1.27
    

      sar 的输出结果是两个表格,第一个表格表示内存的使用情况,第二个表格表示 Swap 的使用情况。其中,各个指标名称前面的 kb 前缀,表示这些指标的单位是 KB。

    大部分指标我们都已经见过了,剩下的几个新出现的指标,简单介绍一下。

    kbcommit,表示当前系统负载需要的内存。它实际上是为了保证系统内存不溢出,对需要内存的估计值。%commit,就是这个值相对总内存的百分比。

    kbactive,表示活跃内存,也就是最近使用过的内存,一般不会被系统回收。

    kbinact,表示非活跃内存,也就是不常访问的内存,有可能会被系统回收。

    清楚了界面指标的含义后,再结合具体数值,来分析相关的现象。可以清楚地看到,总的内存使用率(%memused)在不断增长,从开始的 23% 一直长到了 98%,并且主要内存都被缓冲区(kbbuffers)占用。具体来说:

    刚开始,剩余内存(kbmemfree)不断减少,而缓冲区(kbbuffers)则不断增大,由此可知,剩余内存不断分配给了缓冲区。

    一段时间后,剩余内存已经很小,而缓冲区占用了大部分内存。这时候,Swap 的使用开始逐渐增大,缓冲区和剩余内存则只在小范围内波动。

    还得看看进程缓存的情况。cachetop 正好能满足这一点。

    在第二个终端中,按下 Ctrl+C 停止 sar 命令,然后运行下面的 cachetop 命令,观察缓存的使用情况:

    $ cachetop 5
    12:28:28 Buffers MB: 6349 / Cached MB: 87 / Sort: HITS / Order: ascending
    PID      UID      CMD              HITS     MISSES   DIRTIES  READ_HIT%  WRITE_HIT%
       18280 root     python                 22        0        0     100.0%       0.0%
       18279 root     dd                  41088    41022        0      50.0%      50.0%
    

      通过 cachetop 的输出,dd 进程的读写请求只有 50% 的命中率,并且未命中的缓存页数(MISSES)为 41022(单位是页)。这说明,正是案例开始时运行的 dd,导致了缓冲区使用升高。

    这种情况,还得进一步通过 /proc/zoneinfo  ,观察剩余内存、内存阈值以及匿名页和文件页的活跃情况。

    可以在第二个终端中,按下 Ctrl+C,停止 cachetop 命令。然后运行下面的命令,观察 /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
    

      可以发现,剩余内存(pages_free)在一个小范围内不停地波动。当它小于页低阈值(pages_low) 时,又会突然增大到一个大于页高阈值(pages_high)的值。'

      再结合刚刚用 sar 看到的剩余内存和缓冲区的变化情况,我们可以推导出,剩余内存和缓冲区的波动变化,正是由于内存回收和缓存再次分配的循环往复。当剩余内存小于页低阈值时,系统会回收一些缓存和匿名内存,使剩余内存增大。其中,缓存的回收导致 sar 中的缓冲区减小,而匿名内存的回收导致了 Swap 的使用增大。紧接着,由于 dd 还在继续,剩余内存又会重新分配给缓存,导致剩余内存减少,缓冲区增大。

    其实还有一个有趣的现象,如果多次运行 dd 和 sar,可能会发现,在多次的循环重复中,有时候是 Swap 用得比较多,有时候 Swap 很少,反而缓冲区的波动更大。换句话说,系统回收内存时,有时候会回收更多的文件页,有时候又回收了更多的匿名页。显然,系统回收不同类型内存的倾向,似乎不那么明显。你应该想到了上节课提到的 swappiness,正是调整不同类型内存回收的配置选项。

    还是在第二个终端中,按下 Ctrl+C 停止 watch 命令,然后运行下面的命令,查看 swappiness 的配置:

    $ cat /proc/sys/vm/swappiness
    60
    

      swappiness 显示的是默认值 60,这是一个相对中和的配置,所以系统会根据实际运行情况,选择合适的回收类型,比如回收不活跃的匿名页,或者不活跃的文件页

    到这里,已经找出了 Swap 发生的根源

    还是推荐 proc 文件系统,用来查看进程 Swap 换出的虚拟内存大小,它保存在 /proc/pid/status 中的 VmSwap 中(推荐你执行 man proc 来查询其他字段的含义)。

    第二个终端中运行下面的命令,就可以查看使用 Swap 最多的进程。

    # 按VmSwap使用量对进程排序,输出进程名称、进程ID以及SWAP用量
    $ for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head
    dockerd 2226 10728 kB
    docker-containe 2251 8516 kB
    snapd 936 4020 kB
    networkd-dispat 911 836 kB
    polkitd 1004 44 kB
    

      从这里你可以看到,使用 Swap 比较多的是 dockerd 和 docker-containe 进程,所以,当 dockerd 再次访问这些换出到磁盘的内存时,也会比较慢。这也说明了一点,虽然缓存属于可回收内存,但在类似大文件拷贝这类场景下,系统还是会用 Swap 机制来回收匿名内存,而不仅仅是回收占用绝大部分内存的文件页。最后,如果你在一开始配置了 Swap,不要忘记在案例结束后关闭。你可以运行下面的命令,关闭 Swap:

    $ swapoff -a
    

      实际上,关闭 Swap 后再重新打开,也是一种常用的 Swap 空间清理方法,比如:

    $ swapoff -a && swapon -a 
    

      在内存资源紧张时,Linux 会通过 Swap ,把不常访问的匿名页换出到磁盘中,下次访问的时候再从磁盘换入到内存中来。你可以设置 /proc/sys/vm/min_free_kbytes,来调整系统定期回收内存的阈值;也可以设置 /proc/sys/vm/swappiness,来调整文件页和匿名页的回收倾向。当 Swap 变高时,你可以用 sar、/proc/zoneinfo、/proc/pid/status 等方法,查看系统和进程的内存使用情况,进而找出 Swap 升高的根源和受影响的进程。反过来说,通常,降低 Swap 的使用,可以提高系统的整体性能。也总结了几种常见的降低方法。禁止 Swap,现在服务器的内存足够大,所以除非有必要,禁用 Swap 就可以了。随着云计算的普及,大部分云平台中的虚拟机都默认禁止 Swap。如果实在需要用到 Swap,可以尝试降低 swappiness 的值,减少内存回收时 Swap 的使用倾向。响应延迟敏感的应用,如果它们可能在开启 Swap 的服务器中运行,你还可以用库函数 mlock() 或者 mlockall() 锁定内存,阻止它们的内存换出。

  • 相关阅读:
    redisTemplate写哈希表遇到的坑
    embedded-redis在单元测试中的使用
    使用Standford coreNLP进行中文命名实体识别
    字符编码和文件编码
    Elasticsearch提示low disk watermark [85%] exceeded on [UTyrLH40Q9uIzHzX-yMFXg][Sonofelice][/Users/baidu/Documents/work/soft/data/nodes/0] free: 15.2gb[13.4%], replicas will not be assigned to this node
    nginx.conf常用配置解析
    使用nginx搭建文件下载服务器
    lua连接数据库操作示例代码
    spring常见注解说明
    lua相关库安装常见问题
  • 原文地址:https://www.cnblogs.com/rdchenxi/p/13617625.html
Copyright © 2020-2023  润新知