文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

内存信息

同样在分析内存之前，我们得知到怎么查看系统内存信息，有以下几种方法。

/proc/meminfo

这个文件记录着比较详细的内存配置信息，使用 cat /proc/meminfo 查看。

我们比较关心的是下面几个字段：

• MemTotal：系统总内存，由于 BIOS、内核等会占用一些内存，所以这里和配置声称的内存会有一些出入，比如我这里配置有 2G，但其实只有 1.95G 可用。
• MemFree：系统空闲内存。
• MemAvailable：应用程序可用内存。有人会比较奇怪和 MemFree 的区别，可以从两个层面来区分，MemFree 是系统层面的，而 MemAvailable 是应用程序层面的。系统中有些内存虽然被使用了但是有一部分是可以回收的，比如 Buffers、Cached 及 Slab 这些内存，这部分可以回收的内存加上 MemFree 才是 MemAvailable 的内存值，这是内核通过特定算法算出来的，是一个估算值。
• Buffers：缓冲区内存
• Cached：缓存

上面信息没有 MemUsed 的值，虽然可以用现有的值大致估算出来，但是我们想一步到位，就用下面的 free 命令。

free

这个命令估计用的人就多了（我一般都是用这个命令）。

这里存在一个计算公式：

MemTotal = used + free + buff/cache（单位 K）

几个字段和上面 /proc/meminfo 的字段是对应的。还有个 shared 字段，这个是多进程的共享内存空间，不常用。

我们注意到 free 很小，buff/cache 却很大，这是 Linux 的内存设计决定的，Linux 的想法是内存闲着反正也是闲着，不如拿出来做系统缓存和缓冲区，提高数据读写的速率。但是当系统内存不足时，buff/cache 会让出部分来，非常灵活的操作。

要看比较直观的值，可以加 -h 参数：

dmidecode

同样可以使用这个命令，对于内存，可以使用 dmidecode -t memory 查看：

vmstat

这个命令也是非常常用了。但对于内存，显示信息有限。它更多是用于进行系统全局分析和 CPU 分析。详细可以看 CPU 分析一文。

进程内存使用情况分析

最常用的两个命令 ps 和 top，虽然很简单的两个命令，但还是有不少学问的。

top/htop

top 命令运行时默认是按照 CPU 利用率进行排序的，如果要按照内存排序，该怎么操作呢？两种方法，一种直接按 “M”（相应的按 “P” 是 CPU），另外一种是在键入 top 之后，按下 “F”，然后选择要排序的字段，再按下 “s” 确认即可。

可以看到，我按照 “%MEM” 排序的结果。这个结果对于查看系统占用内存较多的哪些进程是比较有用的。

然后这里我们会重点关注几个地方，上面横排区，和前面几个命令一样可以查看系统内存信息，中间标注的横条部分，和内存相关的有三个字段：VIRT、RES、SHR。

• VIRT：virtual memory usage，进程占用的虚拟内存大小。
• RES：resident memory usage，进程常驻内存大小，也就是实际内存占用情况，一般我们看进程占用了多少内存，就是看的这个值。
• SHR：shared memory，共享内存大小，不常用。

ps

ps 同样可以查看进程占用内存情况，一般常用来查看 Top n 进程占用内存情况，如：

ps aux --sort=rss | head -n，表示按 rss 排序，取 Top n。

这里也关注三个字段：

• %MEM：进程使用物理内存所占百分比。
• VSZ：进程使用虚拟内存大小。
• RSS：进程使用物理内存大小，我们会重点关注这个值。

pmap

这个命令用于查看进程的内存映像信息，能够查看进程在哪些地方用了多少内存。常用 pmap -x pid 来查看。

可以看到该进程内存被哪些库、哪些文件所占用，据此我们定位程序对内存的使用。

几个字段介绍一下：

