内存、swap相关查看

内存

centos 6.5 内存查看

    最近有个月经问题，老有人问为何开机后，还没有其他服务，mem就被用完了？是不是内存泄露？是否要重启服务？只能说不要看现象，要看本质才能找到问题的根源。

往往给出这样的结果，怀疑内存用了90%：
Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers
Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

 

    这样怀疑很普遍，因为很多人用惯了Windows。Windows下，可以使用任务管理器查看当前进程对于内存的消耗情况。在我看来，Windows物理内存总是留下一定的空间，就算此时物理内存有a空闲时，也会让某些程序去使用虚拟内存，目的是在Windows下启动新程序时，直接分配空闲的物理内存，这样子新程序启动速度就较快，而Linux则不然。

而在Linux下，使用top命令看到内存占用情况：

Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers
Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

这里的结果显示使用了3.8G的used，占用率达到90%。看看free的结果你还可以对比一下：
$ free -m
total used free shared buffers cached
Mem: 4049 3784 265 0 208 2939
-/+ buffers/cache: 636 3413
Swap: 2588 0 2588

虽然MEM显示了3.7G左右的used，但是（-/+ buffers/cache）减去buffers和cache的结果可以看到，当前进程实际占用内存是636M，而可用空闲（free）内存为3.4G。

    可以这么理解：在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快。

     如上面的例子：使用了4G的内存，3.7G被占用，但是buuffer和cached部分作为缓存，可以使用命中率的方式提高使用效率，而且这部分缓存是根据指令随时可以释放的，我们可以认为这部分内存没有实际被使用，也可以认为它是空闲的。

    因此查看目前进程正在实际被使用的内存，是used-(buffers+cache)，也可以认为如果swap没有大量使用，mem还是够用的，只有mem被当前进程实际占用完（没有了buffers和cache），才会使用到swap的。

centos 7 内存查看

                    total        used        free      shared  buff/cache   available
Mem:           7.6G        714M        5.4G        408M        1.6G        6.1G
Swap:          2.0G        172M        1.8G
直接通过 available 可查看物理可用内存

 

buffers 与 cached 的区别

　　对于应用程序来说，buffers/cached 是等于可用的，

　　因为buffer/cached是为了提高文件读取的性能，

　　当应用程序需在用到内存的时候，buffer/cached会很快地被回收。

　　所以从应用程序的角度来说 可用内存=系统free memory+buffers+cached.

　　buffers是指用来给块设备做的缓冲大小，

　　他只记录文件系统的metadata以及 tracking in-flight pages.

　　cached是用来给文件做缓冲。

　　那就是说：buffers是用来存储，目录里面有什么内容，权限等等。

　　而cached直接用来记忆我们打开的文件，如果你想知道他是不是真的生效，

　　可以试一下，先后执行两次命令#man X ,可以明显的感觉到第二次的开打的速度快很多。

 

swap

swap作用

    Linux中Swap（即：交换分区），类似于Windows的虚拟内存，就是当内存不足的时候，把一部分硬盘空间虚拟成内存使用,从而解决内存容量不足的情况。Android是基于Linux的操作系统，所以也可以使用Swap分区来提升系统运行效率[1]  。

    交换分区，英文的说法是swap，意思是“交换”、“实物交易”。它的功能就是在内存不够的情况下，操作系统先把内存中暂时不用的数据，存到硬盘的交换空间，腾出内存来让别的程序运行，和Windows的虚拟内存（pagefile.sys）的作用是一样的。

swap查看

# 查看当前内存
free -g

# 查看交换分区使用情况
swapon -s

# 创建一个分区添加交换文件，创建交换空间，然后启动新增的交换空间(1G大小)
dd if=/dev/zero of=/data0/swap bs=1024 count=1024000   
/sbin/mkswap /data0/swap
/sbin/swapon /data0/swap

# 再次查看内存情况
free -g

修改/etc/fstab,使新加的2G交换空间在系统重新启动后自动生效
echo "/opt/temp/swap swap swap defaults 0 0" >>/etc/fstab

如果系统的物理内存用光了，则会用到swap。系统就会跑得很慢，但仍能运行;如果Swap空间用光了，那么系统就会发生错误。通常会出现“application is out of memory”的错误，严重时会造成服务进程的死锁。所以要高度重视。

swap空间大小

　　通常情况下，Swap空间应大于或等于物理内存的大小，最小不应小于64M，通常Swap空间的大小应是物理内存的2-2.5倍。但根据不同的应用，应有不同的配置：如果是小的桌面系统，则只需要较小的Swap空间，而大的服务器系统则视情况不同需要不同大小的Swap空间。特别是数据库服务器和Web服务器，随着访问量的增加，对Swap空间的要求也会增加，具体配置参见各服务器产品的说明。

swap数量

