解决linux buffer/cache 消耗内存过高引发的问题

最新推荐文章于 2025-09-18 10:40:17 发布
原创 最新推荐文章于 2025-09-18 10:40:17 发布 · 5.1w 阅读 · 12 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#buffer cache linux s

本文探讨了如何处理Linux系统中buffer/cache占用内存过高的问题，提供了相应的解决方案，旨在保持系统的稳定运行。
部署运行你感兴趣的模型镜像
工作中接到DBA报障某台服务器 跑一些大的数据，服务器就无法远程连接，报错，抓过日志叫DELL工程师检测也没问题，系统也重装过，

现在些一些较大的数据就会报如 图错误，由于服务器远在异地城市IDC机房，ssh也无法登录，于是使用iDRAC 远程管理卡连接到该台机器，通过控制台连接到服务器，看到如下图报错：

IDRC报错

1、内存占用量：dd过程内核会用大量内存作为磁盘数据的缓存，由于写入8.5T；
2、从设备来看，内存主要消耗在buff中：
3、dd if=/dev/zero of=/data$i/test bs=1M count=9000000 conv=fdatasync  &
参数fdatasync作用 ：1）保证数据刷新到磁盘、2）没有把文件元数据刷到磁盘中；
由于特性2），造成buff占用量激增；

具体可参考：http://www.2cto.com/os/201205/131568.html

4、通过echo 3 > /proc/sys/vm/drop_caches，即可清空buff/cache，目前此设备内存已恢复正常；


sar -r -f /var/log/sa/sa17

内 存使用量激增。通常情况下，是由于业务程序导致的。


Image.jpg (295.72 KB, 下载次数: 0)

IDRC报错


QQ图片20151011213837.png (7.69 KB, 下载次数: 0)

QQ图片20151011213837.png

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型，相比 3.0 版本，它提升了图像质量、运行速度和硬件效率