• Address：占用内存的文件的内存起始地址。
• Kbytes：占用内存的字节数。
• RSS：实际占用内存大小。
• Dirty：脏页大小。
• Mapping：占用内存的文件，[anon] 为已分配的内存，[stack] 为程序堆栈
• 最后的 total 为统计的总值。我们可以使用 pmap -x pid | tail -1 这样只显示最后一行，循环显示最后一行，达到监控该进程的目的。使用：
  while true; do pmap -x pid | tail -1; sleep 1; done

OK，以上工具都是 Linux 自带的，当然还有很多高阶的工具，比如 atop、memstat 等等，对于内存泄漏有一个比较常用的检测工具 Valgrind，这些等之后再找时间跟大家分享了。

通过以上手段，我们基本上就能定位内存问题所在了，究竟是内存太小，还是进程占用内存太多，有哪些进程占用较多，这些进程又究竟有哪些地方占用较多，这些问题通过以上方法都能解决。

最后简单总结下，以上不少工具可能有人会犯选择困难症了。对于我来说，查看系统内存用 free -h，分析进程内存占用用 ps 或者 top（首选 ps），深入分析选择 pmap，就酱。

Reference：
1.Linux下查看内存使用情况的多种方法：
http://stor.51cto.com/art/201804/570236.htm

PS：文章未经我允许，不得转载，否则后果自负。

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

本文的一些概念依赖于上一篇 “CPU 拓扑：从 SMP 谈到 NUMA （理论篇）”，如果你对这块还没有概念，建议看完那篇再来看，如果对这块有自己独到的见解，欢迎探讨。

本文主要会侧重 NUMA 这块，我会通过自己的环境验证 NUMA 的几个概念，以便对 NUMA 的架构有个较深的印象。

NUMA 的几个概念：Node，Socket，Core，Thread

NUMA 技术的主要思想是将 CPU 进行分组，Node 即是分组的抽象，一个 Node 表示一个分组，一个分组可以由多个 CPU 组成。每个 Node 都有自己的本地资源，包括内存、IO 等。每个 Node 之间通过互联模块（QPI）进行通信，因此每个 Node 除了可以访问自己的本地内存之外，还可以访问远端 Node 的内存，只不过性能会差一些，一般用 distance 这个抽象的概念来表示各个 Node 之间互访资源的开销。

Node 是一个逻辑上的概念，与之相对的 Socket，是物理上的概念。它表示一颗物理 CPU 的封装，是主板上的 CPU 插槽，所以，一般就称之为插槽（敲黑板，这 Y 不是套接字吗？emmm……）

Core 就是 Socket 里独立的一组程序执行单元，称之为物理核。有了物理核，自然就有逻辑核，Thread 就是逻辑核。更专业的说法应该称之为超线程。

超线程是为了进一步提高 CPU 的处理能力，Intel 提出的新型技术。它能够将一个 Core 从逻辑上划分成多个逻辑核（一般是两个），每个逻辑核有独立的寄存器和中断逻辑，但是一个 Core 上的多个逻辑核共享 Core 内的执行单元和 Cache，频繁调度可能会引起资源竞争，影响性能。超线程必须要 CPU 支持才能开启。

综上所述，一个 NUMA Node 可以有一个或者多个 Socket，每个 Socket 也可以有一个（单核）或者多个（多核）Core，一个 Core 如果打开超线程，则会变成两个逻辑核（Logical Processor，简称 Processor）。

所以，几个概念从大到小排序依次是：

Node > Socket > Core > Processor。

验证 CPU 拓扑

了解了以上基本概念，下面在实际环境中查看这些概念并验证。

Node

用 numactl --hardware 查看当前系统的 NUMA Node（numactl 是设定进程 NUMA 策略的命令行工具）：

1
2
3
4
5
6
7
8
9
10
11
12

Linux # numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 12 13 14 15 16 17
node 0 size: 49043 MB
node 0 free: 20781 MB
node 1 cpus: 6 7 8 9 10 11 18 19 20 21 22 23
node 1 size: 49152 MB
node 1 free: 31014 MB
node distances:
node   0   1 
0:  10  21 
1:  21  10

