• 通过free命令了解Linux系统内存状态


    一、free命令作用

    在大多数Linux发行版中都可以通过 free 命令来查看显示系统内存状态,该命令主要会汇总出包括系统物理内存、swap 交换分区、共享内存和系统缓存的使用情况。这些数据主要是从/proc/meminfo中读出并解析得到。
    可以通过free --help 查看该命令的使用方法,也可以通过man free查看该命令的详细操作手册。(程序员在旅途

    二、使用示例

    [root@docker-registry ~]# free -h
                  total        used        free      shared  buff/cache   available
    Mem:           2.7G        672M        1.7G         12M        420M        1.8G
    Swap:          2.0G          0B        2.0G
    
    • 1
    • 2
    • 3
    • 4
    参数解析
    total 是物理内存大小;
    used 是已经使用的内存大小,包括了 buff/cache 和 应用程序实际使用的内存;
    free 是空闲的内存数,没有被真正使用的内存空间;
    shared 是共享内存大小,共享内存是进程间通信的一种方式;
    buff/cache 系统为了提高文件的读写速率而使用的一块内存空间,当应用程序需要使用内存时,这块内存是可以很快被回收而被用户空间程序使用。
    available,估算的是当前系统中有多少内存可以用于应用程序的使用,buff/cache占用的内存在有需要的时候是可以被回收的。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    available和free的区别

    可用内存=系统free memory+buff/cache。free是系统中空闲的内存大小,buff/cache虽然是在需要的时候可以回收的,但是当前也是被利用状态,available统计的是应用程序可用内存空间,buff/cache是可回收,可被应用程序使用的。从应用程序角度来看,对于应用程序来说,buffers/cached 是等于可用的,因为buffer/cached是为了提高文件读取的性能,当应用程序需在用到内存的时候,buffer/cached会很快地被回收。

    buff/cache机制

    buff/cache是为了协调内存与磁盘文件读写IO速率差异性、提高系统的工作效率而设计的。
    cache
    cache 就是缓存的意思。当系统读文件的时候,是把数据从硬盘读到内存里,因为硬盘比内存慢很多,所以这个过程会很耗时。为了提高效率,linux 会把读进来的文件在内存中缓存下来,供程序接下来使用,即使程序结束,cache 也不会被自动释放,系统会根据换出算法把cache缓存置换出去。所以如果有程序进行大量的读文件操作,内存使用率也会相应的提高。

    buffer
    buffer 和 cache 相近,稍有区别。考虑内存写文件到硬盘的过程,内存和磁盘的IO差距很大,如果内存要等待数据写完之后才继续后面的操作,会影响程序的运行速度,也会降低系统的相应。所以系统设计了 buffer,写到硬盘的数据会放到 buffer 里面,内存很快把数据写到 buffer,可以继续其他的工作,而硬盘可以在后台慢慢读出 buffer 中的数据,保存起来。这样就提高了读写的效率。

    以下对cache做一个验证,在有cache的情况下,读写IO会快很多:

    [root@docker-registry test]# time dd if=/dev/zero of=test.log bs=1M count=500
    500+0 records in
    500+0 records out
    524288000 bytes (524 MB) copied, 5.04675 s, 104 MB/s
    
    real    0m5.067s
    user    0m0.006s
    sys     0m5.056s
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    [root@docker-registry test]# time dd if=test.log of=/dev/zero bs=1M count=500
    500+0 records in
    500+0 records out
    524288000 bytes (524 MB) copied, 0.145132 s, 3.6 GB/s
    
    real    0m0.151s
    user    0m0.002s
    sys     0m0.149s
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    观察 buffer/cache

    [root@docker-registry test]# free -h
                  total        used        free      shared  buff/cache   available
    Mem:           2.7G        693M        950M         59M        1.1G        1.7G
    Swap:          2.0G          0B        2.0G
    
    • 1
    • 2
    • 3
    • 4

    然后手动清理一下 cache:

    echo 1 > /proc/sys/vm/drop_caches

    [root@docker-registry test]# free -h
                  total        used        free      shared  buff/cache   available
    Mem:           2.7G        695M        1.6G         59M        417M        1.8G
    Swap:          2.0G          0B        2.0G
    
    • 1
    • 2
    • 3
    • 4

    然后再操作该文件,可见慢很多

    [root@docker-registry test]# time dd if=test.log of=/dev/zero bs=1M count=500
    500+0 records in
    500+0 records out
    524288000 bytes (524 MB) copied, 4.08157 s, 128 MB/s
    
    real    0m4.086s
    user    0m0.002s
    sys     0m4.083s
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    以上,可看到buff/cache对IO的的提升还是很明显的。

  • 相关阅读:
    Java 异步调用实践
    JavaScript继承的几种方式
    基于模型设计和机载软件
    Android批量加载图片OOM问题
    算法·每日一题(详解+多解)-- day15
    构建汽车技术与装备交流平台,“中国汽研”开启汽车产业高质量发展新章
    eunomia-bpf: 让 eBPF 程序的开发和部署尽可能简单
    Vue.js核心技术解析与uni-app跨平台实战开发学习笔记 第3章 Vue.js生命周期函数 3.3 销毁期间生命周期函数 && 3.4 扩展
    解决运行Docker镜像报错:version `GLIBC_2.32‘ not found
    软件或游戏提示msvcp120.dll丢失的5种常用解决方法,msvcp120.dll文件全面解析
  • 原文地址:https://blog.csdn.net/qq_24754061/article/details/126567078