Linux DMA、Page Cache、Buffer Cache 和零拷贝
私房菜
12-24 2879
磁盘可以说是计算机系统最慢的硬件之一，读写速度相差内存 10 倍以上，所以针对优化磁盘的技术非常的多，比如零拷贝、直接 I/O、异步 I/O 等等，这些优化的目的就是为了提高系统的吞吐量，另外操作系统内核中的磁盘高速缓存区，可以有效地减少磁盘的访问次数。这次，我们就以「文件传输」作为切入点，来分析 I/O 工作方式，以及如何优化传输文件的性能。
Linux中buff/cache占用内存过多
qq_41992429的博客
12-27 1344
Linux中buff/cache占用内存过多
Linux下buff/cache占用过大问题
ybb_ymm的专栏
01-09 1万+
当我们在命令行中执行free -h 查看内存时，发现buff/cache占用过大，导致其他软件没有内存可使用。其实，我们可以将他设置成定时任务，每隔一段时间执行一下，这样我们的buff/cache就不会那么高了！这样我们就解决了buff/cache过高的问题，但是缺点在于我们需要手动去执行！再打开的文件中添加我们的定时任务执行的时间 以及执行的文件路径。为了确保我们添加成功，可执行下面的命令查看我们是否追加成功。给我们的定义的脚本赋予可执行的权限。测试一把，执行一下我们的脚本。添加完成后，保存，退出。
【服务器知识】linux服务器内存或者CPU利用率占用高占满，如何排查原因核解决？
向宇
09-18 1529
摘要：Linux服务器内存与CPU高利用率排查指南 本文针对Linux服务器内存利用率达90%的情况进行分析，指出Linux内存管理机制会利用空闲内存作缓存来提升性能，高内存利用率不一定代表问题。建议通过free -h命令重点关注available列而非free列，若可用内存不足可使用top或ps命令排查具体进程。对于CPU高利用率问题，推荐使用top命令按CPU排序定位问题进程，并通过ps命令查看进程详情。文中还提供了常见内存/CPU消耗大户的示例和详细排查步骤。
Linux服务器Cache占用过多内存导致系统内存不足最终java应用程序崩溃解决方案
liuyanmin专栏
03-27 5万+
问题描述Linux内存使用量超过阈值，使得Java应用程序无可用内存，最终导致程序崩溃。即使在程序没有挂掉时把程序停掉，系统内存也不会被释放。找原因的过程这个问题已经困扰我好几个月了，分析过好多次都没有找到原因，网上查了一下该问题其他人也都遇到过，不过并没有什么好的解决方案，因为项目一直没有上线，每次当内存不足时导致程序崩溃都是重启服务就好了，索性也就没花太多的时间来找问题。现在项目马上上线了，不...
linux buffer/cache 占用过大问题
Leckun的专栏
02-06 1453
linux bufer/cache占用过大问题
linux buffer/cache过大
IT从业者
10-10 3795
linux buffer/cache过大监控及处理,清理缓存
buffer/cach内存占用过高及k8s java后端pod容器超出内存限制被kill重启
Kainx
11-15 1万+
现象 之前某个后端服务pod在不停的重启导致线上环境很不稳定,于是开始分析问题的原因
Linux内存优化
埃里克的博客
10-10 1306
其中的数据会根据读取频率进行组织，把最频繁读取的内容放在最容易找到的位置，把不再读的内容不断往后排，直至从中删除。根据磁盘的读写设计的，把分散的写操作集中进行，减少磁盘碎片和硬盘的反复寻道，从而提高系统性能。3.vfs_cache_pressure的缺省值是100，加大这个参数设置了虚拟内存回收directory和i-node缓冲的倾向，这个值越大，回收的倾向越严重。因为服务进行了频繁的文件读写操作，但是为什么操作系统不会主动回收呢，原来是因为drop_caches的默认参数设置的就是不释放的。
Linux 内存
帅的没拼音
03-08 902
Linux 内存
由free命令引发的buff/cache思考
Sunny_Future的博客
01-14 3264
1、free命令 free 命令显示系统内存的使用情况，包括物理内存、交换内存(swap)和内核缓冲区内存。 1.1 语法格式 Usage: free [options] Options: -b, --bytes show output in bytes -k, --kilo show output in kilobytes -m, --mega show output in megabytes -g, --giga sh
解析Linux Buffers和Cache过大的问题及解决方法
XMYX-0
04-18 2995
Buffers和Cache是Linux系统中用于存储文件系统数据的临时存储区域。用于存储文件系统的元数据（metadata）和文件数据的临时存储区域。当数据从磁盘读取到内存中时，会首先存储在Buffers中，并在需要时被写回磁盘。用于存储最近被访问过的文件系统数据的临时存储区域。Cache可以加快对频繁访问的文件的访问速度，提高系统性能。
linux缓冲区（buff/cache）内存占用过高解决办法
野草哥哥的博客
12-06 1万+
3.发现是journal这个东西，这是linux系统日志，出现这种情况，一般是日志没有配置好。2.发现free剩余很少，buff/cache占用很高。将Storage=persistent。3.安装hcache查看谁在占用。再次free -m 查看。1.查看当前内存剩余。
Linux中buff/cache内存占用过高解决办法
TopsLuo的专栏
04-13 1万+
转自：http://www.idcyunwei.org/post/162.html 如何回收cache？ Linux内核会在内存将要耗尽的时候，触发内存回收的工作，以便释放出内存给急需内存的进程使用。一般情况下，这个操作中主要的内存释放都来自于对buffer／cache的释放。尤其是被使用更多的cache空间。既然它主要用来做缓存，只是在内存够用的时候加快进程对文件的读写速度，那么在内存压力较...
Linux buffer/cache 内存占用过高的原因以及解决办法
热门推荐
kunyus的博客
03-02 7万+
表现现象 在Linux系统中，我们经常用free命令来查看系统内存的使用状态。在一个 CoreOS 的系统上，free命令的显示内容大概是这样一个状态： core@localhost ~ $ free total used free shared buff/cache available Mem: 8145320...
Linux内存[buff/cache]占用过高分析和优化
七路灯
05-19 6208
问题现场 查看系统内存的使用状态 = 监控报警可用内存空间不足，常规的解决方案如下： 增加内存（增加成本） 增加虚拟内存（影响性能） 定期清理缓存（echo 1 > /proc/sys/vm/drop_caches） 本文将介绍定期清除页面缓存，但是过会儿内存又被占满问题的分析。 问题分析 通过监控系统负载情况（vmstat 1），确定是页面缓存（cache项）占用量大，并且释放页面缓存后从块设备读入数据量（bi项）会马上增加。 通过监控io情况（iostat -x -k 1）也可以看出
Linux cached过高问题
hellojoy的博客
06-21 3万+
Linux手动释放缓存的方法Linux释放内存的命令：syncecho 1 > /proc/sys/vm/drop_cachesdrop_caches的值可以是0-3之间的数字，代表不同的含义：0：不释放（系统默认值）1：释放页缓存2：释放dentries和inodes3：释放所有缓存释放完内存后改回去让系统重新自动分配内存。echo 0 >/proc/sys/vm/drop_cach...
linux拷贝数据时buffer很高,Linux buffer/cache 内存占用过高的原因以及解决办法
weixin_42117032的博客
05-15 4142
表现现象在Linux系统中，我们经常用free命令来查看系统内存的使用状态。在一个 CoreOS 的系统上，free命令的显示内容大概是这样一个状态：core@localhost ~ $ freetotal used free shared buff/cache availableMem: 8145320 391200 3...
redis中数据量会影响 buff/cache内存大小吗
最新发布
12-03
<think> 嗯，用户想了解Redis数据量对buff/cache内存大小的影响。这个问题涉及到操作系统内存管理和Redis内部机制的交集，需要拆解几个层面来思考。 用户可能是个运维工程师或者后端开发，正在遇到服务器内存占用过高的问题。从ta引用的资料来看，已经对Linux的buff/cache有基本了解，但不太清楚Redis如何与之互动。ta的深层需求应该是想优化服务器内存使用，避免因Redis导致系统性能下降。 先明确几个关键点：Redis的内存占用主要分两部分，一是Redis进程自身通过malloc分配的内存（即used_memory），二是操作系统层面为磁盘I/O创建的page cache。用户问的buff/cache属于后者。 当Redis使用RDB或AOF持久化时，写操作会触发内核为持久化文件创建page cache。数据量越大，持久化文件越大，对应的page cache自然越大。不过这里有动态平衡机制——当系统需要更多内存时，内核会自动回收clean page cache。 用户引用的Docker清理方法其实是个误导。手动drop_caches在生产环境很危险，而且Redis数据量引起的cache增长根本不需要干预。应该提醒用户重点监控的是内存回收压力（如pgsteal_kswapd指标）和OOM风险。 还需要区分场景：如果Redis纯内存操作不持久化，那数据量就和page cache无关；但若启用了AOF的appendfsync always，每次写入都落盘，page cache压力就会显著增大。用户没说明持久化配置，这点必须在回答里补充说明。 对了，Redis的写时复制（COW）机制也会短暂增加内存开销。执行BGSAVE时，子进程会共享父进程内存页，此时若有数据修改，内核需要复制原始页，可能短暂增加page cache压力。不过这个影响是临时的。 最后给用户的建议要实用：优先用Redis的info memory看实际内存占用，系统层面关注sar -B的pgscand/s扫描率。真正危险的信号是swap使用或OOM，而不是buff/cache数字本身。可以给个示例命令，比如用smem -t -P redis看进程实际物理内存。 </think>Redis数据量**会间接影响**操作系统的buff/cache内存大小，但这种影响是通过Redis的**持久化操作**和**内核文件缓存机制**实现的，并非Redis进程本身直接占用buff/cache。以下是详细分析： --- ### 1. **Redis自身内存占用（核心影响）** * **主要占用：** Redis存储的数据（键值对）、自身数据结构开销、客户端缓冲区等，直接占用**`used_memory`**（通过`malloc`分配的**应用层内存**），这部分显示在系统的`RES`（常驻内存）中，**不属于**`buff/cache`。 * **数据量影响：** Redis数据量 **$D_{redis}$** 越大，`used_memory` 和 `RES` 必然越大。这消耗的是系统的**可用物理内存（`MemAvailable`）**。 * **查看命令：** `redis-cli info memory | grep "used_memory:"` --- ### 2. **Redis持久化操作与buff/cache的关联（间接影响）** Redis数据量对buff/cache的影响主要通过**持久化（RDB/AOF）** 触发： * **a. RDB (快照) 创建：** * **过程：** 执行`BGSAVE`时，Redis fork一个子进程。子进程将内存数据**序列化**后写入**临时RDB文件**。 * **buff/cache影响：** * 新写入的**临时RDB文件内容**会被Linux内核自动缓存到 **`buff/cache` (主要是`page cache`)** 中[^2][^4]。 * Redis数据量 **$D_{redis}$** 越大，生成的RDB文件越大 **$S_{rdb} \propto D_{redis}$**，写入到磁盘（实际是先到page cache）的数据量就越大，因此内核为缓存该文件占用的`buff/cache`也会越大。 * RDB完成且临时文件重命名后，旧的RDB文件如果不再被访问，其对应的page cache会逐渐被内核回收。 * **b. AOF (追加写日志)：** * **过程：** Redis将写命令追加到AOF缓冲区，根据配置(`appendfsync`)策略刷盘。`always`策略每次写都刷盘；`everysec`每秒刷一次；`no`由内核决定。 * **buff/cache影响：** * **AOF文件本身**会被内核缓存在 **`buff/cache` (`page cache`)** 中[^2][^4]。AOF文件会随着写操作持续增长 **$S_{aof} \propto \text{写操作量}$**。 * 数据量 **$D_{redis}$** 越大，通常意味着历史累积的写操作越多（如果启用了AOF），AOF文件可能越大，其占用的`page cache`也越大。 * **写操作频率：** 即使数据总量不大，**高频写入**也会导致AOF文件快速增大或频繁刷盘，增加内核缓存AOF文件的`page cache`量。 * **AOF重写：** 类似RDB，`BGREWRITEAOF`会生成一个新的AOF文件，该文件的写入过程同样会被缓存到`page cache`。 * **c. 内核机制：** * **Page Cache优化：** Linux内核通过`page cache`缓存最近访问过的文件数据（包括RDB/AOF文件），以**加速后续读取**。这是内核行为，对应用程序透明[^2][^4]。 * **动态管理：** `buff/cache`内存是**可回收的**。当应用程序（如Redis自身需要更多`used_memory`，或其他进程）申请内存时，如果`MemFree`不足，内核会**自动回收**`buff/cache`中**干净(`clean`)的页面**（未被修改的缓存页）来满足需求[^1][^4]。因此，即使Redis持久化导致`buff/cache`暂时升高，只要系统内存压力不大，这**不是问题**，反而**提升了文件访问性能**。 --- ### 3. **总结：数据量影响路径** ```mermaid graph LR A[Redis数据量增大 $D_{redis} \\uparrow$] --> B1[Redis used_memory/RES 增大] A --> B2[RDB文件大小 $S_{rdb} \\uparrow$] A --> B3[AOF文件大小 $S_{aof} \\uparrow$] B2 --> C[RDB生成/读取时内核缓存文件 Page Cache $\\uparrow$] B3 --> D[AOF写入/读取时内核缓存文件 Page Cache $\\uparrow$] C --> E[系统 buff/cache 可能增大] D --> E[系统 buff/cache 可能增大] ``` * **直接影响：** Redis数据量增大直接导致**Redis进程自身内存占用(`RES`)增加**。 * **间接影响：** Redis数据量增大导致**持久化文件(RDB/AOF)变大**。当这些文件被**读写**时，Linux内核会将其内容缓存到**`buff/cache` (主要是`page cache`)** 中，从而可能导致系统显示的`buff/cache`值升高。这种升高是**内核优化I/O的性能行为**，且其占用的内存在系统需要时**会被自动回收**。 --- ### 4. **监控与建议** 1. **关键指标：** * `redis-cli info memory`：关注 **`used_memory`**, `used_memory_rss`(`RES`), `aof_buffer_length`, `aof_rewrite_buffer_length`。 * `free -h` / `top`：关注 **`Mem: available`**, `buff/cache` 总量。 * `sar -B 1`：关注 **`pgscand/s`(内存回收压力)**, `fault/s`(缺页异常)。 2. **何时需关注`buff/cache`?** * **`MemAvailable` 持续很低**且 **`pgscand/s` 很高**：说明系统内存严重不足，频繁回收内存（包括回收`buff/cache`），可能导致性能下降（I/O等待增加）。这时需要： * 增加物理内存。 * 优化Redis配置，减少`used_memory`（如设置合理`maxmemory`和淘汰策略）。 * 评估是否可减少持久化频率或调整策略（如AOF用`everysec`代替`always`）。 * **`buff/cache`高但`MemAvailable`充足且无内存压力指标异常：这是正常且有益的优化，无需干预。** 强行清理`buff/cache`(`echo 3 > /proc/sys/vm/drop_caches`)会损害性能[^4]。 3. **配置考量：** * 确保设置了Redis的`maxmemory`并配置合适的`maxmemory-policy`(如`allkeys-lru`)，避免Redis无限增长耗尽内存。 * 根据数据重要性和性能需求选择合适的持久化策略(`RDB`, `AOF`, `RDB+AOF`)和`appendfsync`策略。 --- **结论：** Redis数据量本身**不直接占用`buff/cache`**。数据量增大会导致Redis自身内存占用(`RES`)增大，并**可能**通过增大持久化文件(RDB/AOF)以及在读写这些文件时被内核缓存，从而**间接地、动态地**影响系统`buff/cache`的大小。这种由内核文件缓存引起的`buff/cache`升高通常是**性能优化的体现**，在系统内存充足且无回收压力时无需担忧。监控的核心应是`MemAvailable`和内存回收压力指标，而非单纯的`buff/cache`数值[^1][^2][^4]。 ---
评论 6
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值