操作系统内存非常重要且比较复杂,其中有许多知识点仍然需要掌握才能更进一步分析程序问题。由于是初次全面系统地接触OS内存,目的是为了全面且低层次地理解linux内存相关概念,不会深入其中原理,所以本章也会尽量避免linux的源码知识。
(https://en.wikipedia.org/wiki/Memory_address)
物理内存(Physical memory):物理内存是计算机系统中实际存在的硬件内存,通常是RAM(随机存取存储器)的形式。
虚拟内存(Virtual memory):虚拟内存是一个线性区,并没有分配实际物理内存,程序认为它们有比实际物理内存更大的地址空间。虚拟内存的实现允许程序访问比物理内存更大的地址范围,而不需要所有数据都同时存在于物理内存中。内核释放物理页面是通过释放线性区,找到其所对应的物理页面,将其全部释放的过程。
内存管理单元(Memory Management Unit,MMU):是一个硬件组件,负责将程序中使用的虚拟地址转换为实际在物理内存中存储数据的物理地址。MMU的主要任务是执行地址映射。
页表(Page Table):页表是一种数据结构,用于存储虚拟地址空间与物理地址空间之间的映射关系。程序试图访问虚拟内存时,MMU通过查询页表确定相应的物理地址。
系统调用流程:
https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf
(图有点糊,最上面的字是 “User Space|Kernel Space”)
用户程序通过C库或通过系统调用才能访问内核系统,用户程序不能直接访问内核系统
内核系统通过MMU访问物理内存;通过驱动访问磁盘其他外部设备
虚拟内存系统(上图中的VM Subsystem)中包含buddy、slab算法等
进程虚拟地址空间分成了用户空间和内核空间。
用户空间:
内核空间:
上下文切换:
用户空间和内核空间的划分是为了提供安全隔离,防止用户程序直接影响操作系统的关键部分。早期的操作系统和Dos系统不区分内核、用户空间,一个程序的错误或恶意行为可能对整个系统造成影响。
(https://www.zhihu.com/tardis/zm/art/66794639?source_id=1003)
32位系统:总共4GB地址空间,3G UserSpace|1G KernelSpace
64位系统:总共256TB地址空间,128T UserSpace|128T KernelSpace
232=4GB,264=16777216TB,为什么是64位的系统是256TB地址空间呢?
64-bit computing wiki上有解释。简而言之,256TB (256 × 1024^4 bytes) 的内存地址足够了,目前以及能想象的未来还不会出现16EB (16 × 1024^6 bytes)的内存。
每个进程通常都有自己的独立虚拟内存空间。虚拟内存是一种抽象概念,为每个运行的进程提供了似乎是连续且私有的地址空间,使得每个进程都感觉自己拥有整个计算机系统的全部内存。
进程虚拟地址空间分布:
(https://www.sohu.com/a/392831824_467784)
进程虚拟地址空间分布和映射:
(https://velog.io/@mysprtlty/%EA%B0%80%EC%83%81-%EB%A9%94%EB%AA%A8%EB%A6%AC%EC%99%80-%EA%B0%80%EC%83%81-%EC%A3%BC%EC%86%8C-%EA%B3%B5%EA%B0%84)
前面讲到,虚拟地址空间中的用户空间不能被其他用户进程访问,如果通过内核区域实现多进程的用户访问同一内存数据,那么无法避免上下文切换。多进程的应用程序明显需要进程间的相互访问,所以一种直接可以实现用户进程访问同一物理内存的方法便应运而生,这就是共享内存。
共享内存是实现进程相互访问IPC(inter process communication)的机制之一,其他的方式还有message queues和semaphores。
(https://www.geeksforgeeks.org/inter-process-communication-ipc/)
由于本身就是多个虚拟内存地址空间对应一个物理内存地址空间,所以只要把两个进程的地址空间中的一段指向同一物理内存即可。
(https://www.softprayog.in/programming/interprocess-communication-using-system-v-shared-memory-in-linux)
共享内存(seems like)有许多实现方式,例如postgresql默认是mmap来实现共享内存,参考shared_memory_type参数和Managing Kernel Resources。其他的共享内存实现可参考这篇文章:宋宝华:世上最好的共享内存(Linux共享内存最透彻的一篇)
进程虚拟地址空间是对于每个进程而言的,而物理内存空间只有一个。那么如果映射、转换虚拟内存和共享内存呢?
(https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf)
页表就是存储虚拟内存地址和物理内存地址的对应关系的地方。(这里有内存管理单元MMU和转换缓冲区TLB等的概念,我们简化一下,简单理解为虚拟内存到物理内存转换功能(PAGING),这里只看页表)。一个页表是一组页表项page table entries (PTEs) 组成,PTE存储了虚拟页和物理页间的map。
单个页表虽然可以实现内存到虚拟内存的转换功能,但是直接这样实现话,页表本身又占用了太多的内存。
(https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf)
所以,需要对单个页表进行再分页:二级页表和四级页表
二级页表:
二级页表就是对单页表的再分页。4G 的空间需要 4M 的页表来存储映射表,如果将这 4M 分成 1K 个 页(4K), 这 1K 个页也需要一个表进行管理,我们成为页目录表,这个页目录表里面有 1K 项,每项 4 个字节,页目录表大小也就是 4K 。
四级页表:
对于 64 位系统,两级页表也不够,需要用四级页表
(https://maodanp.github.io/2019/06/02/linux-virtual-space/)
查看pagetable的大小:
[pg@lzl 2345]$ cat /proc/meminfo |grep PageTables
PageTables: 46736 kB
Uniform Memory Access (UMA):所有cpu访问内存的时间是等价的。UMA存在的问题是多个处理器通过一条总线访问内存,使共享总线上负载增加。多个处理器会争用memory controller造成冲突。另外总线带宽有限,会有访问延迟。
Non-Uniform Memory Access (NUMA):一小组CPU一起访问它们自己的本地内存。存在多组CPU和它们的内存组时,每组CPU和内存组就构成一个NUMA节点(node)。
UMA:
NUMA:
(https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf)
NUMA的基本特性:
NUMA balancing:
通过自动转移任务到远端cpu或者拷贝远端数据到本地内存的方式,实现本地访问。redhat 7上默认打开。
转移任务或者拷贝数据本身也消耗资源,导致任务变慢,该特性可能不适用于部分应用,例如oracle的exdata就对NUMA做了针对优化。
numactl:
NUMA的OS配置工具 。
numactl --show检视cpu和node情况,如下为4node总共64c256g,每个node有16c64g:
available: 4 nodes (0-3)
node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39
node 0 size: 65418 MB
node 0 free: 310 MB
node 1 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47
node 1 size: 65536 MB
node 1 free: 41 MB
node 2 cpus: 16 17 18 19 20 21 22 23 48 49 50 51 52 53 54 55
node 2 size: 65536 MB
node 2 free: 82 MB
node 3 cpus: 24 25 26 27 28 29 30 31 56 57 58 59 60 61 62 63
node 3 size: 65536 MB
node 3 free: 43 MB
NUMA把cpus和内存分成多个node(node 0,node 1,node 2 ···),UMA结构中也可以把cpu内存整体看成node 0。
在Linux中每个node用数据结构struct pglist_data
表示,数据类型为typedef pg_data_t
。每个node又分为多个zone,一个zone的数据结构为zone_t
,数据类型为zone_struct
,一般有3种数据类型ZONE_DMA
, ZONE_NORMAL
, ZONE_HIGHMEM
,每个类型的zone有各种不同的功能。
(https://www.kernel.org/doc/gorman/html/understand/understand005.html)
32位zone的区域分布及功能:
ZONE_DMA
:(<16MB),Direct Memory Access (DMA),古老的16 MiB限制,包含ISA devices。ZONE_DMA32
:由于很多设备在访问无法用 32 位寻址的内存时遇到问题,在x86-64新增了这样一个区域,该区域只存在于x86-64架构中。(详见ZONE_DMA32)ZONE_NORMAL
: (16MB to 896MB),可直接映射到内核段的普通内存域;大部分内核操作都在NORMAL区进行,这是最重要的一个区域ZONE_HIGHMEM
:(>896MB),标记了超出内核段的物理内存,不能直接被内核调用。32位和64位的zone分布图:
https://users.cs.utah.edu/~aburtsev/cs5460/lectures/lecture19-memory-management/lecture19-memory-management.pdf
注意zone是对于物理内存而言的,虚拟内存的用户态转换为内核态后,才可以调用物理内存。下图便是虚拟内存空间的内核地址与物理地址空间中的zone的关系:
(https://wr.informatik.uni-hamburg.de/_media/teaching/wintersemester_2014_2015/kp-1415-memory-management.pdf)
检视zone:
cat /proc/zoneinfo
cat /proc/buddyinfo
cat /proc/pagetypeinfo
$ cat /proc/buddyinfo
Node 0, zone DMA 1 1 1 1 1 0 1 1 1 1 2
Node 0, zone DMA32 688 2080 1420 995 596 357 278 241 276 32 133
Node 0, zone Normal 195748 204074 161167 119070 70791 33578 9556 2070 1034 2533 7328
Node 1, zone Normal 11705 51467 36752 21326 11343 7309 5024 3403 2597 3056 10898
虚拟内存和物理内存被分割为固定大小的片段,一般是4KB大小。所以虚拟内存分割后就有了虚拟页,物理内存分割后就有了物理页(PP or PF,Physical Page or Page Frame),物理页也叫页帧,也是4KB。页帧代表系统内存的最小单位。
虚拟地址空间的每个页面都可以通过其描述项对应到物理地址空间的一个页帧上。
页是内存分配的最小单元(默认4K),当map分配大量的连续页时性能较差,Huge Page就是为了解决这个问题。大页不仅分配的时候更cheap,页表同时也相对会更小。hugepagesz 为2 MB或1 GB,默认是2MB。REDHAT 6开始实现了Huge Page。
由于手动管理大页比较麻烦,REDHAT 6开始同样也提供了自动管理大页的功能,即透明大页。
在oracle的数据库管理中,一般把大页打开给SGA使用,透明大页关闭。相关资料也比较多可行搜索资料。
同样的,PostgreSQL也可以开启大页。由于数据库一般会占用较多的操作系统内存,数据库开启大页一般可以降低内存分配的压力。
文件页可以map到磁盘上的文件,文件系统的读写会通过Page Cache当做缓存IO,脏数据周期或被调用时“sync”(or fsync之类的)到对应的磁盘,Page Cache就是用来“提升”磁盘性能的内存区域。
相对应的,没有文件相关联的页叫匿名页(Anonymous pages ),一般对应着heap、stack。当内存资源紧张时,内核会把不经常使用的匿名页中的数据写入到 Swap 分区或者 Swap 文件中。
简而言之:
(https://www.slideshare.net/raghusiddarth/memory-management-in-linux-11551521?from_search=2)
以上page cache的图是站在操作系统的角度来看的,应用程序(如数据库)的写入也可以不delayed,甚至不通过Page cache。
内存分配也十分复杂,涉及很多概念。两种常见的内存分配方式为buddy、slab
buddy系统用于分配连续的内存页,每个zone都有各自的buddy系统。buddy系统划分了大块内存以响应内存分配请求,同时由于合并的特性可以减少系统内存碎片化。
buddy allocator将内存分为2的幂次方的页,最大阶数为10:
当内存请求大于已有块的大小时,系统会将较大的块分割成两个相等大小的伙伴块。当内存释放时,系统会尝试将相邻的伙伴块合并成一个更大的块:
释放??的时候就直接把??放回空闲列表,如果其之前拆开的另?半??也没有被分配,则组合成双倍??交给更?的列表,然后依次循环,直到不能再循环或者已经到头。
由于高阶页因为不停的分配没有了,此时再申请高阶页时便会触发碎片问题:
等待内存回收成功后,buddy本身会合并低阶到高阶,然后分配高阶页面:
(The implementations of anti pages fragmentation in Linux kernel https://teawater.github.io/presentation/antif.pdf)
然而内存回收也可能赶不上分配速度,所以buddy系统不总是那么理想。
分析示例:
$ cat /proc/buddyinfo
Node 0, zone DMA 0 0 0 1 2 1 1 0 1 1 3
Node 0, zone DMA32 7 6 5 6 5 6 7 7 6 2 272
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0
通过buddyinfo判断内存碎片问题:
#host 1
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0
#host 2
Node 0, zone Normal 7321 7833 10885 8514 2311 1644 1663 1302 1141 7384 80675
上面是两个主机的内存情况,对比可以发现,下面这个主机的连续内存更多,上面那个主机存在内存碎片问题。
slab分配器是基于对象进行管理的。slab系统是一种专门为内核内存设计的内存分配算法。它通过将内存划分为固定大小的cache来实现,每个slab都包含同一类型的对象集。当有内存请求时,该算法首先检查适当的slab缓存中是否存在可用的对象。如果存在,则返回该对象。如果不存在,则算法会分配一个新的slab并将其添加到适当的cache中。
不同大小的对象对应不同的slab cache:
(https://bootlin.com/doc/training/linux-kernel/linux-kernel-slides.pdf)
虽然slab有不同的cache和对象,但是slab仍然使用的是物理连续的内存:
(https://i.stack.imgur.com/wo8Gg.png)
slab也有3种实现方式:
推荐文章:linux强制回收内存,linux内存源码分析 - 内存回收
(https://vivani.net/2022/06/14/linux-kernel-tuning-page-allocation-failure/)
当可用内存较低时kswapd守护进程会被唤醒以释放页
内存回收以zone为单位进行,/proc/zoneinfo
可以查看min、low、high的值。
vm.min_free_kbytes
也就是min_pages线,十分重要的操作系统参数。非常低的值会阻止系统有效地回收内存,这可能会导致系统崩溃并中断服务。太高的值会增加系统回收活动,造成分配延迟,这可能导致系统立即进入内存不足状态。
快速内存分配:是get_page_from_freelist()函数,通过low阀值从zonelist中获取合适的zone进行分配,如果zone没有达到low阀值,则会进行快速内存回收,快速内存回收后再尝试分配。
慢速内存分配:当快速分配失败后,也就是zonelist中所有zone在快速分配中都没有获取到内存,则会使用min阀值进行慢速分配,在慢速分配过程中主要做三件事,异步内存压缩、直接内存回收以及轻同步内存压缩,最后视情况进行oom分配。并且在这些操作完成后,都会调用一次快速内存分配尝试获取页框。
(https://blog.csdn.net/weixin_35094083/article/details/116688112)
不同的内存分配路径中,会触发不同的内存回收方式,对zone的内存回收方式分为两种:
内存压缩见:内存的监控-/proc/pagetypeinfo部分
对于zone的内存回收,它针对三样东西进程回收:slab、lru链表中的页、buffer_head。这里只讨论内存回收针对lru链。
lru链表主要作用就是将页排序,将最应该回收的页放到最后面,最不应该回收的页放到最前面,然后进行内存回收时,就会从后面向前面进行扫描,将扫描到的页尝试进行回收。
lru链表描述符,里面有5个lru链表,活动/非活动匿名页lru链表,活动/非活动文件页lru链表,禁止换出页链表:
(https://lpc.events/event/11/contributions/896/attachments/793/1493/slides-r2.pdf)
内存回收来说,它只会处理前面4个lru链表,也就是活动匿名页lru链表,非活动匿名页lru链表,活动文件页lru链表,非活动文件页lru链。回收到足够页框后直接返回:快速内存回收、kswapd内存回收中会这样做。
可以通过meminfo查看global lruvec(理解为lru区域):
# cat /proc/meminfo |grep -i active
Active: 597380 kB
Inactive: 601920 kB
Active(anon): 10896 kB
Inactive(anon): 117376 kB
Active(file): 586484 kB
Inactive(file): 484544 kB
实际上lruvec不止一个,cgroup、NUMA node都有自己的lruvec,同时global也有自己的lruvec
Dropcache会记录哪些页面是缓存文件系统数据的页面,并在页面被强制回收时把数据写回磁盘,以便下次访问时可以再次缓存。
默认值:vm.drop_caches = 0
。默认情况下,Linux内核不会自动清除缓存
/proc/sys/vm/drop_caches
的值设置为1:内核会清除未使用的页缓存pagecache。
/proc/sys/vm/drop_caches
的值设置为2:内核会释放dentry和inode所使用的内存,dentry和inode是文件系统元数据结构,用于存储文件和目录的信息。
/proc/sys/vm/drop_caches
的值设置为3:效果相当于1+2,释放所有未使用的缓存
当内核决定回收某些缓存时,它会检查缓存中的数据与硬盘上的数据是否一致。如果数据不一致,内核需要将数据写回磁盘,然后才能回收该缓存。这个过程可能导致IO飙高。在进行Drop Cache操作时,建议不要有任何重要的I/O操作,因为这可能会影响系统性能。
操作命令:
echo 3 > /proc/sys/vm/drop_caches #刷cache缓存
echo 0 > /proc/sys/vm/drop_caches #恢复默认值
如果不了解内存的基本知识其实很难看懂内存监控信息,在有了以上内存基础的情况下,我们来一个个过内存相关监控命令、工具的使用。
/proc 主要是进程 (process)信息和系统信息
其中system information部分,有些是linux提供的一些系统状态的接口,可以查看整个操作系统层面的监控信息,比如slabinfo,swaps,zoneinfo,buddyinfo
另一部分process是每个进程运行数据和状态信息,cd到对应进程目录下,可以看到对应进程的持有的fd和进程内存信息等
进程下面还有线程,线程的信息目录:/proc/[pid]/task/[tid]/,其下内容跟进程目录下面差不多。
更多的proc信息参考proc(5) — Linux manual page
/proc/meminfo是了解当前Linux系统内存使用状况的主要接口,最常用的free
,vmstat
,ps
等命令就是通过它获取数据。/proc/meminfo的信息要更加全面,下面只列出一些常见的信息,详细含义可参考红帽文档
#一般的内存信息
cat /proc/meminfo | grep "Mem"
MemTotal: 994328 kB #总内存大小(减去一些保留的和内核的)
MemFree: 66428 kB #完全没有用到的物理内存
MemAvailable: 207192 kB #在不使用交换空间的情况下,启动一个新的应用最大可用内存的大小
#IO缓冲区
cat /proc/meminfo | grep -e "Buffers" -we "Cached"
Buffers: 12820 kB #raw disk block使用的IO缓冲区,不会超过20MB
Cached: 254592 kB #磁盘使用的page cache size(包含tmpfs和shmem不包含SwapCached)
#swap
cat /proc/meminfo | grep "Swap"
SwapCached: 13936 kB #swap cache中包含的是被确定要swapping换页,但是尚未写入物理交换区的匿名内存页
SwapTotal: 945416 kB #swap空间总大小
SwapFree: 851064 kB #剩余的swap的大小
#lru活动与非活动页数(一眼懂)
cat /proc/meminfo | grep -e "Active" -e "Inactive"
Active: 194308 kB
Inactive: 553172 kB
Active(anon): 59024 kB
Inactive(anon): 437264 kB
Active(file): 135284 kB
Inactive(file): 115908 kB
#脏页
cat /proc/meminfo | grep -e "Dirty" -e "Writeback"
Dirty: 0 kB #还未写入的脏页
Writeback: 0 kB #正在写入的脏页
WritebackTmp: 0 kB #?temporary buffer for writebacks used by the FUSE module
#map信息
cat /proc/meminfo | grep -e "AnonPages" -e "Map"
AnonPages: 95296 kB #map的匿名页
Mapped: 153192 kB #map的文件页
DirectMap4k: 113336 kB #map的4k内核页
DirectMap2M: 1900544 kB #map的2M内核页
DirectMap1G: 0 kB #map的1G内核页
#共享内存
cat /proc/meminfo | grep "Shmem"
Shmem: 28920 kB #shmem和tmpfs的总内存大小
ShmemHugePages: 0 kB #shmem和tmpfs的总大页内存大小
ShmemPmdMapped: 0 kB #Shared memory mapped into userspace with huge pages
#内核内存(注意slab就是内核的)
cat /proc/meminfo | grep -ie "reclaim" -e "slab" -e "kernel"
KReclaimable: 35008 kB #分配给内核的Reclaimable内存
Slab: 88752 kB #slab cache
SReclaimable: 35008 kB #slab cache中Reclaimable内存
SUnreclaim: 53744 kB #slab cache中不能reclaim的内存
KernelStack: 5988 kB #所有任务使用的kernel stack内存
#分配的可用内存(与MemAvailable含义不同)
# CommitLimit=[("total RAM pages" - "total huge TLB pages") * overcommit_ratio]/100 + "total swap pages"
# 简而言之,设置了MemAvailable的水位然后加上了swap就等于allocatable内存
cat /proc/meminfo | grep -ie "commit"
CommitLimit: 1442580 kB #allocatable内存
Committed_AS: 3035924 kB #预估当前最坏场景下,需要分配的内存
#虚拟内存
cat /proc/meminfo | grep -e "Vmalloc"
VmallocTotal: 34359738367 kB #已分配的虚拟内存总大小
VmallocUsed: 34780 kB #已使用的虚拟内存总大小
VmallocChunk: 0 kB #最大的连续虚拟内存块
#page table占用的内存(一眼懂)
cat /proc/meminfo | grep PageTables
PageTables: 4120 kB
#大页内存
cat /proc/meminfo | grep -i hugepage
AnonHugePages: 32768 kB
ShmemHugePages: 0 kB
FileHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
buddyinfo由于信息简洁易懂,是最为常用的判断内存碎片问题的方式。详见 “内存分配-buddy章节”
$ cat /proc/buddyinfo
Node 0, zone DMA 0 0 0 1 2 1 1 0 1 1 3
Node 0, zone DMA32 7 6 5 6 5 6 7 7 6 2 272
Node 0, zone Normal 317681 38869 31620 19250 8931 2579 815 182 19 5 0
pagetypinfo首先提供有关页块大小的信息。它提供与buddyinfo相同类型的信息,但按类型进行细分并详细说明每种类型的页的数量。
在理解pagetypeinfo前,需要先了解下memory compaction.
假如一个zone中的内存如下:
白色代表可用内存,红色代表已使用内存。以上内存的碎片化已经比较严重了,如果此时有请求2阶以上的内存,是无法分配的。此时该memory compaction发生作用了,压缩算法会在原有的zone上标记movable pages和Free pages链表。
movable扫描器从底部到顶部扫描,free扫描器从顶部到底部扫描,movable和free扫描器最终会在中间的某点相遇。然后通过页迁移将已使用页转移到zone的顶端。
page compation两种触发方式:
echo x > /proc/sys/vm/compact_memory
来启动page compaction的动作,启动后内核线程kcompactd
就会启动来进行页面整理因为??中数据被迁移到新位置,所以不会有采取的内存回收导致的那么?的性能问题,?且因为?标更明确,得到的连续??的成本也更低。 另外ANON??回收是需要SWAP的,?这?不需要。
此时再来看下/proc/pagetypeinfo的信息:
$ cat /proc/pagetypeinfo
Page block order: 9
Pages per block: 512
...(DMA忽略)
Node 0, zone Normal, type Unmovable 870 530 391 157 103 41 9 2 1 0 0
Node 0, zone Normal, type Movable 5886 9235 5728 4072 1561 324 115 41 12 4 13018
Node 0, zone Normal, type Reclaimable 3 4 8 11 2 3 1 1 1 0 0
Node 0, zone Normal, type HighAtomic 0 0 0 0 0 0 0 0 0 0 0
Node 0, zone Normal, type CMA 0 0 0 0 0 0 0 0 0 0 0
Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0
不同的page被分类,称为pageblock。每个pageblock根据其类型不同分成?个列表,分配内存的时候,根据申请??类型的不同,向相应的列表中申请??,?释放的时候也会根据其所属pageblock回到相应列表。不同的pageblock:
CMA看上去又是一个大块知识,可以简单理解为buddy系统的补充:
(内存之旅——如何提升CMA利用率? https://ost.51cto.com/posts/10815)
VSS/RSS/PSS/USS
查看一个进程占用的内存,常有VSS/RSS/PSS/USS四种形式,主要是内存计算的口径不同
(https://cloud.tencent.com/developer/article/1683708)
VSS(Virtual Set Size)只是一个虚拟空间大小,对内存实际占用量意义不大。
RSS(Resident Set Size)是对于计算一个进程总的内存占用量,包括共享库占用的共享内存大小,比如私有内存大小N,共享内存大小M,则RSS=N+M。肯能会有一点误解,因为像libc这种大部头库文件,共享者很多,都算在一个进程头上不科学。
PSS (Proportional Set Size)是单个进程运行时实际占用的物理内存大小,包含比例分配共享库占用的内存,一个共享库有 N 个进程使用,那么该库比例分配给 PSS 的大小为 1/N。PSS计算进程内存更准确,除了自己独占的内存,再加上分到的共享部分。
USS (Unique Set Size)是进程独自占用的物理内存大小,不包含共享内存
/proc/[pid]/maps
/proc/[pid]/maps可查看进程的虚拟内存的用户空间内存映射
[pg@lzl 2345]$ cat maps
起始地址-结束地址 权限 偏移地址 主次设备号 inode编号 文件名
00400000-00bae000 r-xp 00000000 fd:00 1093852 /pg/pg15.3/bin/postgres ---代码段
00dad000-00dc3000 rw-p 007ad000 fd:00 1093852 /pg/pg15.3/bin/postgres
00dc3000-00df5000 rw-p 00000000 00:00 0
00f1e000-00f60000 rw-p 00000000 00:00 0 [heap] ---heap区
33a6000000-33a6022000 r-xp 00000000 fd:00 1976006 /lib64/ld-2.17.so
...
7fbe2ae09000-7fbe2ae0a000 rw-p 0000c000 fd:00 1975966 /lib64/libnss_files-2.17.so
7fbe2ae1b000-7fbe33ca7000 rw-s 00000000 00:04 12556 /dev/zero (deleted)
7fbe33ca7000-7fbe39b38000 r--p 00000000 fd:00 1181300 /usr/lib/locale/locale-archive
7fbe39b38000-7fbe39b3d000 rw-p 00000000 00:00 0
7fbe39b46000-7fbe39b4d000 rw-s 00000000 00:10 12559 /dev/shm/PostgreSQL.3661351388
7fbe39b4d000-7fbe39b4e000 rw-s 00000000 00:04 32769 /SYSV0010c0b6 (deleted)
7fbe39b4e000-7fbe39b4f000 rw-p 00000000 00:00 0
7fffe3933000-7fffe3948000 rw-p 00000000 00:00 0 [stack] --stack区
7fffe397d000-7fffe397e000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
(1)起始地址-结束地址:本段在虚拟内存中的地址范围
(2)权限:本段的权限; r-读,w-写,x-执行, p-私有
(3)偏移地址:即本段映射地址在文件中的偏移
(4)主次设备号:所映射的文件所属设备的设备号,对应vm_file->f_dentry->d_inode->i_sb->s_dev。匿名映射为0。其中fd为主设备号,00为次设备号。
(5)inode号:对应vm_file->f_dentry->d_inode->i_ino,与ls –i显示的内容相符,匿名映射为0。
(6)映射的文件名:对有名映射而言,是映射的文件名,对匿名映射来说,是此段内存在进程中的作用
以下是文心的分析:(真给它分析出来了,这是一个postgres主进程)
/proc/[pid]/smaps
/proc/[pid]/smaps 文件是基于 /proc/[pid]/maps 的扩展,比同一目录下的maps文件更为详细。每一个VMA都有如下的一系列数据:
[pg@lzl 2345]$ cat smaps
00400000-00bae000 r-xp 00000000 fd:00 1093852 /pg/pg15.3/bin/postgres
Size: 7864 kB --VSS内存
Rss: 408 kB --RSS内存
Pss: 140 kB --PSS内存
Shared_Clean: 404 kB --共享的、干净的内存大小
Shared_Dirty: 0 kB --共享的、已脏的(即已修改)的内存大小
Private_Clean: 4 kB --私有的、干净的内存大小
Private_Dirty: 0 kB --私有的、已脏的内存大小
Referenced: 408 kB --当前页面被标记为已引用或者包含匿名映射
Anonymous: 0 kB --匿名页
AnonHugePages: 0 kB --匿名大页
Swap: 0 kB --已交欢出的内存大小
KernelPageSize: 4 kB --内核页面大小
MMUPageSize: 4 kB --pagetable页面大小
...
7fffe3933000-7fffe3948000 rw-p 00000000 00:00 0 [stack]
Size: 88 kB
Rss: 16 kB
Pss: 16 kB
...
现在知道,maps是进程的内存映射信息,smaps还包含每段映射的内存大小(VSS,RSS,PSS)。
可通过查看进程smaps的PSS、RSS等数据,计算出进程的内存用量,注意单位是kb
所有进程的物理总内存使用量:
grep Pss /proc/[1-9]*/smaps | awk '{total+=$2}; END {printf "%d kB\n", total }'
某进程PSS内存:
cat /proc/90875/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'
某进程的RSS内存 :
cat /proc/68729/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
某进程私有内存:
cat /proc/90875/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'
pmap
pmap命令解析的是/proc/[pid]/maps和/proc/[pid]/smaps文件。参数不多,-x表示展示更多信息
[root@lzl ~]# pmap -x 2345
2345: /pg/pg15.3/bin/postgres -D /pg/1503data
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 7864 212 0 r-x-- postgres
0000000000dad000 88 12 12 rw--- postgres
0000000000dc3000 200 36 32 rw--- [ anon ]
0000000000f1e000 264 12 8 rw--- [ anon ]
00000033a6000000 136 108 0 r-x-- ld-2.17.so
...
00007fbe2ae09000 4 0 0 rw--- libnss_files-2.17.so
00007fbe2ae1b000 145968 4396 4396 rw-s- zero (deleted)
00007fbe33ca7000 96836 8 0 r---- locale-archive
00007fbe39b38000 20 16 16 rw--- [ anon ]
00007fbe39b46000 28 4 4 rw-s- PostgreSQL.3661351388
00007fbe39b4d000 4 0 0 rw-s- [ shmid=0x8001 ]
00007fbe39b4e000 4 4 4 rw--- [ anon ]
00007fffe3933000 84 16 16 rw--- [ stack ]
00007fffe397d000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
---------------- ------ ------ ------
total kB 268896 5532 4540
pmap输出格式跟/proc/[pid]/maps差不多,每个vma地址一行,但是比maps多了VSS和RSS,这样就可以直接看进程虚拟内存的每个区域所使用的大小,帮助快速判断内存较多的区域在哪。
如果地址空间中[heap]太大,那有可能是堆内存产生了泄漏;再比如说,如果进程地址空间包含太多的 vma(可以把 maps 中的每一行理解为一个 vma),那很可能是应用程序调用了很多 mmap 而没有 munmap;再比如持续观察地址空间的变化,如果发现某些项在持续增长,那很可能是那里存在问题
分析示例
从主机的TOP的内存查看某pg backend进程内存看上去比较高,此时需要进一步分析map信息:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
68729 postgres 20 0 5579004 5.116g 5.114g R 97.4 1.4 128:27.94 postgres: lzl: lzldb lzl 30.78.14.174(58067) DELETE
查看这个进程Rss、Pss、Uss
cat /proc/68729/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
5422.67 ---5.4G Rss
cat /proc/68729/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'
467.957 ---467mb Pss
cat /proc/68729/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'
179.605 ---179mb Uss
Rss-Uss=5.3G的共享内存,从Pss-Uss=290mb的proportion共享内存,大致能看出这个backend只是这个共享内存proportion的一小部分
$ pmap -x 68729
68729: postgres: pdmp: pdmpdata pdmp 30.78.14.174(46252) DELETE
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 6084 2444 0 r-x-- postgres
0000000000bf0000 4 4 4 r---- postgres
0000000000bf1000 52 52 52 rw--- postgres
...
00002b7f65bfa000 5441216 5365444 5365444 rw-s- zero (deleted) --这部分占用最多
00002b80b1daa000 48 0 0 r-x-- libnss_files-2.17.so
00002b80b1db6000 2044 0 0 ----- libnss_files-2.17.so
00002b80b1fb5000 4 4 4 r---- libnss_files-2.17.so
00002b80b1fb6000 4 4 4 rw--- libnss_files-2.17.so
00002b80b1fb7000 24 0 0 rw--- [ anon ]
00002b80ba001000 516 516 516 rw--- [ anon ]
00007fffe16f7000 132 88 88 rw--- [ stack ]
00007fffe175b000 8 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
继续深入到smap分析,可以直接定位到zero (deleted)这部分
$ cat smaps
00400000-009f1000 r-xp 00000000 fd:06 58726481 /paic/postgres/base/9.6.6/bin/postgres
...
2b7f65bfa000-2b80b1daa000 rw-s 00000000 00:04 72254 /dev/zero (deleted)
Size: 5441216 kB
Rss: 5365444 kB
Pss: 264618 kB
Shared_Clean: 0 kB
Shared_Dirty: 5365444 kB --共享的脏数据
Private_Clean: 0 kB
Private_Dirty: 0 kB
Referenced: 5364764 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr sh mr mw me ms sd
从以上分析可以得出:这是个pg的私有进程,变动了大量数据还没有刷脏,自己私有内存不多,大部分都是共享内存中占用的。这很有可能是一个pg中的事务变动了很多数据暂时还没提交。
另外,/dev/zero (deleted)在proc(5) — Linux manual page有解释:
Although these entries are present for memory regions that were mapped with the MAP_FILE flag, the way anonymous shared memory (regions created with the MAP_ANON | MAP_SHARED flags) is implemented in Linux means that such regions also appear on this directory. Here is an example where the target file is the deleted /dev/zero one:
lrw-------. 1 root root 64 Apr 16 21:33 7fc075d2f000-7fc075e6f000 -> /dev/zero (deleted)
“非专业翻译”:匿名页和共享页由 /dev/zero (deleted)表示
status可查看进程的状态信息,包含一部分内存信息。
[root@lzl 2345]# cat status
Name: postgres ---运行这个线程的命令
State: S (sleeping) ---进程状态
Tgid: 2345 ---Thread group ID (i.e., Process ID)
Pid: 2345 ---Thread ID
PPid: 1 ---PID of parent process.
...
VmPeak: 268964 kB ---虚拟内存峰值
VmSize: 268896 kB ---虚拟内存当前值
VmLck: 0 kB
VmHWM: 13400 kB ---RSS的峰值
VmRSS: 5532 kB ---RSS的当前值
VmData: 528 kB ---数据段
VmStk: 88 kB ---stack段
VmExe: 7864 kB ---text段
VmLib: 3100 kB ---共享库代码段
VmPTE: 136 kB ---Page table entries
VmSwap: 308 kB ---swap的大小
Threads: 1 ---该进程的线程数
....
status相对map,没有映射信息,内存数据更概况一些,也可以更直观的看到虚拟内存的每个段所占用的大小
查看SWAP用量最多的进程:
for file in /proc/*/status ; do awk '/VmSwap|Name|^Pid/{printf $2 " " $3}END{ print ""}' $file; done | sort -k 3 -n -r | head
cgroup的memory控制现在已经很常见。一些主机参数需要在cgroup中设置。内存设置、监控信息均在/sys/fs/cgroup/memory/下面
cginfo查看CGROUP内存分配和使用情况 : /opt/cgtools/cginfo -t perf -s mem
cginfo -t perf -s mem
==================== Cgroup Performance: memory ====================
DB_TYPE INSTANCE_NAME MEM_OOM MEM_FILE_GB MEM_MAP_GB MEM_USED_GB MEM_ALLO_GB ALLO_RATE MEM_GLOB_GB GLOB_RATE
------- ------------- ------- ----------- ---------- ----------- ----------- --------- ----------- ---------
postgres LZLDB 0 154.3 0.0 4.2 160.0 2.6% 375 1.1%
查看比较详细的CGROUP内存使用状态: /sys/fs/cgroup/memory/[group]/memory.stat
$ cat memory.stat
...
total_cache 167791534080
total_rss 4006932480
total_rss_huge 0
total_mapped_file 11747328
total_swap 0
total_pgpgin 792754417976
total_pgpgout 792712474991
total_pgfault 477971874868
total_pgmajfault 97318
total_inactive_anon 1610874880
total_active_anon 2408255488
total_inactive_file 73446166528
total_active_file 94332768256
total_unevictable 0
smem是一款强大的展示内存使用情况的工具,读取/proc下面的smaps、meminfo等信息然后汇总输出。smem可以输出总体和具体map的内存情况,非常直观而且可以从不同的维度去分析,总体是一款分析内存使用非常好用的工具。
repo可直接下载,基本上解压即可使用。更多用法可参考smem memory reporting tool,以下只简单示例:
查看系统内存使用 -w
:
[root@lzl ~]# smem -w -k
Area Used Cache Noncache
firmware/hardware 0 0 0
kernel image 0 0 0
kernel dynamic memory 183.9M 84.0M 99.9M
userspace memory 112.3M 62.2M 50.1M
free memory 700.3M 700.3M 0
查看每个用户的内存消耗 -u
:
[root@lzl ~]# smem -s pss -urk
User Count Swap USS PSS RSS
oracle 25 85.2M 30.8M 95.7M 383.0M
root 93 112.4M 38.5M 42.3M 86.2M
pg 12 5.9M 1.6M 2.5M 5.9M
mysql 1 169.7M 1.7M 1.7M 2.0M
查看某个用户的内存消耗-U
[root@lzl ~]# smem -U pg -k
PID User Command Swap USS PSS RSS
2345 pg /pg/pg15.3/bin/postgres -D 364.0K 124.0K 134.0K 228.0K
2352 pg postgres: logical replicati 636.0K 144.0K 161.0K 196.0K
...
过滤某个进程 -P
(PROCESSFILTER,不是pid):
[root@lzl ~]# smem -P postgres -p
PID User Command Swap USS PSS RSS
2346 pg /pg/pg16.0/bin/postgres -D 0.01% 0.01% 0.01% 0.01%
2350 pg postgres: walwriter 0.01% 0.01% 0.01% 0.01%
...
查看进程的mapping和内存占用情况 -m
:
[root@lzl ~]# smem -P postgres -mpr -s pss
Map PIDs AVGPSS PSS
<anonymous> 13 0.02% 0.24%
[heap] 3 0.07% 0.20%
/usr/lib64/libpython2.6.so.1.0 1 0.11% 0.11%
/pg/pg15.3/bin/postgres 6 0.01% 0.06%
/pg/pg16.0/bin/postgres 6 0.01% 0.06%
/dev/zero 12 0.00% 0.03%
[stack] 13 0.00% 0.02%
...
smem看进程内存的USS\PSS\RSS很直观,不过有个问题,smem不能过滤pid,只能通过用户名或PROCESSFILTER去过滤,对于一个主机部署多个数据库实例时,过滤父PID或子PID,不是很友好。
top可实时的展示系统运行状态。top玩法也可以非常花哨,直接top运行同样可以展示非常多的信息。
使用top中的排序:
command sorted-field supported
M %MEM Yes
N PID Yes
P %CPU Yes
T TIME+ Yes
可以用%MEM来排序内存占用较多的进程,%MEM表示RES的内存百分比
top - 23:38:01 up 3 days, 22:32, 2 users, load average: 1.12, 1.42, 1.09
Tasks: 198 total, 13 running, 183 sleeping, 0 stopped, 2 zombie
Cpu(s): 0.0%us, 0.3%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1020348k total, 325848k used, 694500k free, 1352k buffers
Swap: 4128760k total, 635872k used, 3492888k free, 150288k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18537 oracle 20 0 636m 24m 21m S 0.0 2.4 0:05.41 oracle
18533 oracle 20 0 638m 24m 21m S 0.0 2.4 0:02.01 oracle
...
18509 oracle 20 0 634m 4384 4036 S 0.0 0.4 0:01.93 oracle
2639 root 20 0 729m 4052 1444 S 0.0 0.4 8:45.32 nautilus
内存相关的解读:
第四行:
内存使用信息:物理内存量、已用内存量、空闲内存量、缓冲内存量
第五行:
交换分区信息:可用交换区总量、已用交换区总量、空闲交换区总量、内核用于缓存的数量
第六行(内存相关):
另外,查看内存的时候不要忘了看一眼进程的状态
S(示例第八列)Process Status:
top命令可以看到主机的内存汇总信息,进程使用内存信息有RSS,SHR,粗略算一下RES-SHR=USS也可以计算私有内存的占用大小,另外还可以看到进程状态,所以top -p查看某进程的内存基本信息还是很好用的。
free展示主机的swap、内存的总量和剩余量,信息都是解析自/proc/meminfo
user@ubuntu:~$ free
total used free shared buff/cache available
Mem: 8029356 794336 6297928 183384 937092 6816804
Swap: 0 0 0
total :Total usable memory (MemTotal and SwapTotal in /proc/meminfo). This includes the physical and swap memory minus a few reserved bits and kernel binary code.
used : Used or unavailable memory (calculated as total - available)
free:Unused memory (MemFree and SwapFree in /proc/meminfo) shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo)
buffers:Memory used by kernel buffers (Buffers in /proc/meminfo)
cache:Memory used by the page cache and slabs (Cached and SReclaimable in /proc/meminfo)。不仅有pagecache,还有SReclaimable的slab!
buff/cache:Sum of buffers and cache
available:cache包含pagecache和SReclaimable,free包含mem free和swap free;而available包含pagecache和即将被reclaim的内存;表示可用内存,但它们的计算方式不同,在实际应用中,由于缓存的存在,available通常会比free大
Page Cache:
Page cache 主要用来作为文件系统上的文件数据的缓存来用,尤其是针对当进程对文件有 read/write 操作的时候。
Buffer Cache:
Buffer cache 则主要是设计用来在系统对块设备进行读写的时候,对块进行数据缓存的系统来使用
ps最大的好处就是从进程的角度分析进程状态(包括内存),COMMAND带[ ]标志的进程为kernel进程。
[pg@lzl ~]$ ps aux|head -1;ps aux|grep postgres
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
pg 2345 0.0 0.0 268896 236 ? Ss Jan01 0:03 /pg/pg15.3/bin/postgres -D /pg/1503data
pg 2353 0.0 0.0 269040 196 ? Ss Jan01 0:00 postgres: checkpointer
pg 2354 0.0 0.0 269032 160 ? Ss Jan01 0:02 postgres: background writer
pg 2356 0.0 0.0 269032 116 ? Ss Jan01 0:01 postgres: walwriter
pg 2357 0.0 0.0 270508 824 ? Ss Jan01 0:02 postgres: autovacuum launcher
pg 2358 0.0 0.0 270492 620 ? Ss Jan01 0:00 postgres: logical replication launcher
pg 29818 0.0 0.0 103372 868 pts/0 S+ 09:16 0:00 grep postgres
VSZ,RSS单位是kb。内存信息比较少,VSZ没什么价值,RSS可以参考一下,没有PSS,USS这类信息,能分析的内容不多
ipcs -m
是一个用于查询 IPC(进程间通信)共享内存资源的命令。分析共享内存的时候比较有用。
[pg@lzl ~]$ ipcs -m
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0010c0b6 32769 pg 600 56 6
此时连接一个会话到PostgreSQL,会多一个backend进程
------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x0010c0b6 32769 pg 600 56 7
nattch+1,说明私有的backend进程也分享了一部分PG共享出来的内存。此时理解下面这个图也更深刻
(http://gauss.ececs.uc.edu/Courses/c4029/code/memory/virtual.pdf)
vmstat是Virtual Meomory Statistics(虚拟内存统计)的缩写,可对操作系统的虚拟内存、进程、CPU活动进行监控。它是对系统的整体情况进行统计,不足之处是无法对某个进程进行深入分析。
有用的参数说明:
vmstat [options] [delay [count]]
OPTIONS:
-a 显示活跃和非活跃内存
-m 显示slabinfo
-s 显示内存相关统计信息及多种系统活动数量
-t Append timestamp to each line,在最后加个输出时间戳
-w Wide output mode.没有加w的话,输出比较窄,可以减少对不齐问题
-bash-4.1$ vmstat -w 1 3
procs -------------------memory------------------ ---swap-- -----io---- --system-- -----cpu-------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 661652 763348 324 76100 15 12 54 21 18 45 0 0 79 21 0
2 1 661652 763340 304 75764 0 0 0 32 12 84 0 1 0 99 0
41 1 661652 760744 244 78300 228 0 3216 0 265 442 0 0 0 100 0
pidstat是sysstat工具的一个命令,用于监控全部或指定进程的CPU、内存、线程、设备IO等系统资源的占用情况。
有用的参数说明:
pidstat OPTIONS interval [ count ]
-d :Report I/O statistics
-u :Report CPU utilization
-r :Report page faults and memory utilization
-w :Report task switching activity
-p :pid[,...]
-l :Display the process command name and all its arguments.
查看某进程的内存情况:
-bash-4.1$ pidstat -r -l -p 2345
Linux 2.6.32-431.el6.x86_64 (lzl) 01/06/2024 _x86_64_ (1 CPU)
02:48:32 PM PID minflt/s majflt/s VSZ RSS %MEM Command
02:48:32 PM 2345 0.23 0.00 268896 240 0.02 /pg/pg15.3/bin/postgres -D /pg/1503data
各类指标比较容易理解,VSZ,RSS说的都不想说了
minflt/s:这是“minor page faults”的缩写,指的是每秒发生的“次要页面错误”的数量。当一个程序试图访问一个不在物理内存中的页面时,就会发生页面错误。如果这个页面确实在硬盘上的交换区(swap)中,那么这是一个次要页面错误(minor page fault)。
majflt/s:这是“major page faults”的缩写,指的是每秒发生的“主要页面错误”的数量。与次要页面错误不同,主要页面错误发生在程序试图访问一个不在物理内存中,且也不在硬盘上的交换区中的页面时。
sar(System Activity Reporter 系统活动情况报告)是目前 Linux 上最为全面的系统性能分析工具之一,可以从多方面对系统的活动进行报告,包括:文件的读写情况、系统调用的使用情况、磁盘 I/O、CPU 效率、内存使用状况、进程活动及 IPC 有关的活动等。SAR工具是sysstat软件包的一部分。
(https://www.brendangregg.com/Perf/linux_observability_sar.png)
sar非常强大,man的参数介绍就有1k多行,本篇不太可能解释完(偷懒)。
内存相关的参数:
sar OPTIONS interval [ count ]
-B :Report paging statistics
-r :Report memory utilization statistics
-W :Report swapping statistics.
-H :Report hugepages utilization statistics
-s [ start_time ] ] [ -e [ end_time ]
示例:sar查看内存利用率
sar -r 1 3
示例:sar查看内存页的状态
sar -B 1 3
示例:sar查看swap信息
sar -W 1 3
报告说明
示例:sar查看历史内存信息
sar -B -s "08:00:00" -e "10:00:00"
#不加-e表示从开始时间点到现在的信息
$ sar -B -s "08:00:00"
09:45:01 PM pgpgin/s pgpgout/s fault/s majflt/s pgfree/s pgscank/s pgscand/s pgsteal/s %vmeff
09:46:01 PM 414429.37 395024.08 179478.63 0.07 352922.62 12003.78 4266.52 16269.42 99.99
09:47:01 PM 879907.08 337948.43 157970.97 0.02 402290.21 0.00 0.00 0.00 0.00
09:48:01 PM 772977.43 507343.30 150255.50 0.05 466742.08 0.00 5821.28 5821.27 100.00
以上pgsank表示kswapd进程介入回收内存的速度,pgscand表示直接内存回收的速度
gcore是gdb的一部分,可生成进程的core dump文件
示例dump一个PostgreSQL的backend进程
[root@lzl ~] ps -ef|grep 8296
pg 8296 2345 0 09:41 ? 00:00:00 postgres: pg lzldb [local] idle
[root@lzl ~] cat /proc/8296/smaps |grep Pss |awk '{sum+=$2 };END {print sum/1024}'
0.351562
[root@lzl ~] cat /proc/8296/smaps |grep Rss |awk '{sum+=$2 };END {print sum/1024}'
0.445312
[root@lzl ~] cat /proc/8296/smaps|sed '/zero/,/VmFlags/d' |grep Private |awk '{sum+=$2 };END {print sum/1024}'
0.0078125
8296进程的uss只有7.8 bytes,RSS 445 bytes。dump内存:
gcore -o /tmp/dump 8296
dump要花点时间,而且dump下来的文件比较大,并且会夯住进程
[root@lzl 8296]# ls -lh /tmp/dump.8296
-rw-r--r-- 1 root root 252M Jan 7 10:59 /tmp/dump.8296
gdb可查看内存中具体位置和内容
示例查看PostgreSQL backend的缓存数据
1.新开一个会话查找一个分区表,会话保持不断开
[pg@lzl ~]$ psql
psql (15.3)
Type "help" for help.
postgres=> \c lzldb
You are now connected to database "lzldb" as user "pg".
lzldb=> select * from lzlpartition limit 1;
appl_no | is_deleted | date_created | date_updated
---------+------------+--------------+--------------
(0 rows)
2.pmap,smaps查看进程内存占用情况,找到想dump的内存段
[root@lzl 13393]# pmap -x 13393
13393: postgres: pg lzldb [local] idle
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 7864 1204 0 r-x-- postgres
..
00007fbe2ae1b000 145968 2164 176 rw-s- zero (deleted) ---RSS这里占用最多
00007fbe33ca7000 96836 0 0 r---- locale-archive
00007fbe39b38000 20 0 0 rw--- [ anon ]
00007fbe39b46000 28 0 0 rw-s- PostgreSQL.3661351388
00007fbe39b4d000 4 0 0 rw-s- [ shmid=0x8001 ]
00007fbe39b4e000 4 0 0 rw--- [ anon ]
00007fffe3933000 84 36 0 rw--- [ stack ]
00007fffe397d000 4 4 0 r-x-- [ anon ]
ffffffffff600000 4 0 0 r-x-- [ anon ]
[root@lzl 13393]# cat /proc/13393/smaps |grep -A 13 zero
7fbe2ae1b000-7fbe33ca7000 rw-s 00000000 00:04 12556 /dev/zero (deleted)
Size: 145968 kB
Rss: 2164 kB
Pss: 2164 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 1988 kB
Private_Dirty: 176 kB
Referenced: 2164 kB
Anonymous: 0 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
3.gdb dump memory
dump内存的起始位置为smaps中的vm地址+0x
[pg@lzl tmp]$ gdb
(gdb) attach 13393
(gdb) dump memory /tmp/delete.dump 0x7fbe2ae1b000 0x7fbe33ca7000
4.查看dump文件
可简单通过strings 查看
[root@lzl 13393]# strings /tmp/delete.dump|grep lzl|sort|uniq
...
@lzlpartition_202301
lzlpartition_202301
lzlpartition_202301_appl_no_idx
lzlpartition_202301_date_created_idx
...
lzlpartition_202306
lzlpartition_202306_appl_no_idx
lzlpartition_202306_date_created_idx
@lzlpartition_attach
lzlpartition_attach
@nk_lzlpartition
nk_lzlpartition
select * from lzlpartition limit 1;
会话只要查询了分区表,就把所有分区、索引等元数据全部缓存到backend进程中
注意:
轻松突破文件IO瓶颈:内存映射mmap技术 https://blog.51cto.com/u_15481245/6582927
一步一图带你深入理解 Linux 物理内存管理 https://cloud.tencent.com/developer/article/2352771?areaId=106001
从DBA的角度系统学习一下内存管理 https://mp.weixin.qq.com/s/CybzGP44dVWQN5hfFrVx7A
https://linux2me.wordpress.com/2017/09/15/linux-introduction-to-memory-management/
Memory management in Linux https://www.slideshare.net/raghusiddarth/memory-management-in-linux-11551521?from_search=2
Linux Performance Tunning Memory https://www.slideshare.net/shayc1/linux-performance-tunning-memory?from_search=4
Linux内核这样学才能学会(内存篇) https://mp.weixin.qq.com/s/lKKHH1MMiZbnIbDQt3-IAQ
https://courses.engr.illinois.edu/cs241/sp2014/lecture/09-VirtualMemory_II_sol.pdf
Linux的进程虚拟地址空间 https://maodanp.github.io/2019/06/02/linux-virtual-space/
Data Processing on Modern Hardware https://db.in.tum.de/teaching/ss21/dataprocessingonmodernhardware/MH_8.pdf?lang=de
Chapter 2 Describing Physical Memory https://www.kernel.org/doc/gorman/html/understand/understand005.html
各类命令的man手册
linux强制回收内存,linux内存源码分析 - 内存回收(整体流程) https://blog.csdn.net/weixin_35094083/article/details/116688112
<Memory compaction https://lwn.net/Articles/368869/>
内存之旅——如何提升CMA利用率? https://ost.51cto.com/posts/10815
The implementations of anti pages fragmentation in Linux kernel https://teawater.github.io/presentation/antif.pdf
T H E /proc F I L E S Y S T E M https://www.kernel.org/doc/Documentation/filesystems/proc.txt
The /proc/meminfo File in Linux https://www.baeldung.com/linux/proc-meminfo
the proc filesystem https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/deployment_guide/s2-proc-meminfo
linux的/proc/{pid}/maps介绍及使用(定位内存泄漏) https://blog.csdn.net/mijichui2153/article/details/123934531
Linux top命令的cpu使用率和内存使用率 https://blog.csdn.net/weixin_45030965/article/details/127693042
smem memory reporting tool https://www.selenic.com/smem/
Linux performance optimization https://feiyang233.club/post/linux/
gdb onlinedocs https://sourceware.org/gdb/current/onlinedocs/gdb
Linux_Core_Dumps https://averageradical.github.io/Linux_Core_Dumps.pdf