可以得出的信息有：1）系统的 Node 数为 2；2）每个 Node 包含的 Processor 数为 12；3）每个 Node 的总内存大小和空闲内存大小；4）每个 Node 之间的 distance。

还可以查看 /sys/devices/system/node/ 目录，这里记录着具体哪些 Node。

Socket

/proc/cpuinfo 中记录着 Socket 信息，用 “physical id” 表示，可以用 cat /proc/cpuinfo | grep "physical id" 查看：

1
2
3
4
5
6
7
8
9

Linux # cat /proc/cpuinfo | grep "physical id"
physical id     : 0
physical id     : 0
physical id     : 0
physical id     : 0
physical id     : 1
physical id     : 1
physical id     : 1
physical id     : 1

可以看到有 2 个 Socket，我们还可以查看以下这几种变种：

1）查看有几个 Socket

1
2
3
4

Linux # grep 'physical id' /proc/cpuinfo | awk -F: '{print $2 | "sort -un"}'

0
1

1
2
3

Linux # grep 'physical id' /proc/cpuinfo | awk -F: '{print $2 | "sort -un"}' | wc -l

2

2）查看每个 Socket 有几个 Processor

1
2
3
4

Linux # grep 'physical id' /proc/cpuinfo | awk -F: '{print $2}' | sort | uniq -c

12 0
12 1

3）查看每个 Socket 有哪几个 Processor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Linux # awk -F: '{ 
>     if ($1 ~ /processor/) {
>         gsub(/ /,"",$2);
>         p_id=$2;
>     } else if ($1 ~ /physical id/){
>         gsub(/ /,"",$2);
>         s_id=$2;
>         arr[s_id]=arr[s_id] " " p_id
>     }
> } 
> 
> END{
>     for (i in arr) 
>         print arr[i];
> }' /proc/cpuinfo | cut -c2-

0 1 2 3 4 5 12 13 14 15 16 17
6 7 8 9 10 11 18 19 20 21 22 23

Core

同样在 /proc/cpuinfo 中查看 Core 信息：

1
2
3
4
5
6
7

Linux # cat /proc/cpuinfo |grep "core id" | sort -u
core id    : 0
core id    : 1
core id    : 2
core id    : 3
core id    : 4
core id    : 5

上面的结果表明一个 Socket 有 5 个 Core。上面查到有 2 个 Socket，则一共就有 10 个 Core。

Processor

上面查看 Socket 信息时已经能够得到 Processor 的信息，总共有 24 个 Processor，不过也可以直接从 /proc/cpuinfo 中获取：

1）获取总的 Processor 数，查看 “processor” 字段：

1
2
3

Linux # cat /proc/cpuinfo | grep "processor" | wc -l

24

2）获取每个 Socket 的 Processor 数，查看 “siblings” 字段：

1
2
3

Linux # cat /proc/cpuinfo | grep "siblings" | sort -u

12

Cache

Cache 也一样通过 /proc/cpuinfo 查看：

1
2
3
4
5

processor  : 0

cache size  : 15360 KB

cache_alignment  : 64

不过这里的值 cache size 比较粗略，我们并不知道这个值是哪一级的 Cache 值（L1？L2？L3？），这种方法不能确定，我们换一种方法。

其实详细的 Cache 信息可以通过 sysfs 查看，如下：

比如查看 cpu0 的 cache 情况：

1
2
3

Linux # ls /sys/devices/system/cpu/cpu0/cache/

index0/  index1/  index2/  index3/

其中包含四个目录：
index0 存 L1 数据 Cache，index1 存 L1 指令 Cache，index2 存 L2 Cache，index3 存 L3 Cache。每个目录里面包含一堆描述 Cache 信息的文件。我们选 index0 具体看下：

