free命令
free命令用于查看系统内存信息
常用选项：
-m：以MB为单位显示
-g：以GB为单位显示
-h：以人类易读的方式显示
运行示例：
运行结果的前面3 个字段很容易理解，但是used + free 的值显然不等于total，这就要看后面两个字段了，shared 为共享内存，进程间通讯使用，buff/cache 叫缓存，从红帽7 开始，buff 和 cache 这两个值合并为一个字段显示，以前是分开的，区别在于buff 是inode 索引的缓存，cache 是data 数据的缓存，buff/cache 是读缓存，我们经常做的一件事情是提升内存的读性能通过读缓存来实现，读cache 提升读性能，写cache 提升写性能，看起来是一句废话，那它们是如何实现的呢？
读cache 提升读性能
当从硬盘中读取数据时，会先将数据读到内存中，当数据处理完成后，依然将数据保留在内存中，下次需要调用这些数据时，就直接从内存中读取，而不需要从硬盘中读取，提升读性能。
我们可以做一个这样的实验：
传递这个内核参数，清理缓存区的数据：
在任何命令前，加一个time，这样可以计算执行后面的命令，需要多长时间。
这个时候，/usr 目录4.6G 的数据，几乎全部写进了buff/cache缓存区，内存资源被消耗殆尽，这个数据即便已经写完了，但会一直保留在缓存中。
再建一个文件夹，我们再拷贝一次：
这个时候，往/redhat 目录拷贝/usr 的数据，系统会直接从缓存中读取，所以运行速度相比第一次更快了一点，看起来提升并不是很明显，但是如果服务器上有一个数据会被访问一千次呢？那么这个读缓存就非常有意义了！
那么问题来了，这个数据会在内存中缓存多久呢？这个问题非常好！
只要内存不紧张，它会一直保留着，当内存紧张的时候，自动释放。这样可以提升读性能。
通常有两种情况，我们需要释放缓存：
1、基线测试（baseline test）
什么叫基线测试，比如说我想测一下磁盘的性能，这个时候如果是因为缓存没有释放掉，测试的读取速度是读缓存区的数据会导致测试结果不准确。这个时候可以手动清理缓存，执行sysctl -w vm.drop_caches=3，这个内核参数看起来很奇怪，为什么值等于3，而不是1或2呢？这是历史遗留问题，1是清空buff，2是清空cache，3是把这两个都清空，但是因为现在buff/cache合并为一个字段了，所以也是3。
再来看，缓存区已经清理完成了，但为什么没有被清成0 呢？因为有些缓存数据可能仍然正在被使用。
有些系统执行这条手动清理的命令可能不会生效，这个时候应该检查下面这个内核参数值：
特别是在安装了容器的机器上，有些教程可能会让我们把这个内核参数设置成0，这个取值范围是0-100，如果设置成0，那么即使是内存紧张的时候，缓存区的数据也不会被释放。所以这个内核参数调整的是：当系统内存资源紧张的时候，是更倾向于把它释放掉，还是倾向于保留。
2、机器休眠
机器在做休眠的时候，系统会把缓存区的数据写回到硬盘，这个过程影响休眠的速度，因此可以提前把数据清理掉。
写cache 提升写性能
当写入数据的时候，先将数据写入到内存中，在内存中将不连续的IO 整合成连续的IO，再一次地写入硬盘。这种数据写入方式类似于电梯调度算法，举例来说：
第一个IO请求：往磁盘第50扇区写入数据
第二个IO请求：写第10000个扇区
第三个IO请求：写第600个扇区
第四个IO请求：写11000个扇区
这个时候，如果没有写缓存，按照顺序写入的方法，磁盘的磁头移动到第50个扇区，然后移动到第10000个扇区，再移回第600个扇区... 磁头来回移动，混乱无序，这样来写入数据效率是非常低效的。这里又涉及到两个概念了，回写与透写：
回写：数据先写缓存，经过整合以后再写硬盘；
透写：数据不写缓存，直接写硬盘。
如果是用回写的方式，数据写缓存经过整合以后，写入到磁盘的时候先处理第一个IO请求，然后处理第三个、第二个、第四个。所以从硬件的角度来看：不是写缓存的方式提升了写性能，而是数据整合。
但是回写有个前提条件：缓存（内存）的写入速度要比主存（硬盘）快，这样才有意义。
来做一个小实验：
往/tmp 目录写入一个文件：
写入时间只花了不到一秒钟，非常快...
但如果，给dd 命令加一个参数：oflag=direct，这个作用是直接写数据到硬盘，不写缓存。
这次花了20多秒，相比之下慢了很多。
那么，同样的问题再次出现：写入的数据会在缓存中保留多久呢？
写缓存也可以和读缓存一样，只要内存不紧张，一直保留在里面吗？
显然是不可以，因为这些数据都属于脏数据（在内存中已经发生变化，还未写入硬盘的数据），一旦出现异常（掉电、死机等情况），将导致数据丢失。
那多久写入硬盘呢？实时吗？肯定不是，因为这样就无法进行整合了。那保留10分钟？这样风险太大。Linux系统中，这个值默认是30秒。
这个值的单位很奇怪，不是毫秒，也不是秒，而是百分之一秒，3000即是30秒。
这个值可以更改，通过写入到/etc/sysctl.conf 文件的方式：
那么如何测试这个值呢？在系统的/proc/meminfo 文件中，有一行数据：
通过监控这个值，就可以验证回写等待时间了。
如果你想实时查看这个值，可以这样写：
-n 指定间隔时间，单位是秒，后面的数值可以是小数，写1表示每一秒钟刷新一次后面的命令执行的结果。
另外：还有一个内核参数需要关注，vm.dirty_writeback_centisecs 表示检测的间隔时间，默认是500，单位也是百分之一秒，就是每隔5 秒检测一次。
如果是随机小IO 场景，应该是将回写保留时间更长一点？还是更短一点？
建议更长一点，因为这样IO 会整合得更充分，如果是大IO，建议缩短。
这就是内存的脏页回收机制，提升了写性能。
但是这样存在一个问题：万一真的停电了，数据不就丢失了吗？是的，如果发生断电，就真的完蛋了...
机房的服务器，通常都有后备电池，可以让你来得及正常下电关机。
那万一存储停电了呢
存储设备也有缓存吗？有的，而且存储设备的缓存就更大了，可能很多设备都在往里面写入数据，几十GB 的数据都在里面。一般存储设备里面都有一个硬件叫BBU（后备电池单元），平时处于充电状态，一旦设备断电了，BBU可以给缓存供电，但BBU很小，它没办法给所有的硬盘供电，只能给缓存供电，可是如果BBU的电耗尽了，电力还没有恢复怎么办呢？存储设备还有保险箱盘，BBU可以给缓存和保险箱盘供电，保险箱盘就是存储里面装操作系统用的那块盘，当存储设备断电时，BBU会给缓存和保险箱盘供电，先把缓存区的数据有序地写入到保险箱盘暂停，即便BBU的电耗尽了，缓存区的数据也已经落盘到保险箱盘了，电力恢复以后，从保险箱盘的一个独立的区域里面把缓存的数据重新读到缓存区，再写回到应该落盘的位置。
所以如果某一天，你发现公司的存储设备怎么性能突然变得这么差，排查半天发现BBU故障了， BBU故障怎么会导致性能下降呢？还真会！
存储设备的LUN 写策略有：
- 回写（默认）
- 透写
- 强制回写
当BBU 故障时，为了保证数据的安全，牺牲性能，所以写策略自动变成透写。
如果BBU一时修不好，你又不怕死，可以人工调整为强制回写，保证性能。
如果是分布式存储，如何实现缓存？是放在内存中吗？不会的。为什么？因为数据量太大了，写内存会让系统崩溃。在分布式存储中，有专用的缓存盘，一般缓存盘通常采用NVME。
下图是华为的Fusion Storage分布式存储解决方案，了解一下即可：
拓展
1、如果，内存中有脏数据还未落盘我又不想等待自动回写，可以执行sync命令手动回写脏数据。
2、下面这个内核参数，值为30，这是一个百分比，即30%，表示：如果脏数据占用缓存区30%的空间，就开始回写数据，即使没有达到超时时间。
3、shutdown、reboot、init 0、poweroff 等等关机/重启命令默认会包含有sync 这个动作，对于一台高速运行、处理高并发业务的主机，如数据库，千万不要执行强制关机，否则，大量的脏数据未落盘，这些数据都会丢失，造成不可估量的损失！！！
799
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
