本文大部分转载和组装，只是觉得这些知识应该放到一起比较好。
进程系统资源的使用原理
大部分进程通过glibc申请使用内存，但是glibc也是一个应用程序库，它最终也是要调用操作系统的内存管理接口来使用内存。大部分情况下，glibc对用户和操作系统是透明的，所以直接观察操作系统记录的进程对内存的使用情况有很大的帮助。但是glibc自己的实现也是有问题的，所以太特殊情况下追究进程的内存使用也要考虑glibc的因素。其他操作系统资源使用情况则可以直接通过proc文件系统查看。
进程所需要的系统资源种类
内存
进程需要内存，但并不一定需要物理内存。一个进程可以申请1个g的内存，内核也确实会批准给他，但是内核真正给他安排实际对应的物理内存的时候是在进程需要实际使用这篇内存的时候，这个时候会引发缺页异常，内核就在这个异常处理代码中把实际的内存安排给进程。就像你在银行存钱的时候，大部分时候你的资产都是个数目，只有当你要取出现金的时候银行才有必要筹措现金支付给你（因为他之前承诺过），但是通常银行的现金数永远是小与储户的总资产数的（资产泡沫也就是这么来的），当大家都要挤兑的时候，银行就得破产。操作系统的内存也一样，当进程都要求兑现的时候，内核不一定能够全部兑现，内核也得崩溃。
进程的内存的种类：进程使用来存放数据的（堆），用来执行进程的（栈），与其他进程的物理内存（例如共享库，共享内存），进程的虚拟地址空间大小（取决于你是32位还是64位，2的该数次方），应用进程实际正在使用的物理地址的大小（rss），进程用来放要执行的代码的部分（trs）。总体来说，应用程序实际要使用的物理地址由数据、栈、可执行代码存放三部分组成。大部分进程需要最多的一般是数据内存。
分析进程的入口点
每个进程都有父进程、进程组、会话组（一般进程组属于会话组，而进程属于进程组）。
每个进程都有属于自己的线程组（有的甚至有协程）
发生缺页的次数可以用来诊断是否是内存敏感的或内存使用过度。
在内核态和用户态分别的运行时间、任务的累计等待时间可以看出该进程对系统调用的依赖程度（或许你需要把进程放到内核实现或者是使用非阻塞的）
调度策略、运行在哪个CPU上和进程的优先级可以用来在系统资源不足时不公平的分配资源。
被swap换出的页数和使用的各种内存的统计表明了进程的内存使用力量。
进程的cap能力集可以看出进程是否有超过的权限
一、/proc/pid/statm
pid/statm包含了在此进程中所有CPU活跃的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。
/proc/1 # catstatm
550 70 62 451 0 97 0
输出解释
CPU 以及CPU0。。。的每行的每个参数意思（以第一行为例）为：
参数解释 /proc/1/status
Size (pages)= 550 任务虚拟地址空间的大小 VmSize/4
Resident(pages)= 70 应用程序正在使用的物理内存的大小VmRSS/4
Shared(pages)= 62 共享页数
Trs(pages)= 451 程序所拥有的可执行虚拟内存的大小VmExe/4
Lrs(pages)= 0 被映像到任务的虚拟内存空间的库的大小VmLib/4
Drs(pages)= 97 程序数据段和用户态的栈的大小 （VmData+ VmStk ）4
dt(pages) 0
二、/proc/pid/stat
pid/stat包含了进程所有CPU活跃的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。
/proc/1 # cat stat
1 (linuxrc) S 0 0 0 0 -1 8388864 50 633 204 2 357 72 342 16 0 1 0 22 2252800 70 4294967295 32768 1879936 31992707043199269552 1113432 0 0 0 674311 3221479524 0 0 0 0 0 0
每个参数意思为：
参数解释
pid=1 进程(包括轻量级进程，即线程)号
comm= linuxrc 应用程序或命令的名字
task_state=S 任务的状态，R:runnign,S:sleeping (TASK_INTERRUPTIBLE), D:disk sleep (TASK_UNINTERRUPTIBLE), T:stopped, T:tracing stop,Z:zombie, X:dead
ppid=0 父进程ID
pgid=0 线程组号
sid=0 c该任务所在的会话组ID
tty_nr=0(pts/3) 该任务的tty终端的设备号，INT（0/256）=主设备号，（0-主设备号）=次设备号
tty_pgrp=-1 终端的进程组号，当前运行在该任务所在终端的前台任务(包括shell 应用程序)的PID。
task->flags=8388864进程标志位，查看该任务的特性
min_flt=50该任务不需要从硬盘拷数据而发生的缺页（次缺页）的次数
cmin_flt=633 累计的该任务的所有的waited-for进程曾经发生的次缺页的次数目
maj_flt=20该任务需要从硬盘拷数据而发生的缺页（主缺页）的次数
cmaj_flt=4 累计的该任务的所有的waited-for进程曾经发生的主缺页的次数目
当一个进程发生缺页中断的时候，进程会陷入内核态，执行以下操作：
1、检查要访问的虚拟地址是否合法
2、查找/分配一个物理页
3、填充物理页内容（读取磁盘，或者直接置0，或者啥也不干）
4、建立映射关系（虚拟地址到物理地址）
重新执行发生缺页中断的那条指令
如果第3步，需要读取磁盘，那么这次缺页中断就是majflt，否则就是minflt。
utime=2 该任务在用户态运行的时间，单位为jiffies
stime=357 该任务在核心态运行的时间，单位为jiffies
cutime=72 累计的该任务的所有的waited-for进程曾经在用户态运行的时间，单位为jiffies
cstime=342 累计的该任务的所有的waited-for进程曾经在核心态运行的时间，单位为jiffies
priority=16 任务的动态优先级
nice=0 任务的静态优先级
num_threads=1 该任务所在的线程组里线程的个数
it_real_value=0 由于计时间隔导致的下一个SIGALRM 发送进程的时延，以 jiffy 为单位.
start_time=22 该任务启动的时间，单位为jiffies
vsize=2252800（bytes） 该任务的虚拟地址空间大小
rss=70(page) 该任务当前驻留物理地址空间的大小
这些页可能用于代码，数据和栈。
rlim=4294967295=0xFFFFFFFF（bytes） 该任务能驻留物理地址空间的最大值
start_code=32768=0x8000 该任务在虚拟地址空间的代码段的起始地址(由连接器决定)
end_code=1879936该任务在虚拟地址空间的代码段的结束地址
start_stack=3199270704=0Xbeb0ff30该任务在虚拟地址空间的栈的开始地址
kstkesp=3199269552 sp(32 位堆栈指针) 的当前值, 与在进程的内核堆栈页得到的一致.
kstkeip=1113432 =0X10FD58 指向将要执行的指令的指针,PC(32 位指令指针)的当前值.
pendingsig=0 待处理信号的位图，记录发送给进程的普通信号
block_sig=0 阻塞信号的位图
sigign=0 忽略的信号的位图
sigcatch=674311被俘获的信号的位图
wchan=3221479524 如果该进程是睡眠状态，该值给出调度的调用点
nswap=0 被swapped的页数
cnswap=0 所有子进程被swapped的页数的和
exit_signal=0 该进程结束时，向父进程所发送的信号
task_cpu(task)=0 运行在哪个CPU上
task_rt_priority=0 实时进程的相对优先级别
task_policy=0 进程的调度策略，0=非实时进程，1=FIFO实时进程；2=RR实时进程
三、/proc/pid/status
包含了所有CPU活跃的信息，该文件中的所有值都是从系统启动开始累计到当前时刻。
/proc/286 # cat status
Name: mmtest
State: R (running)
SleepAVG: 0%
Tgid: 286
Pid: 286
PPid: 243
TracerPid: 0
Uid: 0 0 0 0
Gid: 0 0 0 0
FDSize: 32
Groups:
VmPeak: 1464 kB
VmSize: 1464 kB
VmLck: 0 kB
VmHWM: 344 kB
VmRSS: 344 kB
VmData: 20 kB
VmStk: 84 kB
VmExe: 4 kB
VmLib: 1300 kB
VmPTE: 6 kB
Threads: 1
SigQ: 0/256
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000000000000
CapInh: 0000000000000000
CapPrm: 00000000fffffeff
CapEff: 00000000fffffeff
输出解释
参数解释
Name 应用程序或命令的名字
State 任务的状态，运行/睡眠/僵死/
SleepAVG 任务的平均等待时间(以nanosecond为单位)，交互式任务因为休眠次数多、时间长，它们的 sleep_avg 也会相应地更大一些，所以计算出来的优先级也会相应高一些。
Tgid=286 线程组号
Pid=286 任务ID
Ppid=243 父进程ID
TracerPid=0 接收跟踪该进程信息的进程的ID号
Uid Uid euid suid fsuid
Gid Gid egid sgid fsgid
FDSize=32 文件描述符的最大个数，最多能打开的文件句柄的个数file->fds
Groups：
VmPeak: 60184 kB /*进程地址空间的大小*/
VmHWM: 18020 kB /*文件内存映射和匿名内存映射的大小*/
VmSize(KB)=1499136 任务虚拟地址空间的大小(total_vm-reserved_vm)，其中total_vm为进程的地址空间的大小，reserved_vm：进程在预留或特殊的内存间的物理页
VmLck(KB)=0 任务已经锁住的物理内存的大小。锁住的物理内存不能交换到硬盘 (locked_vm)
VmRSS(KB)= 344 kB 应用程序正在使用的物理内存的大小，就是用ps命令的参数rss的值 (rss)
VmData(KB)=20KB 程序数据段的大小（所占虚拟内存的大小），存放初始化了的数据； (total_vm-shared_vm-stack_vm)
VmStk(KB)=84KB 任务在用户态的栈的大小(stack_vm)
VmExe(KB)=4KB 程序所拥有的可执行虚拟内存的大小，代码段，不包括任务使用的库 (end_code-start_code)
VmLib(KB)=1300KB 被映像到任务的虚拟内存空间的库的大小 (exec_lib)
VmPTE=6KB 该进程的所有页表的大小，单位：kb
Threads=1 共享使用该信号描述符的任务的个数，在POSIX多线程序应用程序中，线程组中的所有线程使用同一个信号描述符。
SigQ 待处理信号的个数
SigPnd 屏蔽位，存储了该线程的待处理信号
ShdPnd 屏蔽位，存储了该线程组的待处理信号
SigBlk 存放被阻塞的信号
SigIgn 存放被忽略的信号
SigCgt 存放被俘获到的信号
CapInh Inheritable，能被当前进程执行的程序的继承的能力
CapPrm Permitted，进程能够使用的能力，可以包含CapEff中没有的能力，这些能力是被进程自己临时放弃的，CapEff是CapPrm的一个子集，进程放弃没有必要的能力有利于提高安全性
CapEff Effective，进程的有效能力
四、/proc/loadavg
该文件中的所有值都是从系统启动开始累计到当前时刻。该文件只给出了所有CPU的集合信息，不能该出每个CPU的信息。
/proc # cat loadavg
1.0 1.00 0.93 2/19 301
每个值的含义为：
参数 解释
lavg_1 (1.0) 1-分钟平均负载
lavg_5 (1.00) 5-分钟平均负载
lavg_15(0.93) 15-分钟平均负载
nr_running (2) 在采样时刻，运行队列的任务的数目，与/proc/stat的procs_running表示相同意思
nr_threads (19) 在采样时刻，系统中活跃的任务的个数（不包括运行已经结束的任务）
last_pid(301) 最大的pid值，包括轻量级进程，即线程。
假设当前有两个CPU，则每个CPU的当前任务数为4.61/2=2.31
五、/proc/286/smaps
该文件反映了该进程的相应线性区域的大小
/proc/286 # cat smaps
00008000-00009000 r-xp 00000000 00:0c1695459 /memtest/mmtest
Size: 4 kB
Rss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 4 kB
Private_Dirty: 0 kB
00010000-00011000 rw-p 00000000 00:0c1695459 /memtest/mmtest
Size: 4 kB
Rss: 4 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 4 kB
00011000-00012000 rwxp 00011000 00:000 [heap]
Size: 4 kB
Rss: 0 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 0 kB
40000000-40019000 r-xp 00000000 00:0c2413396 /lib/ld-2.3.2.so
Size: 100 kB
Rss: 96 kB
用户态进程使用内核内存管理的接口方法
从操作系统角度来看，进程分配内存有两种方式，分别由两个系统调用完成：brk和mmap（不考虑共享内存）。
1、brk是将数据段(.data)的最高地址指针_edata往高地址推（详见glibc部分）
2、mmap是在进程的虚拟地址空间中（堆和栈中间，称为文件映射区域的地方）找一块空闲的虚拟内存。
这两种方式分配的都是虚拟内存，没有分配物理内存。在第一次访问已分配的虚拟地址空间的时候，发生缺页中断，操作系统负责分配物理内存，然后建立虚拟内存和物理内存之间的映射关系。
在标准C库中，提供了malloc/free函数分配释放内存，这两个函数底层是由brk，mmap，munmap这些系统调用实现的。
Glibc的内存管理方法
进程内存区域的预定义
glibc内存分配办法
下面以一个例子来说明内存分配的原理，默认是用的ptmalloc，后续有jemalloc对pymalloc的改进实现。
原理
当malloc小于128k的内存，使用brk分配内存，将_edata往高地址推(只分配虚拟空间，不对应物理内存(因此没有初始化)，第一次读/写数据时，引起内核缺页中断，内核才分配对应的物理内存，然后虚拟地址空间建立映射关系)，如下图：
1、进程启动的时候，其（虚拟）内存空间的初始布局如图1所示。
其中，mmap内存映射文件是在堆和栈的中间（例如libc-2.2.93.so，其它数据文件等），为了简单起见，省略了内存映射文件。_edata指针（glibc里面定义）指向数据段的最高地址。
2、进程调用A=malloc(30K)以后，内存空间如图2：
malloc函数会调用brk系统调用，将_edata指针往高地址推30K，就完成虚拟内存分配。
你可能会问：只要把_edata+30K就完成内存分配了？
事实是这样的，_edata+30K只是完成虚拟地址的分配，A这块内存现在还是没有物理页与之对应的，等到进程第一次读写A这块内存的时候，发生缺页中断，这个时候，内核才分配A这块内存对应的物理页。也就是说，如果用malloc分配了A这块内容，然后从来不访问它，那么，A对应的物理页是不会被分配的。
3、进程调用B=malloc(40K)以后，内存空间如图3。
情况二、malloc大于128k的内存，使用mmap分配内存，在堆和栈之间找一块空闲内存分配(对应独立内存，而且初始化为0)，如下图：
4、进程调用C=malloc(200K)以后，内存空间如图4：
默认情况下，malloc函数分配内存，如果请求内存大于128K（可由M_MMAP_THRESHOLD选项调节），那就不是去推_edata指针了，而是利用mmap系统调用，从堆和栈的中间分配一块虚拟内存。
这样子做主要是因为:
brk分配的内存需要等到高地址内存释放以后才能释放（例如，在B释放之前，A是不可能释放的，这就是内存碎片产生的原因，什么时候紧缩看下面），而mmap分配的内存可以单独释放。当然，还有其它的好处，也有坏处，再具体下去，有兴趣的同学可以去看glibc里面malloc的代码了。
5、进程调用D=malloc(100K)以后，内存空间如图5；
6、进程调用free(C)以后，C对应的虚拟内存和物理内存一起释放。
7、进程调用free(B)以后，如图7所示： B对应的虚拟内存和物理内存都没有释放，因为只有一个_edata指针，如果往回推，那么D这块内存怎么办呢？当然，B这块内存，是可以重用的，如果这个时候再来一个40K的请求，那么malloc很可能就把B这块内存返回回去了。
8、进程调用free(D)以后，如图8所示：B和D连接起来，变成一块140K的空闲内存。
9、默认情况下：当最高地址空间的空闲内存超过128K（可由M_TRIM_THRESHOLD选项调节）时，执行内存紧缩操作（trim）。在上一个步骤free的时候，发现最高地址空闲内存超过128K，于是内存紧缩，变成图9所示。
实验
在了解了内存分配原理以后来看一个现象：
1 压力测试过程中，发现被测对象性能不够理想，具体表现为：
进程的系统态CPU消耗20，用户态CPU消耗10，系统idle大约70
2 用ps -o majflt,minflt-C program命令查看，发现majflt每秒增量为0，而minflt每秒增量大于10000。
初步分析
majflt代表major fault，中文名叫大错误，minflt代表minor fault，中文名叫小错误。这两个数值表示一个进程自启动以来所发生的缺页中断的次数。当一个进程发生缺页中断的时候，进程会陷入内核态，执行以下操作：
l 检查要访问的虚拟地址是否合法
l 查找/分配一个物理页
l 填充物理页内容(读取磁盘，或者直接置0，或者啥也不干)
l 建立映射关系(虚拟地址到物理地址)
l 重新执行发生缺页中断的那条指令
l 如果第3步，需要读取磁盘，那么这次缺页中断就是majflt，否则就是minflt。
l 此进程minflt如此之高，一秒10000多次，不得不怀疑它跟进程内核态cpu消耗大有很大关系。
分析代码
查看代码，发现是这么写的：一个请求来，用malloc分配2M内存，请求结束后free这块内存。看日志，发现分配内存语句耗时10us，平均一条请求处理耗时1000us 。原因已找到!
虽然分配内存语句的耗时在一条处理请求中耗时比重不大，但是这条语句严重影响了性能。要解释清楚原因，需要先了解一下内存分配的原理。
真相大白
说完内存分配的原理，那么被测模块在内核态cpu消耗高的原因就很清楚了：每次请求来都malloc一块2M的内存，默认情况下，malloc调用mmap分配内存，请求结束的时候，调用munmap释放内存。假设每个请求需要6个物理页，那么每个请求就会产生6个缺页中断，在2000的压力下，每秒就产生了10000多次缺页中断，这些缺页中断不需要读取磁盘解决，所以叫做minflt;缺页中断在内核态执行，因此进程的内核态cpu消耗很大。缺页中断分散在整个请求的处理过程中，所以表现为分配语句耗时(10us)相对于整条请求的处理时间(1000us)比重很小。
解决办法
将动态内存改为静态分配，或者启动的时候，用malloc为每个线程分配，然后保存在threaddata里面。但是，由于这个模块的特殊性，静态分配，或者启动时候分配都不可行。另外，Linux下默认栈的大小限制是10M，如果在栈上分配几M的内存，有风险。
禁止malloc调用mmap分配内存，禁止内存紧缩。
在进程启动时候，加入以下两行代码：
mallopt(M_MMAP_MAX,0); // 禁止malloc调用mmap分配内存
mallopt(M_TRIM_THRESHOLD,-1); // 禁止内存紧缩
效果：加入这两行代码以后，用ps命令观察，压力稳定以后，majlt和minflt都为0。进程的系统态cpu从20降到10。
小结
可以用命令ps -o majfltminflt -C program来查看进程的majflt, minflt的值，这两个值都是累加值，从进程启动开始累加。在对高性能要求的程序做压力测试的时候，我们可以多关注一下这两个值。
如果一个进程使用了mmap将很大的数据文件映射到进程的虚拟地址空间，我们需要重点关注majflt的值，因为相比minflt，majflt对于性能的损害是致命的，随机读一次磁盘的耗时数量级在几个毫秒，而minflt只有在大量的时候才会对性能产生影响。
其他内存申请管理算法实现
Glibc中使用的malloc并不是唯一可用的内存管理方法。Bionic的dlmalloc, google 的Tcmalloc还有被普遍认为最强的jemalloc。jemalloc的核心思想是将内存池分为3级，每个线程都有自己的内存池，向上有一些large的内存池，最上是huge内存池。而tcmalloc管理的是一系列内存池，每个线程会发展出与某个内存池的亲和度。所以jemalloc适合线程数比较固定的场合，而tcmalloc适合线程数变动比较大的场合。
版权声明：本文为博主原创文章，未经博主允许不得转载。