其中，shared_cpu_list 和 shared_cpu_map 表示意思是一样的，都表示该 cache 被哪几个 processor 共享。对 shared_cpu_map 具体解释一下。

这个值表面上看是二进制，但其实是 16 进制，每个数字有 4 个bit，代表 4 个 cpu。比如上面的 001001 拆开后是：

1

0000 0000 0001 0000 0000 0001，1 bit 处即对应 cpu 标号，即 cpu0 和 cpu12。

同样我们可以对其他 index 进行统计，可以得出：
/proc/cpuinfo 中的 cache size 对应的 L3 Cache size。

最后，综合以上所有信息我们可以绘制出一下的 CPU 拓扑图：

我们发现以上命令用得不太顺手，要获取多个数据需要输入多条命令，能不能一条命令就搞定，当然是有的，lscpu 就可以做到，如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Linux # lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                24   //共有24个逻辑CPU（threads）
On-line CPU(s) list:   0-23
Thread(s) per core:    2   //每个 Core 有 2 个 Threads
Core(s) per socket:    12  //每个 Socket 有 12 个 Threads
Socket(s):             2  //共有 2 个 Sockets
NUMA node(s):          2  //共有 2 个 Nodes
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Stepping:              2
CPU MHz:               2401.000
BogoMIPS:             4803.16
Virtualization:        VT-x
L1d cache:             32K  //L1 data cache 32k
L1 cache:             32K   //L1 instruction cache 32k  
L2 cache:              256K //L2 instruction cache 256k
L3 cache:              15360K //L3 instruction cache 15M
NUMA node0 CPU(s):     0-5,12-17
NUMA node1 CPU(s):     6-11,18-23

当然了，没有完美的命令，lscpu 也只能显示一些宽泛的信息，只是相对比较全面而已，更详细的信息，比如 Core 和 Cache 信息就得借助 cpuinfo 和 sysfs 了。

下面给大家提供一个脚本，能够比较直观的显示以上所有信息，有 shell 版的和 python 版的（不是我写的，文末附上了引用出处）。

大家有需要可以回复 “CPU” 获取，我就不贴出来了，显示的结果大概就是长下面这个样子：

python 版：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

============================================================
Core and Socket Information (as reported by '/proc/cpuinfo')
============================================================

cores =  [0, 1, 2, 3, 4, 5]

sockets =  [0, 1]


Socket 0        Socket 1        

--------        --------        

Core 0 [0, 12]         [6, 18]         

Core 1 [1, 13]         [7, 19]         

Core 2 [2, 14]         [8, 20]         

Core 3 [3, 15]         [9, 21]         

Core 4 [4, 16]         [10, 22]        

Core 5 [5, 17]         [11, 23]

Reference：

1. 玩转 CPU 拓扑：
   http://blog.itpub.net/645199/viewspace-1421876/
2. NUMA 体系结构详解
   https://blog.csdn.net/ustc_dylan/article/details/45667227（shell 代码引用）
3. dpdk 源代码（python 代码引用）

PS：文章未经我允许，不得转载，否则后果自负。

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

随着计算机技术（特别是以芯片为主的硬件技术）的快速发展，CPU 架构逐步从以前的单核时代进阶到如今的多核时代，在多核时代里，多颗 CPU 核心构成了一个小型的“微观世界”。每颗 CPU 各司其职，并与其他 CPU 交互，共同支撑起了一个“物理世界”。从这个意义上来看，我们更愿意称这样的“微观世界”为 CPU 拓扑，就像一个物理网络一样，各个网络节点通过拓扑关系建立起连接来支撑起整个通信系统。

单核 or 多核 or 多 CPU or 超线程 ?

在单核时代，为了提升 CPU 的处理能力，普遍的做法是提高 CPU 的主频率，但一味地提高频率对于 CPU 的功耗也是影响很大的（CPU 的功耗正比于主频的三次方）。