　　Swap分区的数量对性能也有很大的影响。因为Swap交换的操作是磁盘IO的操作，如果有多个Swap交换区，Swap空间的分配会以轮流的方式操作于 所有的Swap，这样会大大均衡IO的负载，加快Swap交换的速度。如果只有一个交换区，所有的交换操作会使交换区变得很忙，使系统大多数时间处于等待 状态，效率很低。用性能监视工具就会发现，此时的CPU并不很忙，而系统却慢。这说明，瓶颈在IO上，依靠提高CPU的速度是解决不了问题的。

物理内存接近饱和时，系统会自动将不常用的内存文件转储到SWAP中，但SWAP使用率达30%的时候对系统性能可能有一定影响。

对于较大物理内存的VPS或服务器，或根据自己服务器的情况，可以考虑手动关闭或刷新SWAP分区。

sync                         # 先执行下同步
swapoff -a                   # 关闭swap分区
swapon -a                    # 开启swap分区
swapoff -a && swapon -a      # 刷新swap空间，即将SWAP里的数据转储回内存，并清空SWAP里的数据。刷新原理就是把swap关闭后再重启。

哪些因素可能影响SWAP
内存不足无疑会SWAP，但有些时候，即便看上去内存很充裕，还可能会SWAP，这种现象被称为SWAP Insanity，罪魁祸首主要有以下几点：

Swappiness的迷失

实际上，当可用内存不足时，系统有两个选择：一个是通过SWAP来释放内存，另一个是删除Cache中的Page来释放内存。一个很常见的例子是：当拷贝大文件的时候，时常会发生SWAP现象。这是因为拷贝文件的时候，系统会把文件内容在Cache中按Page来缓存，此时一旦可用内存不足，系统便会倾向于通过SWAP来释放内存。

内核中的swappiness参数可以用来控制这种行为，缺省情况下，swappiness的值是60：

shell> sysctl -a | grep swappiness
vm.swappiness = 60
它的含义是：如果系统需要内存，有百分之六十的概率执行SWAP。知道了这一点，我们很自然的会想到用下面的方法来降低执行SWAP的概率：

shell> echo "vm.swappiness = 1" >> /etc/sysctl.conf
shell> sysctl -p
这样做的确可以降低执行SWAP的概率，但并不意味着永远不会执行SWAP。据网友报道某些情况下，直接改为0有可能出现灵异问题，所以建议改为1。

 

Sync命令

    在用reboot命令启动unix系统后，系统提示出错信息，部分应用程序不能正常工作。经仔细检查系统文件，并和初始的正确备份进行比较，发现某些文件确实被破坏了，翻来覆去找不到文件遭破坏的原因，最后想到了写缓存命令——sync，在reboot前没有运行sync命令，导致了系统文件的改变而不能正常工作。   

　　sync命令的作用是，将有关文件系统的存储器常驻信息送入物理介质内。在暂停系统之前，比如要重新启动机器，一定要去执行sync命令。unix系统运行经验表明，为确保可靠起见，应执行两遍sync命令，这是因为sync命令完成时，并不保证信息实际写到了磁盘上，虽然已经执行了一遍这个命令。在执行sync命令以后，要等待磁盘工作灯灭了（假定有系统工作指示灯的话），再去真正暂停机器的运行或启动机器。

    unix系统遭受破坏是随时都可能发生的事情，因此在启动机器或关机之前一定要运行sync命令。记住在任何情况下，慎重地执行sync命令决不会有任何坏处  

umount时间过长，sync命令的使用

    有一个问题,比如 cp 一个文件到SD卡上,是不是首先先将这个文件写到SDRAM上,然后umount的时候再将SDRAM中的内容真正写SD卡上? 我umount的时候会过多一会才出现终端的提示符,根据写入文件的大小确定 umount的时间?  

    后来查了一下资料,Linux文件系统更新是一个复杂的过程，当用户程序对文件系统进行修改以后，例如进行了写操作，文件数据把修改记录在内核缓冲中，在数据没有写到磁盘的时候，依然能够执行用户进程，所有数据的改变都在inode的内容中得到反映。磁盘的数据更新实际上是异步进行的，很有可能在写操作已经完成很长时间以后才真正对磁盘的数据进行更新。

    sync命令强制把磁盘缓冲的所有数据写入磁盘，如果在没有把磁盘缓冲区的信息写入磁盘之前终止系统，则磁盘的文件系统就会处在一个不稳定的状态。而在正常模式下即使没有对分区进行umount的操作，在重启之前系统会调用sync命令强制把磁盘缓冲的所有数据写入磁盘,而在急救模式下必须对所挂的分区进行umount的操作,系统才会调用sync命令强制把磁盘缓冲的所有数据写入磁盘，请在急救模式下的朋友注意这个问题。其实“reboot -n(Don’t sync before reboot or halt)”在重启之前不用sync命令强制把磁盘缓冲的所有数据写入磁盘,就很能说明问题。  

所以要 cp 完之后要执行 sync 命令将缓冲区的内容写到磁盘中,然后再umount 就不会出现延时了.

经验证，采用此方法，延迟写入问题可以解决