容易被误读的iostat

iostat(1)是在Linux系统上查看I/O性能最基本的工具,然而对于那些熟悉其它UNIX系统的人来说它是很容易被误读的。比如在HP-UX上 avserv(相当于Linux上的 svctm)是最重要的I/O指标,反映了硬盘设备的性能,它是指I/O请求从SCSI层发出、到I/O完成之后返回SCSI层所消耗的时间,不包括在SCSI队列中的等待时间,所以avserv体现了硬盘设备处理I/O的速度,又被称为disk service time,如果avserv很大,那么肯定是硬件出问题了。然而Linux上svctm的含义截然不同,事实上在iostat(1)和sar(1)的man page上都说了不要相信svctm,该指标将被废弃:
“Warning! Do not trust this field any more. This field will be removed in a future sysstat version.”

在Linux上,每个I/O的平均耗时是用await表示的,但它不能反映硬盘设备的性能,因为await不仅包括硬盘设备处理I/O的时间,还包括了在队列中等待的时间。I/O请求在队列中的时候尚未发送给硬盘设备,即队列中的等待时间不是硬盘设备消耗的,所以说await体现不了硬盘设备的速度,内核的问题比如I/O调度器什么的也有可能导致await变大。那么有没有哪个指标可以衡量硬盘设备的性能呢?非常遗憾的是,iostat(1)和sar(1)都没有,这是因为它们所依赖的/proc/diskstats不提供这项数据。要真正理解iostat的输出结果,应该从理解/proc/diskstats开始。