另外一种做法是提高 IPC （每个时钟周期内执行的指令条数），这种做法要么是提高指令的并行度，要么是增加核数。显然，后一种方法更具有可扩展性，这也是摩尔定律的必然性。

CPU 的性能到底是如何体现的呢？为了弄清楚这个问题，我们结合单核 CPU 和多核 CPU 的结构来进一步剖析。

首先，对于一个单核结构，即一颗物理 CPU 封装里只集成了一个物理核心，其主要组件可以简化为：CPU 寄存器集合、中断逻辑、执行单元和 Cache，如下图：

对于一个多线程程序，主要通过时间片轮转的方式来获得 CPU 的执行权，从内部来看，这其实是串行执行的，性能自然并不怎么高。

其次，对于多核结构，则是在一颗物理 CPU 封装里集成了多个对等的物理核心，所谓对等，就是每个核心都有相同的内部结构。多个核心之间通过芯片内部总线来完成通信。随着 CPU 制造工艺的提升，每颗 CPU 封装中集成的物理核心也在不断提高。

对于一个多线程程序，这种情况能够实现真正的并发，但线程在不同核之间切换会存在一定的开销，但由于走的是芯片内部总线，开销相对会比较小。

除了上述两种结构，还有另外一种结构是多 CPU 结构，也就是多颗单独封装的 CPU 通过外部总线相连，构成的一个统一的计算平台。每个 CPU 都需要独立的电路支持，有自己的 Cache。它们之间的通信通过主板上的总线来完成。

同样对于一个多线程程序，不同于上一种情况的是，线程间的切换走的是外部总线，延迟较大，开销自然较大，而且对于有共享的数据还会因 Cache 一致性带来一定的开销（关于 Cache 下一小节说明）。

上述结构，一个 CPU 核心同一时间内只能执行一个线程，效率低下，为了提高 CPU 的利用率，CPU 芯片厂商又推出超线程（Hyper-Thread-ing）技术，即让一个物理核心同时执行多个线程，使整体性能得到提升。虽然物理上只有一个核心，但逻辑上被划分了多个逻辑核心，它们之间是完全隔离的。

对于每个逻辑核心，拥有完整独立的寄存器集合和中断逻辑，共享执行单元和 Cache。由于是共享执行单元，所以对高 IPC 的应用，其性能提升有限。

Cache

Cache 是一种 SRAM （Static Random Access Memory，静态访问随机存储器）。出于成本和生产工艺考虑，一般将 Cache 分为三级。一级（L1）访问速度最快，但是容量最小，一般只有几十 KB；二级（L2）次之，一般有几百 KB 到几 MB 不等，三级（LLC，Last Level Cache）最慢，但是容量也最大，一般有几 MB 到几十 MB。

一级 Cache 又分为数据 Cache 和指令 Cache，顾名思义，数据 Cache 用来存数据，指令 Cache 用来存指令。下图是一个简单的 Cache 系统逻辑示意图。

在多核结构中，每个物理核心都拥有独立的一级 Cache 和二级 Cache，而三级 Cache 是所有核心共享。这种共享需要解决的一个问题是公平地为每个核心分配 Cache 大小，避免 Cache 命中率低的问题。

对于现代计算机系统，说到 Cache，不得不提 TLB（Translation Look-aside Buffer） Cache。简单理解，如果说 Cache 存放的是内存中的内容，那么 TLB Cache 存放的是页表项。

为什么页表项需要用 Cache 存，原因当然是快。你可能觉得用三级 Cache 存就行了，为什么还要专门上 TLB Cache。

这里有两点考虑，一点是 TLB 采用基于内容的访问存储器 CAM，这种存储器能做到根据虚拟地址查询直接返回物理地址，效率极高，不需要像传统方式那样采用多级页表查询。另外一点是 Cache 的“淘汰”机制决定，Cache 会根据算法淘汰掉那些不常使用的内容，这对于页表这种需要频繁访问（每次程序寻址都要访问页表）的特性显然是矛盾的，所以就需要专门为页表提供一种特殊的 Cache，即 TLB Cache。

