在Linux内核，对于进程的内存使用与Cgroup的内存使用统计有一些相同和不同的地方。
这个问题不止一个同学遇到过了，之前小王同学也遇到这个问题，内存的计算总是一个迷糊账。我们今天来把它算个清楚下!
本来，写了个智能抠图的接口，本地运行正常，结果部署到服务器，发现，各种失败或服务器错误，查看log日志发现是本kill了
内存是计算机中与CPU进行沟通的桥梁，用于暂时存放CPU中的运算数据。Linux 内核的内存管理机制设计得非常精妙，对于 Linux 内核的性能有很大影响。在早期的 Unix 系统中，fork 启动新进程时，由于从父进程往子进程复制内存信息需要消耗一定的时间，因此启动多个进程时存在性能瓶颈。现在的 Linux 内核则通过“写时复制（copy-on-write）”等机制提高了创建进程的效率；也正是因为这个原因，关于 Linux 内存分配、计算、空闲判断有一些特别的地方需要注意。
这几天遇到一个比较奇怪的问题，觉得有必要和大家分享一下。我们的一个服务，运行在docker上，在某个版本之后，占用的内存开始增长，直到docker分配的内存上限，但是并不会OOM。版本的更改如下：
在创建到32745个线程时，pthread框架报告没有资源创建新线程了，这个是框架自己对于内存使用的显示。
最近看了一篇文章：Tracking Down “Invisible” OOM Kills in Kubernetes，其讲述的是由于内存不足导致Pod中的进程被killed，但Pod并没有重启，也没有任何日志或kubernetes事件，只有一个"Exit Code: 137"的信息，导致难以进一步定位问题。最后还是通过查看节点系统日志才发现如下信息：
本文主要分析 Linux 系统内存统计的一些指标以及进程角度内存使用监控的一些方法。
通过前两篇文章（系统调用mmap的内核实现分析，Linux下Page Fault的处理流程）我们可以知道，虚拟内存是在我们向操作系统申请内存（比如malloc或mmap）时分配的，而物理内存是在我们使用（比如读或写）虚拟内存时通过page fault分配的。
在Almalinux替换CentOS的过程中，我们通过kubectl top nodes命令观察到了两个相同规格的节点（只有cgroup版本不同）。在分别调度两个相同的Pod后，我们预期它们的内存使用量应该相近。然而，我们发现使用了cgroupv2的节点的内存使用量比使用了cgroupv1的节点多了约280Mi。
业务进程异常停止或重启，可以根据 /var/log/messages 日志判断是否发生OOM，如果是，又是什么进程占用了大量内存空间触发 OOM Killer
今天对一个pod进行内存资源调整后, 一直卡在ContainerCreating的状态, 执行describe命令查看该 Pod 详细信息后发现如下 。
我们知道LINUX的内存管理系统中有”反向映射“这一说，目的是为了快速去查找出一个特定的物理页在哪些进程中被映射到了什么地址，这样如果我们想把这一页换出（SWAP），或是迁移（Migrate）的时候，就能相应该更改所有相关进程的页表来达到这个目的。
无论您是 DevOps 工程师、系统管理员还是刚入门 Kubernetes 的人，了解内存指标可能会改变游戏规则。
内核使用cgroup对进程进行分组，并限制进程资源和对进程进行跟踪。内核通过名为cgroupfs类型的虚拟文件系统来提供cgroup功能接口。cgroup有如下2个概念:
/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有什么联系和区别？很多细节在手册中并没有讲清楚，本文对此做了一点探究。
一个进程的虚拟地址空间主要由两个数据结来描述，一个是 mm_struct，一个是 vm_area_structs。
收到同事反馈，说后台服务出现异常，定位后发现是应用连接elasticsearch server失败，于是用eshead去连接，还是失败；
mapped 表示该进程映射的虚拟地址空间大小，也就是该进程预先分配的虚拟内存大小，即ps出的vsz
名称： pmap - report memory map of a process(查看进程的内存映像信息)pmap命令用于报告进程的内存映射关系，是Linux调试及运维一个很好的工具。 用法 pmap [ -x | -d ] [ -q ] pids... pmap -V 选项含义 -x extended Show the extended format. 显示扩展格式 -d device Show the device format. 显示设备格式 -q quiet Do not display some header/footer lines. 不显示头尾行 -V show version Displays version of program. 显示版本 扩展格式和设备格式域： Address: start address of map 映像起始地址 Kbytes: size of map in kilobytes 映像大小 RSS: resident set size in kilobytes 驻留集大小 Dirty: dirty pages (both shared and private) in kilobytes 脏页大小 Mode: permissions on map 映像权限: r=read, w=write, x=execute, s=shared, p=private (copy on write) Mapping: file backing the map , or '[ anon ]' for allocated memory, or '[ stack ]' for the program stack. 映像支持文件,[anon]为已分配内存 [stack]为程序堆栈 Offset: offset into the file 文件偏移 Device: device name (major:minor) 设备名 举例： 查看进程1的设备格式 [root@C44 ~]# pmap -d 1 1: init [5] Address Kbytes Mode Offset Device Mapping 00934000 88 r-x-- 0000000000000000 008:00005 ld-2.3.4.so 0094a000 4 r---- 0000000000015000 008:00005 ld-2.3.4.so 0094b000 4 rw--- 0000000000016000 008:00005 ld-2.3.4.so 0094e000 1188 r-x-- 0000000000000000 008:00005 libc-2.3.4.so 00a77000 8 r---- 0000000000129000 008:00005 libc-2.3.4.so 00a79000 8 rw--- 000000000012b000 008:00005 libc-2.3.4.so 00a7b000 8 rw--- 0000000000a7b000 000:00000 [ anon ] 00a85000 52 r-x-- 0000000000000000 008:00005 libsepol.so.1 00a92000 4 rw--- 000000000000c000 008:00005 libsepol.so.1 00a93000 32 rw--- 0000000000a93000 000:00000 [ anon ] 00d9d000 52 r-x-- 0000000000000000 008:00005 libselinux.so.1 00daa000 4 rw--- 000000000000d000 008:00005 libselinux.so.1 08048000 28 r-x-- 0000000000000000 008:00005 init 0804f000 4 rw--- 0000000000007000 008:00005 init 084e
执行该程序，输出mmap方法返回的内存地址，同时使用pmap命令输出该程序执行mmap之前以及之后的内存使用情况。
在定位一个线上问题时发现Active(file)+Inactive(file)要比cached统计值大很多，看起来不太符合预期，正常情况下Active(file)+Inactive(file)的统计值都会同时计算到cached里，也就是一般cached的值会比Active(file)+Inactive(file)要大。
前面的文章中说道NTM可以追踪到堆内内存、code区域、通过unsafe.allocateMemory和DirectByteBuffer申请的内存。
问题背景：一次启动本地应用，两分钟过后自动退出，通过日志并未发现任何异常状况，莫名其妙的应用就自动被杀掉了；
Perfetto 是一个用于性能检测和跟踪分析的生产级开源堆栈。它提供用于记录系统级和应用程序级跟踪的服务和库、本机 + java 堆分析、使用 SQL 分析跟踪的库以及用于可视化和探索多 GB 跟踪的基于 Web 的 UI。
Linux 内核有个机制叫OOM killer（Out-Of-Memory killer），该机制会监控那些占用内存过大，尤其是瞬间很快消耗大量内存的进程，为了防止内存耗尽而内核会把该进程杀掉。
对这个报表作一个排序，会获得更多信息[root@abc ~]# pmap -x 14769 | sort -nk 2 ---------------- ------ ------ ------14769: /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/lib/mysql/abc.err --open-files-limit=8192 --pid-file=/var/lib
这个文件记录着比较详细的内存配置信息，使用 cat /proc/meminfo 查看。
MM-Wiki 一个轻量级的企业知识分享与团队协同软件，可用于快速构建企业 Wiki 和团队知识分享平台。
「 原谅和忘记就意味着扔掉了我们获得的最贵经验 -------《人生的智慧》叔本华」
值此七夕佳节，烟哥放弃了无数妹纸的邀约，坐在电脑面前码字，就是为了给读者带来新的知识，这是一件伟大的事业！ 好吧，实际情况是没人约。为了化解尴尬，我决定卖力写文章，嗯，一定是我过于屌丝！ 好了，开始说重点。今天讲的这个问题
该文章介绍了如何通过 pmap 命令查看进程的虚拟地址空间使用情况，包括起始地址、大小、实际使用内存、脏页大小、权限、偏移、设备和映射文件等。通过分析这些信息，可以更好地了解程序运行时的内存使用情况，并找出潜在的内存泄漏、内存碎片等问题。
在对MySQL 8.0.26 vs GreatSQL 8.0.25的对比测试过程中，有一个环节是人为制造磁盘满的场景，看看MGR是否还能正常响应请求。
Kubernetes 对内存资源的限制实际上是通过 cgroup 来控制的，cgroup 是容器的一组用来控制内核如何运行进程的相关属性集合。针对内存、CPU 和各种设备都有对应的 cgroup。cgroup 是具有层级的，这意味着每个 cgroup 拥有一个它可以继承属性的父亲，往上一直直到系统启动时创建的 root cgroup。关于其背后的原理可以参考：深入理解Kubernetes资源限制：内存。
pmap（process memory map）命令用于查看进程的内存映射，即进程的内存地址空间。
我们的痛苦来源于“夸父追日”一般的对“更好”的追求，也来自于自己的自卑与狂妄。--------duoduokk
分析问题初步推断有两种情况：参数配置不当内存泄漏关于参数配置不当，我分析完各种buffer，cache参数配置后没有发现异常或特别严重的错误，于是尝试从内存泄漏的角度来寻找突破口----分析工具pmap : 用来生成一个进程的内存使用报表The pmap command reports the memory map of a process or processes.pt-config-diff : 用来比较Mysql 配置文件的差异pt-config-diff diffs MySQL configurat
• Inactive = Inactive(anon) + Inactive(file)
做java开发以来，有一个问题一直萦绕在脑海，那就是java程序为什么会占用那么多的虚拟内存。之前也没有深究，因为服务器内存够大。但是最近用上了docker容器，每个容器基本上就几个GB的内存，内存占用过大的问题必须得解决了。
这件事是真实的发送在我们的生产环境上，其中的一台服务器上跑着 4 个 jar 程序，隔三差五的会发送进程突然消失的问题。
linux下查询进程占用的内存方法总结，假设现在有一个「php-cgi」的进程 ，进程id为「25282」。现在想要查询该进程占用的内存大小。linux命令行下有很多的工具进行查看，现总结常见的几种方式。
The OOM Killer 是内核中的一个进程，当系统出现严重内存不足时，它就会启用自己的算法去选择某一个进程并杀掉. 之所以会发生这种情况，是因为Linux内核在给某个进程分配内存时，会比进程申请的内存多分配一些. 这是为了保证进程在真正使用的时候有足够的内存，因为进程在申请内存后并不一定立即使用，当真正使用的时候，可能部分内存已经被回收了。
首先要说明是goldengate管理的内存不是物理内存，管理只是virtual memroy和swap disk，这个被称为cachesize management(COM).当goldengate进程启动后，COM向操作申请虚拟内存空间(不是真正物理内存,操作系统使用真正使用时候才会分配的机制来提高内存使用效率),只有COM真正需要实际内存空间，操作系统才会分配内存(分配内存空间也不是COM申请全部虚拟地址空间)
[[Address: 内存开始地址]\ [Kbytes: 占用内存的字节数（KB）]\ [RSS: 保留内存的字节数（KB）]\ [Dirty: 脏页的字节数（包括共享和私有的）（KB）]\ [Mode: 内存的权限：read、write、execute、shared、private (写时复制)]\ [Mapping: 占用内存的文件、或[anon]（分配的内存）、或[stack]（堆栈）]\ [Offset: 文件偏移]\ [Device: 设备名 (major:minor)]
这些问题，很可能是由于Page Cache管理不到位引起的，因为Page Cache管理不当除了会增加系统I/O吞吐外，还会引起业务性能抖动。
本文分析过程中参考借鉴了博客:https://cloud.tencent.com/developer/article/1782057的一些知识点，针对自己碰到的实际问题分析过程中补充了一些问题点的理解分析。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