/proc/diskstats有11个字段,以下内核文档解释了它们的含义https://www.kernel.org/doc/Documentation/iostats.txt,我重新表述了一下,注意除了字段#9之外都是累计值,从系统启动之后一直累加:

  1. (rd_ios)读操作的次数。
  2. (rd_merges)合并读操作的次数。如果两个读操作读取相邻的数据块时,可以被合并成一个,以提高效率。合并的操作通常是I/O scheduler(也叫elevator)负责的。
  3. (rd_sectors)读取的扇区数量。
  4. (rd_ticks)读操作消耗的时间(以毫秒为单位)。每个读操作从__make_request()开始计时,到end_that_request_last()为止,包括了在队列中等待的时间。
  5. (wr_ios)写操作的次数。
  6. (wr_merges)合并写操作的次数。
  7. (wr_sectors)写入的扇区数量。
  8. (wr_ticks)写操作消耗的时间(以毫秒为单位)。
  9. (in_flight)当前未完成的I/O数量。在I/O请求进入队列时该值加1,在I/O结束时该值减1。
    注意:是I/O请求进入队列时,而不是提交给硬盘设备时。
  10. (io_ticks)该设备用于处理I/O的自然时间(wall-clock time)。
    请注意io_ticks与rd_ticks(字段#4)和wr_ticks(字段#8)的区别,rd_ticks和wr_ticks是把每一个I/O所消耗的时间累加在一起,因为硬盘设备通常可以并行处理多个I/O,所以rd_ticks和wr_ticks往往会比自然时间大。而io_ticks表示该设备有I/O(即非空闲)的时间,不考虑I/O有多少,只考虑有没有。在实际计算时,字段#9(in_flight)不为零的时候io_ticks保持计时,字段#9(in_flight)为零的时候io_ticks停止计时。
  11. (time_in_queue)对字段#10(io_ticks)的加权值。字段#10(io_ticks)是自然时间,不考虑当前有几个I/O,而time_in_queue是用当前的I/O数量(即字段#9 in-flight)乘以自然时间。虽然该字段的名称是time_in_queue,但并不真的只是在队列中的时间,其中还包含了硬盘处理I/O的时间。iostat在计算avgqu-sz时会用到这个字段。

iostat(1)是以/proc/diskstats为基础计算出来的,因为/proc/diskstats并未把队列等待时间和硬盘处理时间分开,所以凡是以它为基础的工具都不可能分别提供disk service time以及与queue有关的值。
注:下面的公式中“Δ”表示两次取样之间的差值,“Δt”表示采样周期。

  • tps:每秒I/O次数=[(Δrd_ios+Δwr_ios)/Δt]
    • r/s:每秒读操作的次数=[Δrd_ios/Δt]
    • w/s:每秒写操作的次数=[Δwr_ios/Δt]
  • rkB/s:每秒读取的千字节数=[Δrd_sectors/Δt]*[512/1024]
  • wkB/s:每秒写入的千字节数=[Δwr_sectors/Δt]*[512/1024]
  • rrqm/s:每秒合并读操作的次数=[Δrd_merges/Δt]
  • wrqm/s:每秒合并写操作的次数=[Δwr_merges/Δt]
  • avgrq-sz:每个I/O的平均扇区数=[Δrd_sectors+Δwr_sectors]/[Δrd_ios+Δwr_ios]
  • avgqu-sz:平均未完成的I/O请求数量=[Δtime_in_queue/Δt]
    (手册上说是队列里的平均I/O请求数量,更恰当的理解应该是平均未完成的I/O请求数量。)
  • await:每个I/O平均所需的时间=[Δrd_ticks+Δwr_ticks]/[Δrd_ios+Δwr_ios]
    (不仅包括硬盘设备处理I/O的时间,还包括了在kernel队列中等待的时间。)

    • r_await:每个读操作平均所需的时间=[Δrd_ticks/Δrd_ios]
      不仅包括硬盘设备读操作的时间,还包括了在kernel队列中等待的时间。
    • w_await:每个写操作平均所需的时间=[Δwr_ticks/Δwr_ios]
      不仅包括硬盘设备写操作的时间,还包括了在kernel队列中等待的时间。
  • %util:该硬盘设备的繁忙比率=[Δio_ticks/Δt]
    表示该设备有I/O(即非空闲)的时间比率,不考虑I/O有多少,只考虑有没有。
  • svctm:已被废弃的指标,没什么意义,svctm=[util/tput]

对iostat(1)的恰当解读有助于正确地分析问题,我们结合实际案例进一步讨论。

关于rrqm/s和wrqm/s

前面讲过,如果两个I/O操作发生在相邻的数据块时,它们可以被合并成一个,以提高效率,合并的操作通常是I/O scheduler(也叫elevator)负责的。

以下案例对许多硬盘设备执行同样的压力测试,结果惟有sdb比其它硬盘都更快一些,可是硬盘型号都一样,为什么sdb的表现不一样?

img_1781

可以看到其它硬盘的rrqm/s都为0,而sdb不是,就是说发生了I/O合并,所以效率更高,r/s和rMB/s都更高,我们知道I/O合并是内核的I/O scheduler(elevator)负责的,于是检查了sdb的/sys/block/sdb/queue/scheduler,发现它与别的硬盘用了不同的I/O scheduler,所以表现也不一样。

%util与硬盘设备饱和度

%util表示该设备有I/O(即非空闲)的时间比率,不考虑I/O有多少,只考虑有没有。由于现代硬盘设备都有并行处理多个I/O请求的能力,所以%util即使达到100%也不意味着设备饱和了。举个简化的例子:某硬盘处理单个I/O需要0.1秒,有能力同时处理10个I/O请求,那么当10个I/O请求依次顺序提交的时候,需要1秒才能全部完成,在1秒的采样周期里%util达到100%;而如果10个I/O请求一次性提交的话,0.1秒就全部完成,在1秒的采样周期里%util只有10%。可见,即使%util高达100%,硬盘也仍然有可能还有余力处理更多的I/O请求,即没有达到饱和状态。那么iostat(1)有没有哪个指标可以衡量硬盘设备的饱和程度呢?很遗憾,没有。

await多大才算有问题

await是单个I/O所消耗的时间,包括硬盘设备处理I/O的时间和I/O请求在kernel队列中等待的时间,正常情况下队列等待时间可以忽略不计,姑且把await当作衡量硬盘速度的指标吧,那么多大算是正常呢?
对于SSD,从0.0x毫秒到1.x毫秒不等,具体看产品手册;
对于机械硬盘,可以参考以下文档中的计算方法:
http://cseweb.ucsd.edu/classes/wi01/cse102/sol2.pdf
大致来说一万转的机械硬盘是8.38毫秒,包括寻道时间、旋转延迟、传输时间。

在实践中,要根据应用场景来判断await是否正常,如果I/O模式很随机、I/O负载比较高,会导致磁头乱跑,寻道时间长,那么相应地await要估算得大一些;如果I/O模式是顺序读写,只有单一进程产生I/O负载,那么寻道时间和旋转延迟都可以忽略不计,主要考虑传输时间,相应地await就应该很小,甚至不到1毫秒。在以下实例中,await是7.50毫秒,似乎并不大,但考虑到这是一个dd测试,属于顺序读操作,而且只有单一任务在该硬盘上,这里的await应该不到1毫秒才算正常:

对磁盘阵列来说,因为有硬件缓存,写操作不等落盘就算完成,所以写操作的service time大大加快了,如果磁盘阵列的写操作不在一两个毫秒以内就算慢的了;读操作则未必,不在缓存中的数据仍然需要读取物理硬盘,单个小数据块的读取速度跟单盘差不多。

disk 100% busy,谁造成的?

iostat等命令看到的是系统级的统计,比如下例中我们看到/dev/sdb很忙,如果要追查是哪个进程导致的I/O繁忙,应该怎么办?

进程的内核数据结构中包含了I/O数量的统计:

可以直接在 /proc/<pid>/io 中看到:

我们关心的是实际发生的物理I/O,从上面的注释可知,应该关注 read_bytes 和 write_bytes。请注意这都是历史累计值,从进程开始执行之初就一直累加。如果要观察动态变化情况,可以使用 pidstat 命令,它就是利用了/proc/<pid>/io 中的原始数据计算单位时间内的增量:

另外还有一个常用的命令 iotop 也可以观察进程的动态I/O:

pidstat 和 iotop 也有不足之处,它们无法具体到某个硬盘设备,如果系统中有很多硬盘设备,都在忙,而我们只想看某一个特定的硬盘的I/O来自哪些进程,这两个命令就帮不上忙了。怎么办呢?可以用上万能工具SystemTap。比如:我们希望找出访问/dev/sdb的进程,可以用下列脚本,它的原理是对submit_bio下探针:

这个脚本需要在命令行参数中指定需要监控的硬盘设备号,得到这个设备号的方法如下:

执行脚本,我们看到:

结果很令人满意,我们看到是进程号为31202的dd命令在对/dev/sdb进行读操作。

日志文件系统是怎样工作的

文件系统要解决的一个关键问题是怎样防止掉电或系统崩溃造成数据损坏,在此类意外事件中,导致文件系统损坏的根本原因在于写文件不是原子操作,因为写文件涉及的不仅仅是用户数据,还涉及元数据(metadata)包括 Superblock、inode bitmap、inode、data block bitmap等,所以写操作无法一步完成,如果其中任何一个步骤被打断,就会造成数据的不一致或损坏。举一个简化的例子,我们对一个文件进行写操作,要涉及以下步骤:

  1. 从data block bitmap中分配一个数据块;
  2. 在inode中添加指向数据块的指针;
  3. 把用户数据写入数据块。
  • 如果步骤2完成了,3未完成,结果是数据损坏,因为该文件认为数据块是自己的,但里面的数据其实是垃圾;
  • 如果步骤2完成了,1未完成,结果是元数据不一致,因为该文件已经把数据块据为己有,然而文件系统却还认为该数据块未分配、随后又可能会把该数据块分配给别的文件、造成数据覆盖;
  • 如果步骤1完成了、2未完成,结果就是文件系统分配了一个数据块,但是没有任何文件用到这个数据块,造成空间浪费;
  • 如果步骤3完成了,2未完成,结果就是用户数据写入了硬盘数据块中,但白写了,因为文件不知道这个数据块是自己的。

日志文件系统(Journal File System)就是为解决上述问题而诞生的。它的原理是在进行写操作之前,把即将进行的各个步骤(称为transaction)事先记录下来,保存在文件系统上单独开辟的一块空间上,这就是所谓的日志(journal),也被称为write-ahead logging,日志保存成功之后才进行真正的写操作、把文件系统的元数据和用户数据写进硬盘(称为checkpoint),这样万一写操作的过程中掉电,下次挂载文件系统之前把保存好的日志重新执行一遍就行了(术语叫做replay),避免了前述的数据损坏场景。

有人问如果保存日志的过程中掉电怎么办?最初始的想法是把一条日志的数据一次性写入硬盘,相当于一个原子操作,然而这并不可行,因为硬盘通常以512字节为单位进行操作,日志数据一超过512字节就不可能一次性写入了。所以实际上是这么做的:给每一条日志设置一个结束符,只有在日志写入成功之后才写结束符,如果一条日志没有对应的结束符就会被视为无效日志,直接丢弃,这样就保证了日志里的数据是完整的。

一条日志在它对应的写操作完成之后就没用了,占用的硬盘空间就可以释放。保存日志的硬盘空间大小是有限的,被循环使用,所以日志也被称为circular log。

至此可以总结一下日志文件系统的工作步骤了:

  1. Journal write : 把transaction写入日志中;
  2. Journal commit : 在一条日志保存好之后,写入结束符;
  3. Checkpoint : 进行真正的写操作,把元数据(metadata)和用户数据(user data)写入文件系统;
  4. Free : 回收日志占用的硬盘空间。

以上方式把用户数据(user data)也记录在日志中,称为Data Journaling,Linux EXT3文件系统就支持这种方式,这种方式存在效率问题:就是每一个写操作涉及的元数据(metadata)和用户数据(user data)实际上都要在硬盘上写两次,一次写在日志里,一次写在文件系统上。元数据倒也罢了,用户数据通常比较大,拷贝几个GB的电影文件也要乘以2实在是降低了效率。

一个更高效的方式是Metadata Journaling,不把用户数据(user data)记录在日志中,它防止数据损坏的方法是先写入用户数据(user data)、再写日志,即在上述”Journal write”之前先写用户数据,这样就保证了只要日志是有效的,那么它对应的用户数据也是有效的,一旦发生掉电故障,最坏的结果也就是最后一条日志没记完,那么对应的用户数据也会丢,效果与Data Journaling丢弃日志一样,重要的是文件系统的一致性和完整性是有保证的。Metadata Journaling又叫Ordered Journaling,大多数文件系统都采用这种方式。像Linux EXT3文件系统也是可以选择Data Journaling还是Ordered Journaling的。

参考资料:
Crash Consistency: FSCK and Journaling

理解Linux的memory overcommit

Memory Overcommit的意思是操作系统承诺给进程的内存大小超过了实际可用的内存。一个保守的操作系统不会允许memory overcommit,有多少就分配多少,再申请就没有了,这其实有些浪费内存,因为进程实际使用到的内存往往比申请的内存要少,比如某个进程malloc()了200MB内存,但实际上只用到了100MB,按照UNIX/Linux的算法,物理内存页的分配发生在使用的瞬间,而不是在申请的瞬间,也就是说未用到的100MB内存根本就没有分配,这100MB内存就闲置了。下面这个概念很重要,是理解memory overcommit的关键:commit(或overcommit)针对的是内存申请,内存申请不等于内存分配,内存只在实际用到的时候才分配。

Linux是允许memory overcommit的,只要你来申请内存我就给你,寄希望于进程实际上用不到那么多内存,但万一用到那么多了呢?那就会发生类似“银行挤兑”的危机,现金(内存)不足了。Linux设计了一个OOM killer机制(OOM = out-of-memory)来处理这种危机:挑选一个进程出来杀死,以腾出部分内存,如果还不够就继续杀…也可通过设置内核参数 vm.panic_on_oom 使得发生OOM时自动重启系统。这都是有风险的机制,重启有可能造成业务中断,杀死进程也有可能导致业务中断,我自己的这个小网站就碰到过这种问题,参见前文。所以Linux 2.6之后允许通过内核参数 vm.overcommit_memory 禁止memory overcommit。

内核参数 vm.overcommit_memory 接受三种取值:

  • 0 – Heuristic overcommit handling. 这是缺省值,它允许overcommit,但过于明目张胆的overcommit会被拒绝,比如malloc一次性申请的内存大小就超过了系统总内存。Heuristic的意思是“试探式的”,内核利用某种算法(对该算法的详细解释请看文末)猜测你的内存申请是否合理,它认为不合理就会拒绝overcommit。
  • 1 – Always overcommit. 允许overcommit,对内存申请来者不拒。
  • 2 – Don’t overcommit. 禁止overcommit。

关于禁止overcommit (vm.overcommit_memory=2) ,需要知道的是,怎样才算是overcommit呢?kernel设有一个阈值,申请的内存总数超过这个阈值就算overcommit,在/proc/meminfo中可以看到这个阈值的大小:

CommitLimit 就是overcommit的阈值,申请的内存总数超过CommitLimit的话就算是overcommit。
这个阈值是如何计算出来的呢?它既不是物理内存的大小,也不是free memory的大小,它是通过内核参数vm.overcommit_ratio或vm.overcommit_kbytes间接设置的,公式如下:
【CommitLimit = (Physical RAM * vm.overcommit_ratio / 100) + Swap】

注:
vm.overcommit_ratio 是内核参数,缺省值是50,表示物理内存的50%。如果你不想使用比率,也可以直接指定内存的字节数大小,通过另一个内核参数 vm.overcommit_kbytes 即可;
如果使用了huge pages,那么需要从物理内存中减去,公式变成:
CommitLimit = ([total RAM] – [total huge TLB RAM]) * vm.overcommit_ratio / 100 + swap
参见https://access.redhat.com/solutions/665023

/proc/meminfo中的 Committed_AS 表示所有进程已经申请的内存总大小,(注意是已经申请的,不是已经分配的),如果 Committed_AS 超过 CommitLimit 就表示发生了 overcommit,超出越多表示 overcommit 越严重。Committed_AS 的含义换一种说法就是,如果要绝对保证不发生OOM (out of memory) 需要多少物理内存。

“sar -r”是查看内存使用状况的常用工具,它的输出结果中有两个与overcommit有关,kbcommit 和 %commit:
kbcommit对应/proc/meminfo中的 Committed_AS;
%commit的计算公式并没有采用 CommitLimit作分母,而是Committed_AS/(MemTotal+SwapTotal),意思是_内存申请_占_物理内存与交换区之和_的百分比。

附:对Heuristic overcommit算法的解释

内核参数 vm.overcommit_memory 的值0,1,2对应的源代码如下,其中heuristic overcommit对应的是OVERCOMMIT_GUESS:

Heuristic overcommit算法在以下函数中实现,基本上可以这么理解:
单次申请的内存大小不能超过 【free memory + free swap + pagecache的大小 + SLAB中可回收的部分】,否则本次申请就会失败。

 

参考:
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://www.win.tue.nl/~aeb/linux/lk/lk-9.html
https://www.kernel.org/doc/Documentation/sysctl/vm.txt
http://lwn.net/Articles/28345/

解读vmstat中的active/inactive memory

vmstat -a 命令能看到active memory 和 inactive memory:

但它们的含义在manpage中只给了简单的说明,并未详细解释:

inact: the amount of inactive memory. (-a option)
active: the amount of active memory. (-a option)

在此我们试图准确理解它的含义。通过阅读vmstat的源代码(vmstat.c和proc/sysinfo.c)得知,vmstat命令是直接从/proc/meminfo中获取的数据:

而/proc/meminfo的数据是在以下内核函数中生成的:

这段代码的意思是统计所有的LRU list,其中Active Memory等于ACTIVE_ANON与ACTIVE_FILE之和,Inactive Memory等于INACTIVE_ANON与INACTIVE_FILE之和。

LRU list是Linux kernel的内存页面回收算法(Page Frame Reclaiming Algorithm)所使用的数据结构,LRU是Least Recently Used的缩写词。这个算法的核心思想是:回收的页面应该是最近使用得最少的,为了实现这个目标,最理想的情况是每个页面都有一个年龄项,用于记录最近一次访问页面的时间,可惜x86 CPU硬件并不支持这个特性,x86 CPU只能做到在访问页面时设置一个标志位Access Bit,无法记录时间,所以Linux Kernel使用了一个折衷的方法:它采用了LRU list列表,把刚访问过的页面放在列首,越接近列尾的就是越长时间未访问过的页面,这样,虽然不能记录访问时间,但利用页面在LRU list中的相对位置也可以轻松找到年龄最长的页面。Linux kernel设计了两种LRU list: active list 和 inactive list, 刚访问过的页面放进active list,长时间未访问过的页面放进inactive list,这样从inactive list回收页面就变得简单了。内核线程kswapd会周期性地把active list中符合条件的页面移到inactive list中,这项转移工作是由refill_inactive_zone()完成的。

LRU_listLRU list 示意图

vmstat看到的active/inactive memory就分别是active list和inactive list中的内存大小。如果inactive list很大,表明在必要时可以回收的页面很多;而如果inactive list很小,说明可以回收的页面不多。

Active/inactive memory是针对用户进程所占用的内存而言的,内核占用的内存(包括slab)不在其中。

至于在源代码中看到的ACTIVE_ANON和ACTIVE_FILE,分别表示anonymous pages和file-backed pages。用户进程的内存页分为两种:与文件关联的内存(比如程序文件、数据文件所对应的内存页)和与文件无关的内存(比如进程的堆栈,用malloc申请的内存),前者称为file-backed pages,后者称为anonymous pages。File-backed pages在发生换页(page-in或page-out)时,是从它对应的文件读入或写出;anonymous pages在发生换页时,是对交换区进行读/写操作。

解读dmesg中的内存初始化信息

Linux kernel在引导过程中会在dmesg中报告如下的内存初始化信息,其实此时引导过程并未完成,initrd和init所占的内存尚未释放,最终kernel可用的内存比dmesg报告的available内存还会更多一点。

要理解以上信息的含义,还是看源代码吧,这条信息是在 mem_init() 函数中输出的:

以上代码中,free_all_bootmem()需要详细解释:在内核引导的初始阶段,buddy allocator和slab allocator等内存管理机制尚未就绪,所以使用的是bootmem allocator,到运行mem_init()的时候,bootmem的历史任务已经完成,所以调用free_all_bootmem()把它管理的内存中未分配的部分全都释放掉。

absent_pages_in_range()用于统计物理内存中对kernel不可用的部分,因为有一些物理内存是被BIOS保留的,kernel用不了。

在全部物理内存中,除掉bootmem释放出来的空闲内存和kernel无法使用的absent内存,剩下的就是在kernel引导过程中已经分配掉的内存,称为reserved内存。Reserved内存主要包括initrd、初始化代码init、内核代码及数据(内核数据是动态变化的,这里所说的是引导阶段截至mem_init为止所产生的数据,包括存放页描述符struct page的mem_map[]数组等)。
注:initrd和初始化代码init在引导完成之后会被释放掉,所以最终的可用内存会比dmesg显示的available更多一点,相应的源代码可参见:
arch/x86/mm/init.c: free_initrd_mem() 和 free_initmem()。
在dmesg中可以看到释放时输出的日志,注意看init的大小:

正因如此,最终用”free”命令看到的total memory比dmesg里看到的available memory更多,以本系统为例,”free”命令看到的total 3809036k,比dmesg看到的available memory 3789320k更多,(3809036k – 3789320k) = (24k + 18088k + 1604k):

注:关于reserved memory的更多详情可参见链接中的表1:
http://www.tldp.org/LDP/khg/HyperNews/get/memory/linuxmm.html

所以内存初始化信息的解读如下:

  • 3789320k/4915200k available
    分母4915200k表示物理内存的大小,
    分子3789320k表示可供kernel分配的 free memory的大小;
  • 795332k absent
    表示不可用的物理内存大小。譬如有一些物理内存被BIOS保留、对kernel是不可用的,这部分物理内存被计入”absent”之中。
  • 330548k reserved
    包括【initrd】和【内核代码及数据】等,详见上面的解释。其中内核代码和部分数据包含在下列统计值中:

    • 6243k kernel code :
      表示kernel的代码,属于reserved memory;
    • 4180k data :
      表示kernel的数据,属于reserved memory;
    • 1604k init :
      表示init code和init data,属于reserved memory,但引导完成之后会释放给free memory。

它们之间的关系如下:

  • available = 物理内存 – absent – reserved
  • reserved 包括 kernel code, data 和 init,由于它还包括initrd和其它更多的内容,所以reserved远远大于 kernel code + data + init 之和。

参考资料:
http://winfred-lu.blogspot.com/2011/03/linux-boot-memory-allocator-mips.html

怎样统计所有进程总共占用多少内存?

很多人通过累加 “ps  aux” 命令显示的 RSS 列来统计全部进程总共占用的物理内存大小,这是不对的。RSS(resident set size)表示常驻内存的大小,但是由于不同的进程之间会共享内存,所以把所有进程RSS进行累加的方法会重复计算共享内存,得到的结果是偏大的。

正确的方法是累加 /proc/[1-9]*/smaps 中的 Pss 。/proc/<pid>/smaps 包含了进程的每一个内存映射的统计值,详见proc(5)的手册页。Pss(Proportional Set Size)把共享内存的Rss进行了平均分摊,比如某一块100MB的内存被10个进程共享,那么每个进程就摊到10MB。这样,累加Pss就不会导致共享内存被重复计算了。

命令如下:
$ grep Pss /proc/[1-9]*/smaps | awk ‘{total+=$2}; END {print total}’

需要注意的是,全部进程占用的内存并不等于 free 命令所显示的 “used memory”,因为“used memory”不仅包含了进程所占用的内存,还包含cache/buffer以及kernel动态分配的内存等等。

有人提出【MemTotal = MemFree + buff/cache + slab + 全部进程占用的内存】。这是不对的,原因之一是:进程占用的内存包含了一部分page cache,换句话说,就是进程占用的内存与page cache发生了重叠。比如进程的mmap文件映射同时也统计在page cache中。我们用一个实验来证明,下面的小程序调用mmap()映射了一个大文件,等我们检查内存状态之后,再读取文件使它真正进入内存,我们将最后的内存状态与之前的进行对比:

测试结果是这样的:

可以看到,page cache的大小和进程的/RssPss同时变大了,而且增加的大小也吻合,证明进程占用的内存与page cache的统计是有重叠的。

RCU CPU STALL DETECTOR

在RHEL 7 和 SELS11 SP2 之后的Linux系统上,有时会看到如下信息:

它们来自RCU CPU Stall Detector,要了解RCU CPU Stall Detector是什么,首先要知道RCU是什么。RCU(Read-Copy Update) 是Linux 2.6 内核开始引入的一种新的锁机制,与spinlock、rwlock不同,RCU有其独到之处,它只适用于读多写少的情况。

RCU是基于其原理命名的,Read-Copy Update,[Read]指的是对于被RCU保护的共享数据,reader可以直接访问,不需要获得任何锁;[Copy Update]指的是writer修改数据前首先拷贝一个副本,然后在副本上进行修改,修改完毕后向reclaimer(垃圾回收器)注册一个回调函数(callback),在适当的时机完成真正的修改操作–把原数据的指针重新指向新的被修改的数据,–这里所说的适当的时机就是当既有的reader全都退出临界区的时候,而等待恰当时机的过程被称为 grace period。在RCU机制中,writer不需要和reader竞争任何锁,只在有多个writer的情况下它们之间需要某种锁进行同步作,如果写操作频繁的话RCU的性能会严重下降,所以RCU只适用于读多写少的情况。

RCU API 最核心的函数是:
rcu_read_lock()
rcu_read_unlock()
synchronize_rcu()
call_rcu()

  • rcu_read_lock()和rcu_read_unlock()配对使用,由reader调用,用以标记reader进入/退出临界区。夹在这两个函数之间的代码区称为”读端临界区”(read-side critical section),注:读端临界区可以嵌套。reader在临界区内是不能被阻塞的。
  • synchronize_rcu()由writer调用,它会阻塞writer(即writer会进入睡眠等待),直到经过grace period后,即所有的reader都退出读端临界区,writer才可以继续下一步操作。如果有多个writer调用该函数,它们将在grace period之后全部被唤醒。
  • call_rcu()是synchronize_rcu()的非阻塞版本,它也由 writer调用,但不会阻塞writer(即writer不会进入睡眠,而是继续运行),因而可以在中断上下文或 softirq 中使用,而 synchronize_rcu()只能在进程上下文使用。call_rcu()把参数中指定的callback函数挂接到 RCU回调函数链上,然后立即返回。一旦所有的 CPU 都已经完成端临界区操作(即grace period之后),该callback函数将被调用,用writer修改过的数据副本替换原数据并释放原数据空间。需要指出的是,函数 synchronize_rcu 的实现实际上也使用了函数call_rcu()。

RCU API 有一些特殊用途的分支,比如 RCU BH (防DDoS攻击的API)、RCU Sched(适用于 scheduler 和 interrupt/NMI-handler 的 API),等。参见 http://lwn.net/Articles/264090/

RCU在Linux 2.6内核中(RHEL6和SLES11 SP1)就已经存在了,那时处理grace period利用了软中断(softirq),而到了新的3.x内核之后有所改变,处理grace period利用的是内核线程,因为内核线程可以被抢占,减少了实时任务的响应延迟。所以在3.x内核的系统上,会看到类似如下的内核线程:
[rcu_sched]
[rcu_bh]
[rcuob/0]
[rcuob/1]
[rcuos/0]
[rcuos/1]
还有可能会见到rcu_preempt线程。
注:其中 rcuob/N, rcuos/N 是负责处理 RCU callbacks 的内核线程,参见https://www.kernel.org/doc/Documentation/kernel-per-CPU-kthreads.txt

好了,现在终于可以讲 RCU CPU Stall Detector 了,它其实是RCU代码中的一个debugging feature(参见https://lwn.net/Articles/301910/ ),在2.6内核中缺省是关闭的,而到3.x内核中缺省是打开的,它有助于检测导致 grace period 过度延迟的因素,因为grace period的长短是RCU性能的重要因素。发生RCU grace period延迟会在系统日志中记录告警信息,称为RCU CPU Stall Warnings

INFO: rcu_sched_state detected stalls on CPUs/tasks: { 15} (detected by 17, t=15002 jiffies)

INFO: rcu_bh_state detected stalls on CPUs/tasks: { 3 5 } (detected by 2, 2502 jiffies)
等等。

在上述告警信息之后通常还会看到相关CPU的stack dump,检查stack trace有助于了解当时运行的代码和可能导致延迟的原因。

如果你不想看到以上告警信息,可以通过以下参数关掉它:
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress
注:缺省值为0,表示显示延迟告警;置为1表示禁止显示延迟告警。
RCU grace period延迟多长时间会触发告警呢?这是以下参数决定的(以秒为单位):
/sys/module/rcupdate/parameters/rcu_cpu_stall_timeout
RCU的其它内核参数,如rcupdate.rcu_task_stall_timeout等参见:
https://www.kernel.org/doc/Documentation/kernel-parameters.txt

有哪些原因会导致 RCU grace period延迟(RCU CPU Stall Warnings)呢?参见 https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt 这里仅列举几例:

  • CPU 在 RCU read-side 临界区内死循环
  • CPU 在屏蔽中断的情况下死循环
  • Linux引导过程中输出信息很多,但是所用的 console太慢,跟不上信息输出的速度。
  • 任何可能导致 RCU grace-period 内核线程无法运行的因素
  • 优先级很高的实时任务占着 CPU 不放,抢占了恰好处于RCU read-side临界区的低优先级任务。
  • RCU代码bug。
  • 硬件故障。.
  • 等等。

具体分析还需从告警信息中输出的stack trace入手。

参考资料:
源代码:kernel/rcupdate.c, kernel/rcutree.c …
https://www.ibm.com/developerworks/cn/linux/l-rcu/
https://www.kernel.org/doc/Documentation/RCU/stallwarn.txt
https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt
http://lwn.net/Articles/262464/
https://lwn.net/Articles/518953/

Redhat cluster 的心跳机制

Redhat cluster软件的架构分为两层:

  • 底层的cluster messaging layer(集群信息层)负责在所有节点之间传递集群信息包括心跳信息
    RHEL6及之前是CMAN,从RHEL7开始是Corosync。
  • 上层的cluster resource manager(集群资源管理器)管理划归集群所属的资源,包括IP地址、逻辑卷、文件系统等
    RHEL6及之前是RGManager,从RHEL7开始是Pacemaker。

心跳机制使用的是Totem协议,Totem是一个巨复杂的协议,心跳只是其中一个很小的部分,可以这么理解:Totem协议负责处理集群内部所有节点之间的通信问题,包含四个主要组件:Total Ordering Protocol, Membership Protocol, Recovery Protocol, Flow Control Mechanism。这里只讲与心跳有关的部分。

Totem的通信是两种方式互相配合进行的:multicast(多播)和token(令牌)。[注意multicast与broadcast(广播)不同,它相当于限定范围的广播,只有分组内的成员能收到。] 一个节点只有在持有token的时候才能发言,通过multicast给集群内所有节点发送信息,每一条multicast信息都附有顺序号,发送完成之后就把顺序号记录到token中,然后把token传给下一个节点,token的传递方式是一对一的,就像首尾相连的环形接力,从IP地址最小的节点依次传给下一个IP地址更大的节点,每个节点收到token之后,根据token里记录的顺序号检查自己是否漏收了multicast信息,如果漏收了,就在token里添加重传申请,然后把token传给下一个节点,下一个节点除了检查自己有没有漏收multicast之外,还会根据token里记录的重传申请把相应的multicast信息重新发送一次(当然前提是该节点已经收到了这条multicast信息)。

totem

集群通过两种机制检测节点的健康状态:

  • Token超时

如果token中断的时间超过了指定的期限,节点就会触发membership protocol,重组cluster,这个期限通过以下参数设置:<totem token=”XXX”/>
注:XXX以毫秒为单位。

在上述期限内,token会尝试重传,重传的次数是以下参数指定的,缺省值是4:
<totem token_retransmits_before_loss_const=”X”/>

  • Multicast retransmit(重传)超过阈值

如果某个节点能收到token,但收不到multicast,那么经过若干次token循环之后,也会触发membership protocol,重组cluster,这个次数可以通过参数 fail_recv_const 设置,缺省值是2500次。

Totem协议有4种状态,代表集群运行的不同阶段,不同的状态下运行的子协议也不同:

  • GATHER
  • COMMIT
    Gather和Commit状态出现在集群组建的阶段,可以比喻为集合、报数的过程。运行的是membership protocol。
  • RECOVERY
    Recovery状态出现在集群发生问题、进行恢复的阶段。运行的是recovery protocol。
  • OPERATIONAL
    Operational状态表示集群正常工作的阶段。运行的是Totem Ordering Protocol。

totem_status

有了这些基本概念,我们就可以大致看懂集群的日志了:

 

内核引导参数iommu与intel_iommu有何不同?

前文介绍过IOMMU是提供DMA Remapping功能的硬件模块,可以把DMA地址从虚拟地址翻译成物理地址。Linux kernel有两个引导参数(boot parameter)与iommu有关:iommu=[on/off] 和 intel_iommu=[on/off],它们有什么区别呢?答案是:参数iommu控制的是GART iommu功能,参数intel_iommu控制的是基于Intel VT-d的iommu功能。

下面的代码表明:CONFIG_IOMMU控制的是GART iommu,CONFIG_DMAR控制的是intel_iommu。(CONFIG_IOMMU对应的是引导参数iommu,CONFIG_DMAR对应的是引导参数intel_iommu,注意:CONFIG_DMAR名称中没有Intel字样,这里比较容易误导,但你看它下面对应的函数intel_iommu_init就很明显了):

 

引导参数iommu控制的是GART iommu前文介绍过GART (Graphics Address Remapping Table),最初是为了方便图形芯片直接读取内存而设计的:使用地址转译功能将收集到内存中的数据映射到一个图形芯片可以“看”到的地址。这个地址转译功能自然也可以充当IOMMU,于是GART被Linux kernel用来帮助传统的32位PCI设备访问可寻址范围之外的内存区域。GART iommu有局限性(比如仅限于显存范围内),不具备Intel IOMMU的完整功能。

“iommu”参数默认是打开的,以2.6.18 kernel为例,

注:GART iommu功能是按需激活的,并有前提条件,比如系统内存必须在3GB以上、而且只对有限的设备,参见:

引导参数intel_iommu控制的是基于Intel VT-d的iommu,该参数默认是关闭的,在config文件中对应的配置如下(注意:名称中用的是DMAR而不是iommu,不留意的话容易错过):

从以下的代码中我们看到:[默认情况]与[显式设置intel_iommu=off]的效果是一样的,结果都是”dmar_disabled=1″,所以 intel_iommu=off 设不设置其实都一样:

注:启动参数intel_iommu有点复杂的是:存在两个与DMAR有关的配置,除了上面看到的CONFIG_DMAR_DEFAULT_ON之外,另外还有一个是CONFIG_DMAR,默认是打开的:

CONFIG_DMAR告诉内核在编译时要准备好支持DMA Remapping设备(见注一);
而CONFIG_DMAR_DEFAULT_ON 是告诉内核在引导时是否激活DMAR设备。
也就是说,默认情况下(CONFIG_DMAR=y)内核已经具备了支持DMAR的功能,设置内核引导参数intel_iommu=off(等效于缺省情况:即CONFIG_DMAR_DEFAULT_ON未设置)并不是关闭内核的DMAR功能,仅仅是告诉内核在引导过程中不要把DMAR设备激活而已。
这两个配置参数的详细解释参见以下文件。

(注一)事实上更准确地说,内核不仅仅是在编译时具备了支持DMAR设备的功能,而且在引导过程中始终会根据ACPI table把DMAR设备有关的数据结构都初始化好–无论是否加了引导参数intel_iommu=off。

内核怎么知道哪些设备需要DMA Remapping呢?是通过ACPI table知道的,因为需要DMA Remapping的设备必须在firmware/BIOS中登记。以下是内核初始化DMAR的代码,可以看到无论是否dmar_disabled,都会调用dmar_table_init和dmar_dev_scope_init:

这就是为什么只要BIOS中打开了Intel VT-d,我们就总会在kernel messages中看到类似下面的初始化DMAR table的信息,无论intel_iommu参数是on还是off。

如果你想让kernel中与Intel VT-d有关的软件模块完全关闭,仅仅使用启动参数intel_iommu=off是不够的,而必须重新编译内核–在config中配置CONFIG_DMAR=n,或者用另一种方法:在BIOS中关闭Intel VT-d。