SMP or NUMA or MPP?

如果说前面咱们讨论的是 CPU 内部的“微观世界”，那么本节将跳出来，探讨一个系统级的“宏观世界”。

首先是 SMP，对称多处理器系统，指的是一种多个 CPU 处理器共享资源的电脑硬件架构，其中，每个 CPU 没有主从之分，地位平等，它们共享相同的物理资源，包括总线、内存、IO、操作系统等。每个 CPU 访问内存所用时间都是相同的，因此这种系统也被称为一致存储访问结构（UMA，Uniform Memory Access）。

这种系统由于共享资源，不可避免地要加锁来解决资源竞争的问题，带来一定的性能开销，另外，扩展能力还非常有限，实验证明，SMP 系统最好的情况是有 2-4 个 CPU，适用于 PC、笔记本电脑和小型服务器等。

tips: 查看系统是否是 SMP 结构：

1

ls /sys/devices/system/node/     # 如果只看到一个 node0 那就是 SMP 架构

为了应对大规模的系统要求（特别是云计算环境），就研制出了 NUMA 结构，即非一致存储访问结构。

这种结构引入了 CPU 分组的概念，用 Node 来表示，一个 Node 可能包含多个物理 CPU 封装，从而包含多个 CPU 物理核心。每个 Node 有自己独立的资源，包括内存、IO 等。每个 Node 之间可以通过互联模块总线（QPI）进行通信，所以，也就意味着每个 Node 上的 CPU 都可以访问到整个系统中的所有内存，但很显然，访问远端 Node 的内存比访问本地内存要耗时很多，这也是 NUMA 架构的问题所在，我们在基于 NUMA 架构开发上层应用程序要尽可能避免跨 Node 内存访问。

NUMA 架构在 SMP 架构的基础上通过分组的方式增强了可扩展性，但从性能上看，随着 CPU 数量的增加，并不能线性增加系统性能，原因就在于跨 Node 内存访问的问题。所以，一般 NUMA 架构最多支持几百个 CPU 就不错了。

但对于很多大型计算密集型的系统来说，NUMA 显然有些吃力，所以，后来又出现了 MPP 架构，即海量并行处理架构。这种架构也有分组的概念，但和 NUMA 不同的是，它不存在异地内存访问的问题，每个分组内的 CPU 都有自己本地的内存、IO，并且不与其他 CPU 共享，是一种完全无共享的架构，因此它的扩展性最好，可以支持多达数千个 CPU 的量级。

总结

1、在芯片技术已然发展成熟的今天，性能低，上核不是问题，但上核就一定能提高性能吗，另外上核怎么很好地利用多核来完成自身进化，这些问题都值得深思。

2、NUMA 架构算是多核时代应用较大的一种 CPU 架构，本文从核心谈到系统，让大家有个全面的了解，下文会特别针对 NUMA 架构做一些实验验证。

Reference：
1.《深入浅出 DPDK》

2. SMP、NUMA、MPP体系结构介绍：
   https://www.cnblogs.com/yubo/archive/2010/04/23/1718810.html

PS：文章未经我允许，不得转载，否则后果自负。

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

平常工作会涉及到一些 Linux 性能分析的问题，因此决定总结一下常用的一些性能分析手段，仅供参考。

说到性能分析，基本上就是 CPU、内存、磁盘 IO 以及网络这几个部分，本文先来看 CPU 这个部分。

1 CPU 基础信息

进行性能分析之前，首先得知道 CPU 有哪些信息，可以通过以下方法查看 CPU 配置信息。

lscpu

在 Linux 下，类似 lsxxx 这样的命令都是用来查看基本信息的，如 ls 查看当前目录文件信息，lscpu 就用来查看 CPU 信息，类似还有 lspci 查看 PCI 信息。

