马哥linux运维 | 最专业的linux培训机构 ---- 最近在维护一台CentOS服务器的时候，发现内存无端"损失"了许多，free和ps统计的结果相差十几个G，搞的我一度又以为遇到灵异事件了，后来Google了许久才搞明白，特此记录一下，以供日后查询。 虽然天天都在用Linux系统办公，其实对它的了解也不过尔尔。毕业几年才迈入"知道自己不知道"的境界，我觉得自己丝毫没有愧对万年吊车尾这个称号 :( 问题描述和初步调查 同事说有一台服务器的内存用光了，我连上去用free看了下，确实有点怪。 $ fr
最近一台 CentOS 服务器，发现内存无端损失了许多，free 和 ps 统计的结果相差十几个G，非常奇怪，后来Google了许久才搞明白。
释放 reclaimable slab ，包括dentries and inodes cache
在疫情期间，小编不得不待在家中远程办公。但变的是办公方式，不变的是美创运维的7*24小时不间断支持。
前言： 前文《内存映射技术分析》描述了虚拟内存的管理、内存映射；《物理内存管理》介绍了物理内存管理。 本篇介绍一下内存回收。内存回收应该是整个Linux的内存管理上最难理解的部分了。 分析： 1，PFRA Page Frame Reclaim Algorithm，Linux的内存回收算法。 不过，PFRA和常规的算法不同。比如说冒泡排序或者快速排序具有固定的时间复杂度和空间复杂度，代码怎么写都差不多。而PFRA则不然，它不是一个具体的算法，而是一个策略---什么样的情况下需要做内存回收，什么样的page
前言： 书接上回《内存映射技术分析》，继续来分析一下linux的物理内存管理。 分析： 1，物理内存 PC上的内存条，或者手机上的内存芯片，物理上实实在在的内存，就是物理内存。大小是硬件决定的，一般就是一个起始地址，加上大小。地址如何分配呢？PC上作者也不太懂，听闻BIOS可以配置。在ARM上，作者曾经看过一份电路图，当时的图上，使用32bit的高2bit作为chip select，后面的30bit作为地址总线，看过chip select信号之后，作者才明白为什么在代码上要配置起始的地址不是0，因为硬件
最近在维护一台CentOS服务器的时候，发现内存无端"损失"了许多，free和ps统计的结果相差十几个G，搞的我一度又以为遇到灵异事件了，后来Google了许久才搞明白，特此记录一下，以供日后查询。
在Linux系统上查看内存使用状况最常用的命令是"free"，其中buffers和cache通常被认为是可以回收的：
一台服务器报警了，内存占用过高，奇怪的是集群里其它的服务器都没问题。不过从以往的经验来看：每一个匪夷所思的问题背后，都隐藏着一个啼笑皆非的答案。
在之前的这四篇文章中，笔者详细的为大家介绍了 slab 内存池的整体架构演化过程，随后基于这个演化过程，介绍了整个 slab alloactor 体系的创建，内存分配，内存释放以及销毁等相关复杂流程在内核中的实现。
腾讯云cvm内存使用率监控指标到底是怎么统计的？按照官网的解释，内存使用率是用户实际使用的内存量与总内存量之比，不包括缓冲区与系统缓存占用的内存。 官网这里解释比较笼统， 是free 命令里面的(total-free)100%/total？ 还是（total-free-buffer/cache）100%/total? 答案都不是，具体看下面的解释。
a). 进程使用的物理内存： find /proc/ -maxdepth 1 -iname "[0-9]*" | xargs -I{} cat {}/smaps | grep Pss: | awk '{s+=$2}END{print s}' b). slab分配占用的内存，采用slab机制主要是解决申请时候浪费page的问题，这一部分的内存并不是application 所占用的，所以要单独列出来, 可以在meminfo 中查看到其占用空间以及可回收空间大小. c). pagetable在虚拟地址到物理地址的转换中发挥着关键的作用，所以也不属于application占用的内存，属于系统所用，所以也单独列出来. 其大小随着内存的变大而变大，可以在meminfo 中找到占用的大小. d). free的内存，这一部分内存是从system的角度看，依然是free的，也就是说这一部分内存还没有被system 进行接管. e). cache/buffer内存的大小，这一部分可以在meminfo 中找到，这里主要是 application 的所使用的cache/buffer. f). 其他原因导致的内存gap, 在下面的示例中，上述所述的6种内存的总和大于实际的总内存，这是因为 shmem 是被application使用的，所以在计算进程使用的物理内存的时候，已经包含了shmem,而cache又计算了一次，因此最后的结果应该是减去SHMEM, 这样 和总内存相比，还有5497KB的gap .那么这个gap 到底应该是available的，还是算作used的，不得而知，那么因为这个gap 不大，所以对于内存的使用状况统计，我们可以暂且忽略该gap， 所以我们可以有如下的公式作为一个参考： total = free + cache + buffer + process_used_via_pss + slab + pagetables - shmem
当我们要学习一个新知识点时，比较好的过程是先理解出现这个技术点的 背景原因，同期其他解决方案，新技术点解决了什么问题以及它存在哪些不足和改进之处，这样整个学习过程是 闭环 的，个人觉得这是个很好的学习思路。
a) 如果当前连续内存块足够 realloc 的话，只是将 p 所指向的空间扩大，并返回 p 的指针地址。这个时候 q 和 p 指向的地址是一样的
这篇文章是对 Linux 内存相关问题的集合，工作中会有很大的帮助。关注公号的朋友应该知道之前我写过从内核态到用户态 Linux 内存管理相关的基础文章，在阅读前最好浏览下，链接如下：
作者简介： 程磊，一线码农，在某手机公司担任系统开发工程师，日常喜欢研究内核基本原理。 1.1 内存管理的意义 1.2 原始内存管理 1.3 分段内存管理 1.4 分页内存管理 1.5 内存管理的目标 1.6 Linux内存管理体系 2.1 物理内存节点 2.2 物理内存区域 2.3 物理内存页面 2.4 物理内存模型 2.5 三级区划关系 3.1 Buddy System 3.1.1 伙伴系统的内存来源 3.1.2 伙伴系统的管理数据结构 3.1.3 伙伴系统的算法逻辑 3.1.4 伙伴系统的接口 3.1
蒋彪，腾讯云高级工程师，10+年专注于操作系统相关技术，Linux内核资深发烧友。目前负责腾讯云原生OS的研发，以及OS/虚拟化的性能优化工作。 导语 云原生场景，相比于传统的 IDC 场景，业务更加复杂多样，而原生 Linux kernel 在面对云原生的各种复杂场景时，时常显得有些力不从心。本文基于腾讯云原生场景中的实际案例，展现针对类似问题的一些排查思路，并希望借此透视 Linux kernel 的相关底层逻辑以及可能的优化方向。 背景 腾讯云客户某关键业务容器所在节点，偶发 CPU sys (内核
Docker长期运行导致Linux内存buff/caches占用过高，这个问题很常见，但是我们是无法控制Docker自己对pagecache的处理机制的。
导语 linux 内存是后台开发人员，需要深入了解的计算机资源。合理的使用内存，有助于提升机器的性能和稳定性。本文主要介绍 linux 内存组织结构和页面布局，内存碎片产生原因和优化算法，linux
也就是我们实际中编码时遇到的内存地址并不是对应于实际内存上的地址，我们编码中使用的地址是一个逻辑地址，会通过分段和分页这两个机制把它转为物理地址。而由于linux使用的分段机制有限，可以认为，linux下的逻辑地址=线性地址。也就是，我们编码使用的是线性地址，之后只需要经过一个分页机制就可以把这个地址转为物理地址了。所以我们更重要的可能是去说明一下linux的分页模型。
linux 内存是后台开发人员，需要深入了解的计算机资源。合理的使用内存，有助于提升机器的性能和稳定性。本文主要介绍 linux 内存组织结构和页面布局，内存碎片产生原因和优化算法，linux 内核几种内存管理的方法，内存使用场景以及内存使用的那些坑。从内存的原理和结构，到内存的算法优化，再到使用场景，去探寻内存管理的机制和奥秘。
理解硬件访问内存的原理,MMU和页表；澄清Linux内核ZONE，buddy，slab管理；澄清用户空间malloc与内核关系，Lazy分配机制；澄清进程的内存消耗的vss,rss,pss,uss概念；澄清内存耗尽的OOM行为；澄清文件背景页面与匿名页，page cache与swap；澄清内存的回收、dirty page的写回，以及一些内存管理/proc/sys/vm sysctl配置的幕后原理；DMA和cache一致性，IOMMU等;给出一些内存相关的调试和优化方法；消除网上各种免费资料的各种误解。
在Linux系统中，我们经常用free命令来查看系统内存的使用状态。在一个RHEL6的系统上，free命令的显示内容大概是这样一个状态：
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
有了前两节的学习相信读者已经知道CPU所有的操作都是建立在虚拟地址上处理(这里的虚拟地址分为内核态虚拟地址和用户态虚拟地址)，CPU看到的内存管理都是对page的管理，接下来我们看一下用来管理page
之前负责过QQ音乐Android版的播放功能，对于Android音频系统有过一些了解，因此将这些内容整理成文。本文是Android音频系统的基础篇，主要介绍了匿名内存内部实现以及对外的接口。下篇文章将介绍Ashmem对外提供的接口以及MemoryBase+MemoryHeapBase实现进程间共享内存的原理。
Memcached特点 协议简单，基于文本行的协议 基于Libevent的时间处理 内置内存存储方式 分布式缓存服务器（采用一致性哈希算法实现的客户端分布式，而非服务器端的分布式） 内存分配机制 -
memcached是高性能的分布式内存缓存服务器。一般的使用目的是，通过缓存数据库查询结果，减少数据库访问次数，以提高动态Web应用的速度、提高可扩展性。
有了前两节的学习相信读者已经知道CPU所有的操作都是建立在虚拟地址上处理(这里的虚拟地址分为内核态虚拟地址和用户态虚拟地址)，CPU看到的内存管理都是对page的管理，接下来我们看一下用来管理page的经典算法--Buddy。
为了加速操作和减少磁盘I/O，内核通常会尽可能多地缓存内存，这部分内存就是Cache Memory(缓存内存)。根据设计，包含缓存数据的页面可以按需重新用于其他用途(例如，应用程序)。
本文主要介绍Buddy System、Slab Allocator的实现机制以及现实中的一些漏洞利用方法，从攻击者角度加深对Linux内核内存管理机制的理解。
网上已经有很多关于Linux内核内存管理的分析和介绍了，但是不影响我再写一篇：一方面是作为其他文章的补充，另一方面则是自己学习的记录、总结和沉淀。
之前写了两篇详细分析 Linux 内存管理的文章，读者好评如潮。但由于是分开两篇来写，而这两篇内容其实是有很强关联的，有读者反馈没有看到另一篇读起来不够不连贯，为方便阅读这次特意把两篇整合在一起，看这一篇就够了！
使用free命令可以查看系统的内存使用情况，包括总内存、已用内存、空闲内存等信息。
本文主要分析 Linux 系统内存统计的一些指标以及进程角度内存使用监控的一些方法。
文章目录 一、查看 x86_64 架构体系内存分布 二、/proc/meminfo 重要字段解析 一、查看 x86_64 架构体系内存分布 ---- 执行 cat /proc/meminfo 命令 , 可以查看 " x86_64 架构体系内存分布 " ; 执行结果参考 : root@ubuntu:~/kernel/linux-5.6.14# cat /proc/meminfo MemTotal: 4001788 kB MemFree: 2312852 kB MemAvaila
cat /proc/meminfo 各字段详解 /proc/meminfo是了解Linux系统内存使用状况的主要接口，我们最常用的”free”、”vmstat”等命令就是通过它获取数据的 ，/proc/meminfo所包含的信息比”free”等命令要丰富得多，因此需要了解这些字段的含义。 / $ cat /proc/meminfo MemTotal: 877368 kB ：所有可用RAM大小（即物理内存减去一些预留位和内核的二进制代码大小）（HighTotal + LowTotal）,
硬件平台: 全志R/V/F/MR/H 系列芯片。软件平台: Tina v3.5 及后续版本。
前言 在高性能网络模型下，使用polling模式，依然遇到了长尾20ms+的情况，远高于平均的1ms左右。怀疑是调度的延迟导致的。那么如何量化是不是内核的调度导致的呢？以及如何发现是什么原因导致的呢？ 分析 调度延迟 在前文《[Linux][kernel]sched delay和steal time的原理分析以及atop的监控改进》中分析过Linux中如何计算一个task的run delay：即一个task希望运行，但是得不到运行的时间统计，即run delay，也就是调度延迟。 那么问题来了，如果通过atop监控到某一个进程的run delay是2%，能说明那20ms的长尾延迟是因为调度延迟导致的吗？答案是不能。我们看下面的两种情况： 1，例如说，Run 19ms, Delay 1ms,Run 19ms, Delay 1ms,Run 19ms, Delay 1ms。在这个模型下，统计出来的run delay是2%。 2，另外一种模型下，例如 Run 980ms, Delay 20ms, Run 980ms, Delay 20ms，这个模型下，就会遇到20ms+的长尾延迟。 所以atop可以统计出来宏观的run delay延迟占比，但是不能统计出来具体的调度延迟极端情况。 runqslower工具 在bcc中提供了runqslower工具，可以通过参数控制，打印出来哪些进程的调度延迟超过了特定的阈值，例如希望知道哪些进程的run delay超过10ms，可以使用这样的命令：
解释已经很清楚了，主要有以下几个关键点： 1. 1 代表系统所保留空闲内存的最低限
分页单元可以实现把线性地址转换为物理地址, 为了效率起见, 线性地址被分为固定长度为单位的组, 称为”页”, 页内部的线性地址被映射到连续的物理地址. 这样内核可以指定一个页的物理地址和其存储权限, 而不用指定页所包含的全部线性地址的存储权限.
常见的内存分配函数有malloc，mmap等，但大家有没有想过，这些函数在内核中是怎么实现的？换句话说，Linux内核的内存管理是怎么实现的？
在 Linux 系统中，我们经常用 free 命令来查看系统内存的使用状态。在个 RHEL6 的系统上，free 命令的显示内容大概是这样一个状态： 这里的默认显示单位是 kb，我的服务器是 128
Memcached创建者Dormando很早就写过两篇文章[1][2]，告诫开发人员不要用memcached存储Session。他在第一篇文章中给出的理由大致是说，如果用memcached存储Session，那么当memcached集群发生故障（比如内存溢出）或者维护（比如升级、增加或减少服务器）时，用户会无法登录，或者被踢掉线。而在第二篇文章中，他则指出，memcached的回收机制可能会导致用户无缘无故地掉线。
从 Memcached1.5 开始，实现了一个改良的 LRU 算法，也叫做分段 LRU（Segmented LRU）算法，新算法主要是为了更好的利用内存，并提升性能。包含了二个重要的线程:maintainer 线程、crawler 线程。
在上篇文章 《深入理解 Linux 虚拟内存管理》 中，笔者分别从进程用户态和内核态的角度详细深入地为大家介绍了 Linux 内核如何对进程虚拟内存空间进行布局以及管理的相关实现。在我们深入理解了虚拟内存之后，那么何不顺带着也探秘一下物理内存的管理呢？
前面已经分析了内存管理框架的构建实现过程，有部分内容未完全呈现出来，这里主要做个补充。
/proc/meminfo是了解Linux系统内存使用状况的主要接口，我们最常用的”free”、”vmstat”等命令就是通过它获取数据的 ，/proc/meminfo所包含的信息比”free”等命令要丰富得多，然而真正理解它并不容易，比如我们知道”Cached”统计的是文件缓存页，manpage上说是“In-memory cache for files read from the disk (the page cache)”，那为什么它不等于[Active(file)+Inactive(file)]？AnonHugePages与AnonPages、HugePages_Total有什么联系和区别？很多细节在手册中并没有讲清楚，本文对此做了一点探究。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
即时通信 IM