可以看到我的机器配置很低，1 核 2.5GHz（在阿里云买的最低配的服务器）。

/proc/cpuinfo

/proc 目录是内核透传出来给用户态使用的，里面记录着很多信息文件，比如还有内存文件 meminfo 等。可以使用 cat /proc/cpuinfo 查看 CPU 信息。

这里显示的信息可以具体到每个逻辑核上，由于我只有一个核，所以只显示一组信息。

dmidecode

这个命令是用来获取 DMI（Desktop Management Interface）硬件信息的，包括 BIOS、系统、主板、处理器、内存、缓存等等。对于 CPU 信息，可以使用 dmidecode -t processor 来查看。

2 CPU 使用情况分析

知道了 CPU 的基本信息，我们就可以使用另外的命令来对 CPU 的使用情况分析一通了。

top

相信大家对下面这玩意不陌生，Windows 的任务管理器，top 的作用和它是一样的。

top 显示的效果虽说不像它这么华丽，但已然让人惊呼他俩怎么长得这么像。

我们重点关注这么几个字段：

• load average：三个数字分别表示最近 1 分钟，5 分钟和 15 分钟的负责，数值越大负载越重。一般要求不超过核数，比如对于单核情况要 < 1。如果机器长期处于高于核数的情况，说明机器 CPU 消耗严重了。
• %Cpu(s)：表示当前 CPU 的使用情况，如果要查看所有核（逻辑核）的使用情况，可以按下数字 “1” 查看。这里有几个参数，表示如下：

1
2
3
4
5
6
7
8

- us    用户空间占用 CPU 时间比例
- sy    系统占用 CPU 时间比例
- ni    用户空间改变过优先级的进程占用 CPU 时间比例
- id    CPU 空闲时间比
- wa    IO等待时间比（IO等待高时，可能是磁盘性能有问题了）
- hi    硬件中断
- si    软件中断
- st    steal time

每个进程的使用情况：这里可以罗列每个进程的使用情况，包括内存和 CPU 的，如果要看某个具体的进程，可以使用 top -p pid 查看。

和 top 一样的还有一个改进版的工具：htop，功能和 top 一样的，只不过比 top 表现更炫酷，使用更方便，可以看下它的效果。

ps

可能很多人会忽略这个命令，觉得这不是查看进程状态信息的吗，其实非也，这个命令配合它的参数能显示很多功能。比如 ps aux。如果配合 watch，可以达到跟 top 一样的效果，如：watch -n 1 "ps aux"（-n 1 表示每隔 1s 更新一次）

vmstat

这个命令基本能看出当前机器的运行状态和问题，非常强大。可以使用 vmstat n 后面跟一个数字，表示每隔 ns 显示系统的状态，信息包括 CPU、内存和 IO 等。

几个关键的字段：

• r 值：表示在 CPU 运行队列中等待的进程数，如果这个值很大，表示很多进程在排队等待执行，CPU 压力山大。
• in 和 cs 值：表示中断次数和上下文切换次数，这两个值越大，表示系统在进行大量的进程（或线程）切换。切换的开销是非常大的，这时候应该减少系统进程（或线程）数。
• us、sy、id、wa 值：这些值上面也提到过，分别表示用户空间进程，系统进程，空闲和 IO 等待的 CPU 占比，这里只有 id 很高是好的，表示系统比较闲，其他值飚高都不好。

这个工具强大之处在于它不仅可以分析 CPU，还可以分析内存、IO 等信息，犹如瑞士军刀。

dstat

这个命令也很强大，能显示 CPU 使用情况，磁盘 IO 情况，网络发包情况和换页情况，而且输出是彩色的，可读性比较强，相对于 vmstat 更加详细和直观。使用时可以直接输入命令，也可以带相关参数。

3 进程使用 CPU 情况分析

上面说的是系统级的分析，现在来看单个进程的 CPU 使用情况分析，以便于我们能对占用 CPU 过多的进程进行调试和分析，优化程序性能。

其实前面 top 和 ps 这样的命令就可以看每个进程的 CPU 使用情况，但我们需要更专业的命令。

pidstat

这个命令默认统计系统信息，也包括 CPU、内存和 IO 等，我们常用 pidstat -u -p pid [times] 来显示 CPU 统计信息。如下统计 pid = 802 的 CPU 信息。

strace

这个命令用来分析进程的系统调用情况，可以看进程都调用了哪些库和哪些系统调用，进而可以进一步优化程序。比如我们分析 ls 的系统调用情况，就可以用 strace ls：

可以看到，一个简单的 ls 命令，其实有不少系统调用的操作。

此外，还可以 attach（附着）到一个正在运行的进程上进行分析，比如我 attach 到 802 这个进程显示：

根据这些输出信息，其实就能够很好地帮我们分析问题，从而定位到问题所在了。

OK，以上就是平常比较常用的一些工具，当然除了这些，还有很多很多工具，下面放一张图，来自 Linux 大牛，Netflix 高级性能架构师 Brendan Gregg。看完了，你也许会感叹“这世界太疯狂了（just crazy）”。

Reference：
[1]. http://rdc.hundsun.com/portal/article/731.html

PS：文章未经我允许，不得转载，否则后果自负。

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。

文章首发于我的公众号「Linux云计算网络」，欢迎关注，第一时间掌握技术干货！

前面单主机容器网络和多主机容器网络两篇文章，咱们已经从原理上总结了多种容器网络方案，也通过这篇文章探讨了容器网络的背后原理。本文再基于一个宏观的视角，对比几种网络方案，让大家有个完整的认识。

单主机网络就不多说了，因为也比较简单，我们重点对比几种多主机网络方案。

对比的维度有以下几种：网络模型，IP 地址池管理（IP Address Management，IPAM），服务发现，连通与隔离，性能。

网络模型指的是构成跨主机通信的网络结构和实现技术，比如是纯二层转发，还是纯三层转发；是 overlay 网络还是 underlay 网络等等。

IPAM 指的是如何管理容器网络的 IP 池。当容器集群比较大，管理的主机比较多的时候，如何分配各个主机上容器的 IP 是一个比较棘手的问题。Docker 网络有个 subnet 的概念，通常一个主机分配一个 subnet，但也有多个主机共用一个 subnet 的情况，具体的网络方案有不同的考量。具体看下面的表格总结。

服务发现本质上是一个分布式的 key-value 存储系统，用于跨主机通信时保存并同步各主机的网络信息，便于快速建立起各主机之间的网络连接。由于各网络方案实现上各有千秋，并不是所有的跨主机网络方案都要依据服务发现。

连通与隔离指的是容器跨主机之间是否能够互相通信，以及容器与外网（外网不一定指 Internet）之间如何通信。

性能具体指的是通信的时延，我们仅从各个网络方案的原理上来分析得出结论，所以这里的结论并不一定正确，因为不同的部署环境会对性能有一些影响，建议大家还是根据自己的环境动手实验验证为妙。

从原理上说，underlay 网络性能要优于 overlay 网络，因为 overlay 网络存在封包和拆包操作，存在额外的 CPU 和网络开销，所以，几种方案中，macvlan、flannel host-gw、calico 的性能会优于 overlay、flannel vxlan 和 weave。但是这个也不能作为最终生产环境采用的标准，因为 overlay 网络采用 vxlan 作为隧道的话，能支持更多的二层网段，安全性也更高，所以，需要综合考虑。

通过以上分析，我们可以得出以下的结论：

参考：
http://www.cnblogs.com/CloudMan6/p/7587532.html

PS：文章未经我允许，不得转载，否则后果自负。

欢迎扫👇的二维码关注我的微信公众号，后台回复「m」，可以获取往期所有技术博文推送，更多资料回复下列关键字获取。