Memory

Linux内存--HugePage

Linux内存–HugePage

本系列有如下几篇

[Linux 内存问题汇总](/2020/01/15/Linux 内存问题汇总/)

Linux内存–PageCache

Linux内存–管理和碎片

Linux内存–HugePage

Linux内存–零拷贝

/proc/buddyinfo

/proc/buddyinfo记录了内存的详细碎片情况。

1
2
3
4
#cat /proc/buddyinfo 
Node 0, zone      DMA      1      1      1      0      2      1      1      0      1      1      3 
Node 0, zone    DMA32      2      5      3      6      2      0      4      4      2      2    404 
Node 0, zone   Normal 243430 643847 357451  32531   9508   6159   3917   2960  17172   2633  22854

Normal行的第二列表示： 643847*2^1*Page_Size(4K) ; 第三列表示： 357451*2^2*Page_Size(4K) ，高阶内存指的是2^3及更大的内存块。

应用申请大块连续内存（高阶内存，一般之4阶及以上, 也就是64K以上–2^4*4K）时，容易导致卡顿。这是因为大块连续内存确实系统需要触发回收或者碎片整理，需要一定的时间。

slabtop和/proc/slabinfo

slabtop和/proc/slabinfo 查看cached使用情况 主要是：pagecache（页面缓存）， dentries（目录缓存）， inodes

关于hugetlb

This is an entry in the TLB that points to a HugePage (a large/big page larger than regular 4K and predefined in size). HugePages are implemented via hugetlb entries, i.e. we can say that a HugePage is handled by a “hugetlb page entry”. The ‘hugetlb” term is also (and mostly) used synonymously with a HugePage.

hugetlb 是TLB中指向HugePage的一个entry(通常大于4k或预定义页面大小)。 HugePage 通过hugetlb entries来实现，也可以理解为HugePage 是hugetlb page entry的一个句柄。

Linux下的大页分为两种类型：标准大页（Huge Pages）和透明大页（Transparent Huge Pages）

标准大页管理是预分配的方式，而透明大页管理则是动态分配的方式

目前透明大页与传统HugePages联用会出现一些问题，导致性能问题和系统重启。Oracle 建议禁用透明大页（Transparent Huge Pages）

hugetlbfs比THP要好，开thp的机器碎片化严重（不开THP会有更严重的碎片化问题），最后和没开THP一样 https://www.atatech.org/articles/152660

Linux 中的 HugePages 都被锁定在内存中，所以哪怕是在系统内存不足时，它们也不会被 Swap 到磁盘上，这也就能从根源上杜绝了重要内存被频繁换入和换出的可能。

Transparent Hugepages are similar to standard HugePages. However, while standard HugePages allocate memory at startup, Transparent Hugepages memory uses the khugepaged thread in the kernel to allocate memory dynamically during runtime, using swappable HugePages.

HugePage要求OS启动的时候提前分配出来，管理难度比较大，所以Enterprise Linux 6增加了一层抽象层来动态创建管理HugePage，这就是THP，而这个THP对应用透明，由khugepaged thread在后台动态将小页组成大页给应用使用，这里会遇上碎片问题导致需要compact才能得到大页，应用感知到的就是SYS CPU飙高，应用卡顿了。

虽然 HugePages 的开启大都需要开发或者运维工程师的额外配置，但是在应用程序中启用 HugePages 却可以在以下几个方面降低内存页面的管理开销：

  • 更大的内存页能够减少内存中的页表层级，这不仅可以降低页表的内存占用，也能降低从虚拟内存到物理内存转换的性能损耗；
  • 更大的内存页意味着更高的缓存命中率，CPU 有更高的几率可以直接在 TLB（Translation lookaside buffer）中获取对应的物理地址；
  • 更大的内存页可以减少获取大内存的次数，使用 HugePages 每次可以获取 2MB 的内存，是 4KB 的默认页效率的 512 倍；

HugePage

为什么需要Huge Page 了解CPU Cache大致架构的话，一定听过TLB Cache。Linux系统中，对程序可见的，可使用的内存地址是Virtual Address。每个程序的内存地址都是从0开始的。而实际的数据访问是要通过Physical Address进行的。因此，每次内存操作，CPU都需要从page table中把Virtual Address翻译成对应的Physical Address，那么对于大量内存密集型程序来说page table的查找就会成为程序的瓶颈。

所以现代CPU中就出现了TLB(Translation Lookaside Buffer) Cache用于缓存少量热点内存地址的mapping关系。然而由于制造成本和工艺的限制，响应时间需要控制在CPU Cycle级别的Cache容量只能存储几十个对象。那么TLB Cache在应对大量热点数据Virual Address转换的时候就显得捉襟见肘了。我们来算下按照标准的Linux页大小(page size) 4K，一个能缓存64元素的TLB Cache只能涵盖4K*64 = 256K的热点数据的内存地址，显然离理想非常遥远的。于是Huge Page就产生了。

Huge pages require contiguous areas of memory, so allocating them at boot is the most reliable method since memory has not yet become fragmented. To do so, add the following parameters to the kernel boot command line:

Huge pages kernel options

  • hugepages

    Defines the number of persistent huge pages configured in the kernel at boot time. The default value is 0. It is only possible to allocate (or deallocate) huge pages if there are sufficient physically contiguous free pages in the system. Pages reserved by this parameter cannot be used for other purposes.

    Default size huge pages can be dynamically allocated or deallocated by changing the value of the /proc/sys/vm/nr_hugepages file.

    In a NUMA system, huge pages assigned with this parameter are divided equally between nodes. You can assign huge pages to specific nodes at runtime by changing the value of the node’s /sys/devices/system/node/node_id/hugepages/hugepages-1048576kB/nr_hugepages file.

    For more information, read the relevant kernel documentation, which is installed in /usr/share/doc/kernel-doc-kernel_version/Documentation/vm/hugetlbpage.txt by default. This documentation is available only if the kernel-doc package is installed.

  • hugepagesz

    Defines the size of persistent huge pages configured in the kernel at boot time. Valid values are 2 MB and 1 GB. The default value is 2 MB.

  • default_hugepagesz

    Defines the default size of persistent huge pages configured in the kernel at boot time. Valid values are 2 MB and 1 GB. The default value is 2 MB.

应用程序想要利用大页优势，需要通过hugetlb文件系统来使用标准大页。操作步骤

1.预留大页

echo 20 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

2.挂载hugetlb文件系统

mount hugetlbfs /mnt/huge -t hugetlbfs

3.映射hugetbl文件

fd = open(“/mnt/huge/test.txt”, O_CREAT|O_RDWR);

addr = mmap(0, MAP_LENGTH, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

4.hugepage统计信息

通过hugepage提供的sysfs接口，可以了解大页使用情况

HugePages_Total: 预先分配的大页数量

HugePages_Free：空闲大页数量

HugePages_Rsvd: mmap申请大页数量(还没有产生缺页)

HugePages_Surp: 多分配的大页数量(由nr_overcommit_hugepages决定)

5 hugpage优缺点

缺点:

1.需要提前预估大页使用量，并且预留的大页不能被其他内存分配接口使用。

2.兼容性不好，应用使用标准大页，需要对代码进行重构才能有效的使用标准大页。

优点:因为内存是预留的，缺页延时非常小

针对Hugepage的不足，内核又衍生出了THP大页(Transparent Huge pages)

工具

1
2
3
4
5
6
7
8
9
10
11
yum install libhugetlbfs-utils -y

//列出
hugeadm --pool-list
      Size  Minimum  Current  Maximum  Default
   2097152    12850    12850    12850        *
1073741824        0        0        0

hugeadm --list-all-mounts
Mount Point          Options
/dev/hugepages       rw,relatime,pagesize=2M

大页和 MySQL 性能 case

MySQL的页都是16K, 当查询的行不在内存中时需要按照16K为单位从磁盘读取页,而文件系统中的页是4k，也就是一次数据库请求需要有4次磁盘IO，如过查询比较随机，每次只需要一个页中的几行数据，存在很大的读放大。

那么我们是否可以把MySQL的页设置为4K来减少读放大呢？

在5.7里收益不大，因为每次IO存在 fil_system 的锁，导致IO的并发上不去

8.0中总算优化了这个场景，测试细节可以参考这篇

16K VS 4K 性能对比（4K接近翻倍）

img

4K会带来的问题：顺序insert慢了10%（因为fsync更多了）；DDL更慢；二级索引更多的场景下4K性能较差；大BP下，刷脏代价大。

HugePage 带来的问题

CPU对同一个Page抢占增多

对于写操作密集型的应用，Huge Page会大大增加Cache写冲突的发生概率。由于CPU独立Cache部分的写一致性用的是MESI协议，写冲突就意味：

  • 通过CPU间的总线进行通讯，造成总线繁忙
  • 同时也降低了CPU执行效率。
  • CPU本地Cache频繁失效

类比到数据库就相当于，原来一把用来保护10行数据的锁，现在用来锁1000行数据了。必然这把锁在线程之间的争抢概率要大大增加。

连续数据需要跨CPU读取

Page太大，更容易造成Page跨Numa/CPU 分布。

从下图我们可以看到，原本在4K小页上可以连续分配，并因为较高命中率而在同一个CPU上实现locality的数据。到了Huge Page的情况下，就有一部分数据为了填充统一程序中上次内存分配留下的空间，而被迫分布在了两个页上。而在所在Huge Page中占比较小的那部分数据，由于在计算CPU亲和力的时候权重小，自然就被附着到了其他CPU上。那么就会造成：本该以热点形式存在于CPU2 L1或者L2 Cache上的数据，不得不通过CPU inter-connect去remote CPU获取数据。 假设我们连续申明两个数组，Array A和Array B大小都是1536K。内存分配时由于第一个Page的2M没有用满，因此Array B就被拆成了两份，分割在了两个Page里。而由于内存的亲和配置，一个分配在Zone 0，而另一个在Zone 1。那么当某个线程需要访问Array B时就不得不通过代价较大的Inter-Connect去获取另外一部分数据。

img

Java进程开启HugePage

从perf数据来看压满后tlab miss比较高，得想办法降低这个值

修改JVM启动参数

JVM启动参数增加如下三个(-XX:LargePageSizeInBytes=2m, 这个一定要，有些资料没提这个，在我的JDK8.0环境必须要)：

-XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:+UseHugeTLBFS

修改机器系统配置

设置HugePage的大小

cat /proc/sys/vm/nr_hugepages

nr_hugepages设置多大参考如下计算方法：

If you are using the option -XX:+UseSHM or -XX:+UseHugeTLBFS, then specify the number of large pages. In the following example, 3 GB of a 4 GB system are reserved for large pages (assuming a large page size of 2048kB, then 3 GB = 3 * 1024 MB = 3072 MB = 3072 * 1024 kB = 3145728 kB and 3145728 kB / 2048 kB = 1536):

echo 1536 > /proc/sys/vm/nr_hugepages

透明大页是没有办法减少系统tlab，tlab是对应于进程的，系统分给进程的透明大页还是由物理上的4K page组成。

对于c++来说，他malloc经常会散落得全地址都是，因为会触发各种mmap，冷热区域。所以THP和hugepage都可能导致大量内存被浪费了，进而导致内存紧张，性能下滑。jvm的连续内存布局，加上gc会使得内存密度很紧凑。THP的问题是，他是逻辑页，不是物理页，tlb依旧要N份，所以他的收益来自page fault减少，是一次性的收益。

hugepage的在减少page_fault上和thp效果一样第二个作用是，他只需要一份TLB了，hugepage是真正的大页内存，thp是逻辑上的，物理上还是需要很多小的page。

如果TLB miss，则可能需要额外三次内存读取操作才能将线性地址翻译为物理地址。

code_hugepage 代码大页

代码大页特性主要为大代码段业务服务，可以降低程序的iTLB miss，从而提升程序性能。针对倚天这一类跨numa访存开销大的芯片有比较好的性能提升效果

1
2
// 1 表示仅打开二进制和动态库大页  2 仅打开可执行匿名大页 3 相当于1+2，0 表示关闭
echo 1 > /sys/kernel/mm/transparent_hugepage/hugetext_enabled //1 可以改成2/3

是否启用代码大页，可以查看/proc//smaps中FilePmdMapped字段可确定是否使用了代码大页。 扫描进程代码大页使用数量（单位KB）：

1
cat /proc/<pid>/smaps | grep FilePmdMapped | awk '{sum+=$2}END{print"Sum= ",sum}'

THP

Linux kernel在2.6.38内核增加了Transparent Huge Pages (THP)特性 ，支持大内存页(2MB)分配，默认开启。当开启时可以降低fork子进程的速度，但fork之后，每个内存页从原来4KB变为2MB，会大幅增加重写期间父进程内存消耗。同时每次写命令引起的复制内存页单位放大了512倍，会拖慢写操作的执行时间，导致大量写操作慢查询。例如简单的incr命令也会出现在慢查询中。因此Redis日志中建议将此特性进行禁用。

THP 的目的是用一个页表项来映射更大的内存（大页），这样可以减少 Page Fault，因为需要的页数少了。当然，这也会提升 TLB（Translation Lookaside Buffer，由存储器管理单元用于改进虚拟地址到物理地址的转译速度） 命中率，因为需要的页表项也少了。如果进程要访问的数据都在这个大页中，那么这个大页就会很热，会被缓存在 Cache 中。而大页对应的页表项也会出现在 TLB 中，从上一讲的存储层次我们可以知道，这有助于性能提升。但是反过来，假设应用程序的数据局部性比较差，它在短时间内要访问的数据很随机地位于不同的大页上，那么大页的优势就会消失。

大页在使用的时候需要清理512个4K页面，再返回给用户，这里的清理动作可能会导致卡顿。另外碎片化严重的时候触发内存整理造成卡顿

大页分配: 在缺页处理函数__handle_mm_fault中判断是否使用大页 大页生成: 主要通过在分配大页内存时是否带__GFP_DIRECT_RECLAIM 标志来控制大页的生成.

1.异步生成大页: 在缺页处理中，把需要异步生成大页的VMA注册到链表，内核态线程khugepaged 动态为vma分配大页(内存回收，内存归整)

2.madvise系统调用只是给VMA加了VM_HUGEPAGE,用来标记这段虚拟地址需要使用大页

image-20240116134744487

THP 原理

大页分配: 在缺页处理函数__handle_mm_fault中判断是否使用大页 大页生成: 主要通过在分配大页内存时是否带__GFP_DIRECT_RECLAIM 标志来控制大页的生成.

1.异步生成大页: 在缺页处理中，把需要异步生成大页的VMA注册到链表，内核态线程khugepaged 动态为vma分配大页(内存回收，内存归整)

2.madvise系统调用只是给VMA加了VM_HUGEPAGE,用来标记这段虚拟地址需要使用大页

THP 对redis、mongodb 这种cache类推荐关闭，对drds这种java应用最好打开

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

grep "Huge" /proc/meminfo
AnonHugePages:   1286144 kB
ShmemHugePages:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB

$grep -e AnonHugePages  /proc/*/smaps | awk  '{ if($2>4) print $0} ' |  awk -F "/"  '{print $0; system("ps -fp " $3)} '

$grep -e AnonHugePages  /proc/*/smaps | awk  '{ if($2>4) print $0} ' |  awk -F "/"  '{print $0; system("ps -fp " $3)} '

//查看pagesize（默认4K） 
$getconf PAGESIZE

在透明大页功能打开时，造成系统性能下降的主要原因可能是 khugepaged 守护进程。该进程会在（它认为）系统空闲时启动，扫描系统中剩余的空闲内存，并将普通 4k 页转换为大页。该操作会在内存路径中加锁，而该守护进程可能会在错误的时间启动扫描和转换大页的操作，从而影响应用性能。

此外，当缺页异常(page faults)增多时，透明大页会和普通 4k 页一样，产生同步内存压缩(direct compaction)操作，以节省内存。该操作是一个同步的内存整理操作，如果应用程序会短时间分配大量内存，内存压缩操作很可能会被触发，从而会对系统性能造成风险。https://yq.aliyun.com/articles/712830

1
2
3
4
5
6
7
#查看系统级别的 THP 使用情况，执行下列命令：
cat /proc/meminfo  | grep AnonHugePages
#类似地，查看进程级别的 THP 使用情况，执行下列命令：
cat /proc/1730/smaps | grep AnonHugePages |grep -v "0 kB"
#是否开启了hugepage
$cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

/proc/sys/vm/nr_hugepages 中存储的数据就是大页面的数量，虽然在默认情况下它的值都是 0，不过我们可以通过更改该文件的内容申请或者释放操作系统中的大页：

1
2
3
4
$ echo 1 > /proc/sys/vm/nr_hugepages
$ cat /proc/meminfo | grep HugePages_
HugePages_Total:       1
HugePages_Free:        1

THP和perf

thp on后比off性能稳定好 10-15%，开启THP最显著的指标是 iTLB命中率显著提升了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
//on 419+E5-2682， thp never
9,145,128,732      branch-instructions       #  229.068 M/sec                    (10.65%)
       555,518,878      branch-misses             #    6.07% of all branches          (14.24%)
     3,951,535,475      bus-cycles                #   98.979 M/sec                    (14.29%)
       372,477,068      cache-misses              #    7.733 % of all cache refs      (14.34%)
     4,816,702,013      cache-references          #  120.649 M/sec                    (14.36%)
   114,521,174,305      cpu-cycles                #    2.869 GHz                      (14.36%)
    48,969,565,344      instructions              #    0.43  insn per cycle           (17.93%)
    98,728,666,922      ref-cycles                # 2472.967 M/sec                    (21.52%)
         39,922.47 msec cpu-clock                 #    7.898 CPUs utilized
     1,848,336,574      L1-dcache-load-misses     #   13.31% of all L1-dcache hits    (21.51%)
    13,889,399,043      L1-dcache-loads           #  347.903 M/sec                    (21.51%)
     7,055,617,648      L1-dcache-stores          #  176.730 M/sec                    (21.50%)
     2,017,950,458      L1-icache-load-misses                                         (21.50%)
        88,802,885      LLC-load-misses           #    9.86% of all LL-cache hits     (14.35%)
       900,379,398      LLC-loads                 #   22.553 M/sec                    (14.33%)
       162,711,813      LLC-store-misses          #    4.076 M/sec                    (7.13%)
       419,869,955      LLC-stores                #   10.517 M/sec                    (7.14%)
       553,257,955      branch-load-misses        #   13.858 M/sec                    (10.71%)
     9,195,874,519      branch-loads              #  230.339 M/sec                    (14.29%)
       176,112,524      dTLB-load-misses          #    1.28% of all dTLB cache hits   (14.29%)
    13,739,965,115      dTLB-loads                #  344.160 M/sec                    (14.28%)
        33,087,849      dTLB-store-misses         #    0.829 M/sec                    (14.28%)
     6,992,863,588      dTLB-stores               #  175.158 M/sec                    (14.26%)
       170,555,902      iTLB-load-misses          #  107.90% of all iTLB cache hits   (14.24%)
       158,070,998      iTLB-loads                #    3.959 M/sec                    (14.24%)

//on 419+E5-2682， thp always
    12,958,974,094      branch-instructions       #  227.392 M/sec                    (10.68%)
       850,468,837      branch-misses             #    6.56% of all branches          (14.27%)
     5,639,495,284      bus-cycles                #   98.957 M/sec                    (14.29%)
       526,744,798      cache-misses              #    7.324 % of all cache refs      (14.32%)
     7,192,328,925      cache-references          #  126.204 M/sec                    (14.34%)
   163,419,436,811      cpu-cycles                #    2.868 GHz                      (14.33%)
    68,638,583,038      instructions              #    0.42  insn per cycle           (17.90%)
   140,882,455,768      ref-cycles                # 2472.076 M/sec                    (21.48%)
         56,987.52 msec cpu-clock                 #    7.932 CPUs utilized
     2,471,392,118      L1-dcache-load-misses     #   12.69% of all L1-dcache hits    (21.47%)
    19,480,914,771      L1-dcache-loads           #  341.833 M/sec                    (21.48%)
    10,059,893,871      L1-dcache-stores          #  176.522 M/sec                    (21.46%)
     3,184,073,065      L1-icache-load-misses                                         (21.46%)
       128,467,945      LLC-load-misses           #   10.83% of all LL-cache hits     (14.31%)
     1,186,653,892      LLC-loads                 #   20.822 M/sec                    (14.30%)
       224,877,539      LLC-store-misses          #    3.946 M/sec                    (7.15%)
       628,574,746      LLC-stores                #   11.030 M/sec                    (7.15%)
       848,830,289      branch-load-misses        #   14.894 M/sec                    (10.71%)
    13,074,297,582      branch-loads              #  229.416 M/sec                    (14.28%)
       109,223,171      dTLB-load-misses          #    0.56% of all dTLB cache hits   (14.27%)
    19,418,657,165      dTLB-loads                #  340.741 M/sec                    (14.29%)
        13,930,402      dTLB-store-misses         #    0.244 M/sec                    (14.28%)
    10,047,511,003      dTLB-stores               #  176.305 M/sec                    (14.28%)
       194,902,860      iTLB-load-misses          #   61.23% of all iTLB cache hits   (14.27%)
       318,292,771      iTLB-loads                #    5.585 M/sec                    (14.26%)

//on 310+8269 thp never
        90,790,778      dTLB-load-misses          #    0.67% of all dTLB cache hits   (16.66%)
    13,639,069,352      dTLB-loads                                                    (16.66%)
         6,553,693      dTLB-store-misses                                             (16.63%)
     6,494,274,815      dTLB-stores                                                   (20.28%)
        76,175,883      iTLB-load-misses          #   40.53% of all iTLB cache hits   (20.80%)
       187,932,292      iTLB-loads                                                    (20.76%)

//on 310+8269 thp always
     7,199,483,512      branch-instructions       #  338.269 M/sec                    (11.46%)
        81,893,729      branch-misses             #    1.14% of all branches          (14.95%)
       532,919,206      bus-cycles                #   25.039 M/sec                    (14.85%)
       253,267,167      cache-misses              #   11.507 % of all cache refs      (14.81%)
     2,201,001,946      cache-references          #  103.414 M/sec                    (14.15%)
    63,971,073,336      cpu-cycles                #    3.006 GHz                      (14.55%)
    37,214,341,673      instructions              #    0.58  insns per cycle          (18.09%)
    52,209,823,072      ref-cycles                # 2453.086 M/sec                    (17.23%)
     1,098,964,315      L1-dcache-load-misses     #   10.17% of all L1-dcache hits    (14.22%)
    10,808,109,191      L1-dcache-loads           #  507.820 M/sec                    (14.31%)
     5,092,652,478      L1-dcache-stores          #  239.279 M/sec                    (14.38%)
     4,338,580,209      L1-icache-load-misses     #  203.849 M/sec                    (14.40%)
        60,262,584      LLC-load-misses           #   21.81% of all LL-cache hits     (14.35%)
       276,321,779      LLC-loads                 #   12.983 M/sec                    (14.31%)
        62,982,184      LLC-store-misses          #    2.959 M/sec                    (10.76%)
       105,448,227      LLC-stores                #    4.954 M/sec                    (8.08%)
        81,163,187      branch-load-misses        #    3.813 M/sec                    (11.67%)
     7,111,481,940      branch-loads              #  334.134 M/sec                    (14.37%)
         4,527,406      dTLB-load-misses          #    0.04% of all dTLB cache hits   (14.30%)
    10,726,725,791      dTLB-loads                #  503.997 M/sec                    (17.33%)
         1,066,097      dTLB-store-misses         #    0.050 M/sec                    (17.37%)
     5,090,008,144      dTLB-stores               #  239.155 M/sec                    (17.34%)
        18,715,797      iTLB-load-misses          #   18.97% of all iTLB cache hits   (17.33%)
        98,684,189      iTLB-loads                #    4.637 M/sec                    (14.29%)

MySQL 场景下代码大页对性能的影响

不只是数据可以用HugePage，代码段也可以开启HugePage, 无论在x86还是arm（arm下提升更明显）下，都可以得到大页优于透明大页，透明大页优于正常的4K page

收益：代码大页 > anon THP > 4k

arm下，对32core机器用32并发的sysbench来对比，代码大页带来的性能提升大概有11%，iTLB miss下降了10倍左右。

x86下，性能提升只有大概3-5%之间，iTLB miss下降了1.5-3倍左右。

TLAB miss高的案例

程序运行久了之后会变慢大概10%

刚开始运行的时候perf各项数据:

img

长时间运行后：

img

内存的利用以页为单位，当时分析认为，在此4k连续的基础上，页的碎片不应该对64 byte align的cache有什么影响。当时guest和host都没有开THP。

既然无法理解这个结果，那就只有按部就班的查看内核执行路径上各个函数的差别了，祭出ftrace:

1
2
3
4
5
6
echo kerel_func_name1 > /sys/kernel/debug/tracing/set_ftrace_filter

echo kerel_func_name2 > /sys/kernel/debug/tracing/set_ftrace_filter

echo kerel_func_name3 > /sys/kernel/debug/tracing/set_ftrace_filter
echo 1 > /sys/kernel/debug/tracing/function_profile_enabled

在CPU#20上执行代码:

taskset -c 20 ./b

代码执行完后:

1
2
echo 0 > /sys/kernel/debug/tracing/function_profile_enabled
cat /sys/kernel/debug/tracing/trace_stat/function20

这个时候就会打印出在各个函数上花费的时间，比如:

img

经过调试后，逐步定位到主要时间差距在 __mem_cgroup_commit_charge() (58%).

在阅读代码的过程中，注意到当前内核使能了CONFIG_SPARSEMEM_VMEMMAP=y

原因就是机器运行久了之后内存碎片化严重，导致TLAB Miss严重。

解决：开启THP后，性能稳定

碎片化

内存碎片严重的话会导致系统hang很久(回收、压缩内存）

尽量让系统的free多一点(比例高一点）可以调整 vm.min_free_kbytes(128G 以内 2G，256G以内 4G/8G), 线上机器直接修改vm.min_free_kbytes会触发回收，导致系统hang住 https://www.atatech.org/articles/163233 https://www.atatech.org/articles/97130

compact: 在进行 compcation 时，线程会从前往后扫描已使用的 movable page，然后从后往前扫描 free page，扫描结束后会把这些 movable page 给迁移到 free page 里，最终规整出一个 2M 的连续物理内存，这样 THP 就可以成功申请内存了。

image-20210628144121108

一次THP compact堆栈：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
java          R  running task        0 144305 144271 0x00000080
 ffff88096393d788 0000000000000086 ffff88096393d7b8 ffffffff81060b13
 ffff88096393d738 ffffea003968ce50 000000000000000e ffff880caa713040
 ffff8801688b0638 ffff88096393dfd8 000000000000fbc8 ffff8801688b0640

Call Trace:
 [<ffffffff81060b13>] ? perf_event_task_sched_out+0x33/0x70
 [<ffffffff8100bb8e>] ? apic_timer_interrupt+0xe/0x20
 [<ffffffff810686da>] __cond_resched+0x2a/0x40
 [<ffffffff81528300>] _cond_resched+0x30/0x40
 [<ffffffff81169505>] compact_checklock_irqsave+0x65/0xd0
 [<ffffffff81169862>] compaction_alloc+0x202/0x460
 [<ffffffff811748d8>] ? buffer_migrate_page+0xe8/0x130
 [<ffffffff81174b4a>] migrate_pages+0xaa/0x480
 [<ffffffff81169660>] ? compaction_alloc+0x0/0x460                 //compact and migrate
 [<ffffffff8116a1a1>] compact_zone+0x581/0x950
 [<ffffffff8116a81c>] compact_zone_order+0xac/0x100
 [<ffffffff8116a951>] try_to_compact_pages+0xe1/0x120
 [<ffffffff8112f1ba>] __alloc_pages_direct_compact+0xda/0x1b0
 [<ffffffff8112f80b>] __alloc_pages_nodemask+0x57b/0x8d0
 [<ffffffff81167b9a>] alloc_pages_vma+0x9a/0x150
 [<ffffffff8118337d>] do_huge_pmd_anonymous_page+0x14d/0x3b0        //huge page
 [<ffffffff8152a116>] ? rwsem_down_read_failed+0x26/0x30
 [<ffffffff8114b350>] handle_mm_fault+0x2f0/0x300
 [<ffffffff810ae950>] ? wake_futex+0x40/0x60
 [<ffffffff8104a8d8>] __do_page_fault+0x138/0x480
 [<ffffffff810097cc>] ? __switch_to+0x1ac/0x320
 [<ffffffff81527910>] ? thread_return+0x4e/0x76e
 [<ffffffff8152d45e>] do_page_fault+0x3e/0xa0                       //page fault
 [<ffffffff8152a815>] page_fault+0x25/0x30

查看pagetypeinfo

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
#cat /proc/pagetypeinfo
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    0, zone      DMA, type    Unmovable      1      1      1      0      2      1      1      0      1      0      0
Node    0, zone      DMA, type  Reclaimable      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type      Movable      0      0      0      0      0      0      0      0      0      1      3
Node    0, zone      DMA, type      Reserve      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type          CMA      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type    Unmovable     89    144     98     42     21     14      5      2      1      0      1
Node    0, zone    DMA32, type  Reclaimable     28     22      9      8      0      0      0      0      0      1      7
Node    0, zone    DMA32, type      Movable    402     50     21      8    880    924    321     51      4      1    227
Node    0, zone    DMA32, type      Reserve      0      0      0      0      0      0      0      0      0      0      1
Node    0, zone    DMA32, type          CMA      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone   Normal, type    Unmovable  13709  15231   6637   2646    816    181     46      4      4      1      0
Node    0, zone   Normal, type  Reclaimable      1      5      6   3293   1295    128     29      7      5      0      0
Node    0, zone   Normal, type      Movable   6396 1383350 1301956 1007627 670102 366248 160232  54894  13126   1482     37
Node    0, zone   Normal, type      Reserve      0      0      0      2      1      1      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

Number of blocks type     Unmovable  Reclaimable      Movable      Reserve          CMA      Isolate
Node 0, zone      DMA            1            0            7            0            0            0
Node 0, zone    DMA32           24           38          889            1            0            0
Node 0, zone   Normal         1568          795       127683            2            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    1, zone   Normal, type    Unmovable   3938   8735   5469   3221   2097    989    202      6      0      0      0
Node    1, zone   Normal, type  Reclaimable      1      7      7      8      7      2      2      2      1      0      0
Node    1, zone   Normal, type      Movable  18623 1001037 2084894 1261484 631159 276096  87272  17169   1389    797      0
Node    1, zone   Normal, type      Reserve      0      0      0      8      0      0      0      0      0      0      0
Node    1, zone   Normal, type          CMA      0      0      0      0      0      0      0      0      0      0      0
Node    1, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable  Reclaimable      Movable      Reserve          CMA      Isolate
Node 1, zone   Normal         1530          637       128903            2            0            0

每个zone都有自己的min low high,如下，但是单位是page, 计算案例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
[root@jiangyi01.sqa.zmf /home/ahao.mah]
#cat /proc/zoneinfo  |grep "Node"
Node 0, zone      DMA
Node 0, zone    DMA32
Node 0, zone   Normal
Node 1, zone   Normal

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#cat /proc/zoneinfo  |grep "Node 0, zone" -A10
Node 0, zone      DMA
  pages free     3975
        min      20
        low      25
        high     30
        scanned  0
        spanned  4095
        present  3996
        managed  3975
    nr_free_pages 3975
    nr_alloc_batch 5
--
Node 0, zone    DMA32
  pages free     382873
        min      2335
        low      2918
        high     3502
        scanned  0
        spanned  1044480
        present  513024
        managed  450639
    nr_free_pages 382873
    nr_alloc_batch 584
--
Node 0, zone   Normal
  pages free     11105097
        min      61463
        low      76828
        high     92194
        scanned  0
        spanned  12058624
        present  12058624
        managed  11859912
    nr_free_pages 11105097
    nr_alloc_batch 12344
    
    low = 5/4 * min
high = 3/2 * min

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#T=min;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=499 MB

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#T=low;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=624 MB

[root@jiangyi01.sqa.zmf /home/ahao.mah]
#T=high;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=802 MB

内存碎片化导致rt升高的诊断

判定方法如下：

  1. 运行 sar -B 观察 pgscand/s，其含义为每秒发生的直接内存回收次数，当在一段时间内持续大于 0 时，则应继续执行后续步骤进行排查；
  2. 运行 cat /sys/kernel/debug/extfrag/extfrag_index 观察内存碎片指数，重点关注 order >= 3 的碎片指数，当接近 1.000 时，表示碎片化严重，当接近 0 时表示内存不足；
  3. 运行 cat /proc/buddyinfo, cat /proc/pagetypeinfo 查看内存碎片情况， 指标含义参考 （https://man7.org/linux/man-pages/man5/proc.5.html），同样关注 order >= 3 的剩余页面数量，pagetypeinfo 相比 buddyinfo 展示的信息更详细一些，根据迁移类型 （伙伴系统通过迁移类型实现反碎片化）进行分组，需要注意的是，当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重，我们需要结合其他工具来排查具体原因，在本文就不做过多介绍了；
  4. 对于 CentOS 7.6 等支持 BPF 的 kernel 也可以运行我们研发的 drsnoop，compactsnoop 工具对延迟进行定量分析，使用方法和解读方式请参考对应文档；
  5. (Opt) 使用 ftrace 抓取 mm_page_alloc_extfrag 事件，观察因内存碎片从备用迁移类型“盗取”页面的信息。

​

参考资料

https://www.atatech.org/articles/66885

https://cloud.tencent.com/developer/article/1087455

https://www.cnblogs.com/xiaolincoding/p/13719610.html

Memory

Linux内存--零拷贝

Linux内存–零拷贝

本系列有如下几篇

[Linux 内存问题汇总](/2020/01/15/Linux 内存问题汇总/)

Linux内存–PageCache

Linux内存–管理和碎片

Linux内存–HugePage

Linux内存–零拷贝

零拷贝

“Zero-copy“ describes computer operations in which the CPU does not perform the task of copying data from one memory area to another. This is frequently used to save CPU cycles and memory bandwidth when transmitting a file over a network.

零拷贝技术是指计算机执行操作时，CPU不需要先将数据从某处内存复制到另一个特定区域。这种技术通常用于通过网络传输文件时节省 CPU 和内存带宽。

零拷贝可以做到用户空间和内核空间共用同一块内存（Java中的DirectBuffer），这样少做一次拷贝。普通Buffer是在JVM堆上分配的内存，而DirectBuffer是堆外分配的（内核和JVM可以同时读写），这样不需要再多一次内核到用户Buffer的拷贝

比如通过网络下载文件，普通拷贝的流程会复制4次并有4次上下文切换，上下文切换是因为读写慢导致了IO的阻塞，进而线程被内核挂起，所以发生了上下文切换。在极端情况下如果read/write没有导致阻塞是不会发生上下文切换的：

NoOptimization

改成零拷贝后，也就是将read和write合并成一次，直接在内核中完成磁盘到网卡的数据复制

image.png

零拷贝就是操作系统提供的新函数(sendfile)，同时接收文件描述符和 TCP socket 作为输入参数，这样执行时就可以完全在内核态完成内存拷贝，既减少了内存拷贝次数，也降低了上下文切换次数。

而且，零拷贝取消了用户缓冲区后，不只降低了用户内存的消耗，还通过最大化利用 socket 缓冲区中的内存，间接地再一次减少了系统调用的次数，从而带来了大幅减少上下文切换次数的机会！

应用读取磁盘写入网络的时候还得考虑缓存的大小，一般会设置的比较小，这样一个大文件导致多次小批量的读取，每次读取伴随着多次上下文切换。

零拷贝使我们不必关心 socket 缓冲区的大小（socket缓冲区大小本身默认就是动态调整、或者应用代码指定大小）。比如，调用零拷贝发送方法时，尽可以把发送字节数设为文件的所有未发送字节数，例如 320MB，也许此时 socket 缓冲区大小为 1.4MB，那么一次性就会发送 1.4MB 到客户端，而不是只有 32KB。这意味着对于 1.4MB 的 1 次零拷贝，仅带来 2 次上下文切换，而不使用零拷贝且用户缓冲区为 32KB 时，经历了 176 次（4 * 1.4MB/32KB）上下文切换。

read+write 和零拷贝优化

1
2
read(file, tmp_buf, len);
write(socket, tmp_buf, len);

image-20201104175056589

通过mmap替换read优化一下

用 mmap() 替换原先的 read()，mmap() 也即是内存映射（memory map）：把用户进程空间的一段内存缓冲区（user buffer）映射到文件所在的内核缓冲区（kernel buffer）上。

image.png

通过使用 mmap() 来代替 read()， 可以减少一次数据拷贝的过程。

但这还不是最理想的零拷贝，因为首先仍然需要通过 CPU 把内核缓冲区的数据拷贝到 socket 缓冲区里，而且仍然需要 4 次上下文切换，因为系统调用还是 2 次；另外内存映射技术是一个开销很大的虚拟存储操作：这种操作需要修改页表以及用内核缓冲区里的文件数据汰换掉当前 TLB 里的缓存以维持虚拟内存映射的一致性。

sendfile

在 Linux 内核版本 2.1 中，提供了一个专门发送文件的系统调用函数 sendfile()，函数形式如下：

1
2
#include <sys/socket.h>
ssize_t sendfile(int out_fd, int in_fd, off_t *offset, size_t count);

它的前两个参数分别是目的端和源端的文件描述符，后面两个参数是源端的偏移量和复制数据的长度，返回值是实际复制数据的长度。

首先，它可以替代前面的 read() 和 write() 这两个系统调用，这样就可以减少一次系统调用，也就减少了 2 次上下文切换的开销。

其次，该系统调用，可以直接把内核缓冲区里的数据拷贝到 socket 缓冲区里，不再拷贝到用户态，这样就只有 2 次上下文切换，和 3 次数据拷贝。如下图：

image.png

当然这里还是有一次CPU来拷贝内存的过程，仍然有文件截断的问题。sendfile() 依然是一个适用性很窄的技术，最适合的场景基本也就是一个静态文件服务器了。

然而 sendfile() 本身是有很大问题的，从不同的角度来看的话主要是：

  1. 首先一个是这个接口并没有进行标准化，导致 sendfile() 在 Linux 上的接口实现和其他类 Unix 系统的实现并不相同；
  2. 其次由于网络传输的异步性，很难在接收端实现和 sendfile() 对接的技术，因此接收端一直没有实现对应的这种技术；
  3. 最后从性能方面考量，因为 sendfile() 在把磁盘文件从内核缓冲区（page cache）传输到到套接字缓冲区的过程中依然需要 CPU 参与，这就很难避免 CPU 的高速缓存被传输的数据所污染。

SG-DMA（The Scatter-Gather Direct Memory Access）技术

上一小节介绍的 sendfile() 技术已经把一次数据读写过程中的 CPU 拷贝的降低至只有 1 次了，但是人永远是贪心和不知足的，现在如果想要把这仅有的一次 CPU 拷贝也去除掉，有没有办法呢？

当然有！通过引入一个新硬件上的支持，我们可以把这个仅剩的一次 CPU 拷贝也给抹掉：Linux 在内核 2.4 版本里引入了 DMA 的 scatter/gather – 分散/收集功能，并修改了 sendfile() 的代码使之和 DMA 适配。scatter 使得 DMA 拷贝可以不再需要把数据存储在一片连续的内存空间上，而是允许离散存储，gather 则能够让 DMA 控制器根据少量的元信息：一个包含了内存地址和数据大小的缓冲区描述符，收集存储在各处的数据，最终还原成一个完整的网络包，直接拷贝到网卡而非套接字缓冲区，避免了最后一次的 CPU 拷贝：

image.png

如果网卡支持 SG-DMA（The Scatter-Gather Direct Memory Access）技术（和普通的 DMA 有所不同），我们可以进一步减少通过 CPU 把内核缓冲区里的数据拷贝到 socket 缓冲区的过程。

这就是所谓的零拷贝（Zero-copy）技术，因为我们没有在内存层面去拷贝数据，也就是说全程没有通过 CPU 来搬运数据，所有的数据都是通过 DMA 来进行传输的。 数据传输过程就再也没有 CPU 的参与了，也因此 CPU 的高速缓存再不会被污染了，也不再需要 CPU 来计算数据校验和了，CPU 可以去执行其他的业务计算任务，同时和 DMA 的 I/O 任务并行，此举能极大地提升系统性能。

零拷贝技术的文件传输方式相比传统文件传输的方式，减少了 2 次上下文切换和数据拷贝次数，只需要 2 次上下文切换和数据拷贝次数，就可以完成文件的传输，而且 2 次的数据拷贝过程，都不需要通过 CPU，2 次都是由 DMA 来搬运。

所以，总体来看，零拷贝技术可以把文件传输的性能提高至少一倍以上。

splice()

sendfile() + DMA Scatter/Gather 的零拷贝方案虽然高效，但是也有两个缺点：

  1. 这种方案需要引入新的硬件支持；
  2. 虽然 sendfile() 的输出文件描述符在 Linux kernel 2.6.33 版本之后已经可以支持任意类型的文件描述符，但是输入文件描述符依然只能指向文件。

这两个缺点限制了 sendfile() + DMA Scatter/Gather 方案的适用场景。为此，Linux 在 2.6.17 版本引入了一个新的系统调用 splice()，它在功能上和 sendfile() 非常相似，但是能够实现在任意类型的两个文件描述符时之间传输数据；而在底层实现上，splice()又比 sendfile() 少了一次 CPU 拷贝，也就是等同于 sendfile() + DMA Scatter/Gather，完全去除了数据传输过程中的 CPU 拷贝。

splice() 所谓的写入数据到管道其实并没有真正地拷贝数据，而是玩了个 tricky 的操作：只进行内存地址指针的拷贝而不真正去拷贝数据。所以，数据 splice() 在内核中并没有进行真正的数据拷贝，因此 splice() 系统调用也是零拷贝。

还有一点需要注意，前面说过管道的容量是 16 个内存页，也就是 16 * 4KB = 64 KB，也就是说一次往管道里写数据的时候最好不要超过 64 KB，否则的话会 splice() 会阻塞住，除非在创建管道的时候使用的是 pipe2() 并通过传入 O_NONBLOCK 属性将管道设置为非阻塞。

send() with MSG_ZEROCOPY

Linux 内核在 2017 年的 v4.14 版本接受了来自 Google 工程师 Willem de Bruijn 在 TCP 网络报文的通用发送接口 send() 中实现的 zero-copy 功能 (MSG_ZEROCOPY) 的 patch，通过这个新功能，用户进程就能够把用户缓冲区的数据通过零拷贝的方式经过内核空间发送到网络套接字中去，这个新技术和前文介绍的几种零拷贝方式相比更加先进，因为前面几种零拷贝技术都是要求用户进程不能处理加工数据而是直接转发到目标文件描述符中去的。Willem de Bruijn 在他的论文里给出的压测数据是：采用 netperf 大包发送测试，性能提升 39%，而线上环境的数据发送性能则提升了 5%~8%，官方文档陈述说这个特性通常只在发送 10KB 左右大包的场景下才会有显著的性能提升。一开始这个特性只支持 TCP，到内核 v5.0 版本之后才支持 UDP。

这个技术是基于 redhat 红帽在 2010 年给 Linux 内核提交的 virtio-net zero-copy 技术之上实现的，至于底层原理，简单来说就是通过 send() 把数据在用户缓冲区中的分段指针发送到 socket 中去，利用 page pinning 页锁定机制锁住用户缓冲区的内存页，然后利用 DMA 直接在用户缓冲区通过内存地址指针进行数据读取，实现零拷贝

目前来说，这种技术的主要缺陷有：

  1. 只适用于大文件 (10KB 左右) 的场景，小文件场景因为 page pinning 页锁定和等待缓冲区释放的通知消息这些机制，甚至可能比直接 CPU 拷贝更耗时；
  2. 因为可能异步发送数据，需要额外调用 poll() 和 recvmsg() 系统调用等待 buffer 被释放的通知消息，增加代码复杂度，以及会导致多次用户态和内核态的上下文切换；
  3. MSG_ZEROCOPY 目前只支持发送端，接收端暂不支持。

零拷贝应用

kafka就利用了「零拷贝」技术，从而大幅提升了 I/O 的吞吐率，这也是 Kafka 在处理海量数据为什么这么快的原因之一(利用磁盘顺序写；PageCache)。

非零拷贝代码：

1
2
File.read(fileDesc, buf, len);
Socket.send(socket, buf, len);

Traditional data copying approach：

Traditional data copying approach

Traditional context switches：

Traditional context switches

如果你追溯 Kafka 文件传输的代码，你会发现，最终它调用了 Java NIO 库里的 transferTo 方法：

1
2
3
4
@Overridepublic 
long transferFrom(FileChannel fileChannel, long position, long count) throws IOException { 
    return fileChannel.transferTo(position, count, socketChannel);
}

Data copy with transferTo()

Data copy with transferTo()

Context switching with transferTo()：

Context switching when using transferTo()

Data copies when transferTo() and gather operations are used

Data copies when transferTo() and gather operations are used

如果 Linux 系统支持 sendfile() 系统调用，那么 transferTo() 实际上最后就会使用到 sendfile() 系统调用函数。

Nginx 也支持零拷贝技术，一般默认是开启零拷贝技术，这样有利于提高文件传输的效率，是否开启零拷贝技术的配置如下：

1
2
3
4
5
http {
...
    sendfile on
...
}

sendfile 配置的具体意思:

  • 设置为 on 表示，使用零拷贝技术来传输文件：sendfile ，这样只需要 2 次上下文切换，和 2 次数据拷贝。
  • 设置为 off 表示，使用传统的文件传输技术：read + write，这时就需要 4 次上下文切换，和 4 次数据拷贝。

如果是大文件很容易消耗非常多的PageCache，不推荐使用PageCache（或者说零拷贝），建议使用异步IO+直接IO。

在 nginx 中，我们可以用如下配置，来根据文件的大小来使用不同的方式：

1
2
3
4
5
location /video/ { 
    sendfile on; 
    aio on; 
    directio 1024m; 
}

当文件大小大于 directio 值后，使用「异步 I/O + 直接 I/O」，否则使用「零拷贝技术」。

零拷贝性能

如果用零拷贝和不用零拷贝来做一个文件服务器，来对比下他们的性能

Performance comparison: Traditional approach vs. zero copy

File size Normal file transfer (ms) transferTo (ms)
7MB 156 45
21MB 337 128
63MB 843 387
98MB 1320 617
200MB 2124 1150
350MB 3631 1762
700MB 13498 4422
1GB 18399 8537

DMA

什么是 DMA 技术？简单理解就是，在进行 I/O 设备和内存的数据传输的时候，数据搬运的工作全部交给 DMA 控制器，而 CPU 不再参与任何与数据搬运相关的事情，这样 CPU 就可以去处理别的事务

RDMA

remote DMA

参考资料

https://www.atatech.org/articles/66885

https://cloud.tencent.com/developer/article/1087455

https://www.cnblogs.com/xiaolincoding/p/13719610.html

https://mp.weixin.qq.com/s/dZNjq05q9jMFYhJrjae_LA 从Linux内存管理到零拷贝

Efficient data transfer through zero copy

CPU：一个故事看懂DMA

Memory

Linux内存--管理和碎片

Linux内存–管理和碎片

本系列有如下几篇

[Linux 内存问题汇总](/2020/01/15/Linux 内存问题汇总/)

Linux内存–PageCache

Linux内存–管理和碎片

Linux内存–HugePage

Linux内存–零拷贝

物理结构分析

内存从物理结构上面分为：Channel > DIMM（对应物理上售卖的内存条） >Rank > Chip > Bank > Row/Column。

Chip就是DRAM芯片，一个chip里面会有很多bank。每个bank就是数据存储的实体，相当于一个二维矩阵，只要声明了column和row就可以从每个bank中取出8bit的数据。

具体可以看如下图，一个通道Channel可以是一个DIMM也可以是两个DIMM，甚至3个DIMM，图中是2个DIMM。

image-20211222135852796

虚拟内存和物理内存

进程所操作的内存是一个虚拟内存，由OS来将这块虚拟内存映射到实际的物理内存上，这样做的好处是每个进程可以独占 128T 内存，任意地使用，系统上还运行了哪些进程已经与我们完全没有关系了（不需要考虑和其它进程之间的地址会冲突）。为变量和函数分配地址的活，我们交给链接器去自动安排就可以了。这一切都是因为虚拟内存能够提供内存地址空间的隔离，极大地扩展了可用空间。

操作系统管理着这种映射关系，所以你在写代码的时候，就不用再操心物理内存的使用情况了，你看到的内存就是虚拟内存。无论一个进程占用的内存资源有多大，在任一时刻，它需要的物理内存都是很少的。在这个推论的基础上，CPU 为每个进程只需要保留很少的物理内存就可以保证进程的正常执行了。

当程序中使用 malloc 等分配内存的接口时会将内存从待分配状态变成已分配状态，此时这块分配好的内存还没有真正映射到对应的物理内存上，这块内存就是未映射状态，因为它并没有被映射到相应的物理内存，直到对该块内存进行读写时，操作系统才会真正地为它分配物理内存。然后这个页面才能成为正常页面。

i7 处理器的页表也是存储在内存页里的，每个页表项都是 4 字节。所以，人们就将 1024 个页表项组成一张页表。这样一张页表的大小就刚好是 4K，占据一个内存页，这样就更加方便管理。而且，当前市场上主流的处理器也都选择将页大小定为 4K。

虚拟地址在计算机体系结构里可以评为特优的一项技术；超线程、流水线、多发射只是优；cache则只是良好（成本高）

CPU 如何找到真实地址

image-20211107175201297

  • 第一步是确定页目录基址。每个 CPU 都有一个页目录基址寄存器，最高级页表的基地址就存在这个寄存器里。在 X86 上，这个寄存器是 CR3。每一次计算物理地址时，MMU 都会从 CR3 寄存器中取出页目录所在的物理地址。
  • 第二步是定位页目录项（PDE）。一个 32 位的虚拟地址可以拆成 10 位，10 位和 12 位三段，上一步找到的页目录表基址加上高 10 位的值乘以 4，就是页目录项的位置。这是因为，一个页目录项正好是 4 字节，所以 1024 个页目录项共占据 4096 字节，刚好组成一页，而 1024 个页目录项需要 10 位进行编码。这样，我们就可以通过最高 10 位找到该地址所对应的 PDE 了。
  • 第三步是定位页表项（PTE）。页目录项里记录着页表的位置，CPU 通过页目录项找到页表的位置以后，再用中间 10 位计算页表中的偏移，可以找到该虚拟地址所对应的页表项了。页表项也是 4 字节的，所以一页之内刚好也是 1024 项，用 10 位进行编码。所以计算公式与上一步相似，用页表基址加上中间 10 位乘以 4，可以得到页表项的地址。
  • 最后一步是确定真实的物理地址。上一步 CPU 已经找到页表项了，这里存储着物理地址，这才真正找到该虚拟地址所对应的物理页。虚拟地址的低 12 位，刚好可以对一页内的所有字节进行编码，所以我们用低 12 位来代表页内偏移。计算的公式是物理页的地址直接加上低 12 位。

前面我们分析的是 32 位操作系统，那对于 64 位机器是不是有点不同呢？在 64 位的机器上，使用了 48 位的虚拟地址，所以它需要使用 4 级页表。它的结构与 32 位的 3 级页表是相似的，只是多了一级页目录，定位的过程也从 32 位的 4 步变成了 5 步。

image-20211107182305732

8086最开始是按不同的作用将内存分为代码段、数据段等，386开始按页开始管理内存（混合有按段管理）。 现代的操作系统都是采用段式管理来做基本的权限管理，而对于内存的分配、回收、调度都是依赖页式管理。

tlab miss

tlb：从各级cache里分配的一块专用空间，用来存放页表(虚拟地址和物理地址的对应关系)–存放在CPU cache里的索引

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#x86info -c
Monitor/Mwait: min/max line size 64/64, ecx bit 0 support, enumeration extension
SVM: revision 1, 32768 ASIDs
Address Size: 48 bits virtual, 48 bits physical
The physical package has 96 of 32768 possible cores implemented.
L1 Data TLB (1G):           Fully associative. 64 entries.
L1 Instruction TLB (1G):    Fully associative. 64 entries.
L1 Data TLB (2M/4M):        Fully associative. 64 entries.
L1 Instruction TLB (2M/4M): Fully associative. 64 entries.
L1 Data TLB (4K):           Fully associative. 64 entries.
L1 Instruction TLB (4K):    Fully associative. 64 entries.
L1 Data cache:
	Size: 32Kb	8-way associative.
	lines per tag=1	line size=64 bytes.
L1 Instruction cache:
	Size: 32Kb	8-way associative.
	lines per tag=1	line size=64 bytes.
L2 Data TLB (1G):           Fully associative. 64 entries.
L2 Instruction TLB (1G):    Disabled. 0 entries.
L2 Data TLB (2M/4M):        4-way associative. 2048 entries.
L2 Instruction TLB (2M/4M): 2-way associative. 512 entries.
L2 Data TLB (4K):           8-way associative. 2048 entries.
L2 Instruction TLB (4K):    4-way associative. 512 entries.
L2 cache:
	Size: 512Kb	8-way associative.
	lines per tag=1	line size=64 bytes.

 running at an estimated 2.55GHz

image-20220928160318893

TLB(Translation Lookaside Buffer) Cache用于缓存少量热点内存地址的mapping关系。TLB和L1一样每个core独享，由于制造成本和工艺的限制，响应时间需要控制在CPU Cycle级别的Cache容量只能存储几十个对象。那么TLB Cache在应对大量热点数据Virual Address转换的时候就显得捉襟见肘了。我们来算下按照标准的Linux页大小(page size) 4K，一个能缓存64元素的TLB Cache只能涵盖4K*64 = 256K的热点数据的内存地址，显然离理想非常遥远的。于是Huge Page就产生了。

These are typical performance levels of a TLB:

  • Size: 12 bits – 4,096 entries
  • Hit time: 0.5 – 1 clock cycle
  • Miss penalty: 10 – 100 clock cycles
  • Miss rate: 0.01 – 1% (20–40% for sparse/graph applications)

TLB也分为iTLB和dTLB, 分别顶在L1i和L1d前面（比L1更小更快，每个core独享tlb）

img

以intel x86为例，一个cpu也就32到64个tlb, 超出这个范畴，就得去查页表。 每个型号的cpu都不一样，需要查看spec

进程分配到的不是内存的实际物理地址，而是一个经过映射后的虚拟地址，这么做的原因是为了让每个应用可以独享完整的虚拟地址，而不需要每个进程互相考虑使用内存的协调。

但是虚拟地址到物理地址的映射需要巨大的映射空间，如何用更少的内存消耗来管理庞大的内存（如果没有分级，4G内存对应着4MB的索引空间，一级比如使用4K就够了，多个二级使总共用4M，但是这4M大部分时候不用提前分配），Linux通过四级表项来做虚拟地址到物理地址的映射，这样4Kb就能管理256T内存，4级映射是时间换空间的典型案例。不过一般而言一个进程是远远用不了256T内存的，那么这四级映射大部分时候都是没必要的，所以实际用不了那么大的PageTable。

虚拟内存的核心原理是：为每个程序设置一段”连续”的虚拟地址空间，把这个地址空间分割成多个具有连续地址范围的页 (page)，并把这些页和物理内存做映射，在程序运行期间动态映射到物理内存。当程序引用到一段在物理内存的地址空间时，由硬件立刻执行必要的映射；而当程序引用到一段不在物理内存中的地址空间时，由操作系统负责将缺失的部分装入物理内存并重新执行失败的指令：

img

在 内存管理单元（Memory Management Unit，MMU）进行地址转换时，如果页表项的 “在/不在” 位是 0，则表示该页面并没有映射到真实的物理页框，则会引发一个缺页中断，CPU 陷入操作系统内核，接着操作系统就会通过页面置换算法选择一个页面将其换出 (swap)，以便为即将调入的新页面腾出位置，如果要换出的页面的页表项里的修改位已经被设置过，也就是被更新过，则这是一个脏页 (dirty page)，需要写回磁盘更新改页面在磁盘上的副本，如果该页面是”干净”的，也就是没有被修改过，则直接用调入的新页面覆盖掉被换出的旧页面即可。

还需要了解的一个概念是转换检测缓冲器（Translation Lookaside Buffer，TLB，每个core一个TLB，类似L1 cache），也叫快表，是用来加速虚拟地址映射的，因为虚拟内存的分页机制，页表一般是保存内存中的一块固定的存储区，导致进程通过 MMU 访问内存比直接访问内存多了一次内存访问，性能至少下降一半，因此需要引入加速机制，即 TLB 快表，TLB 可以简单地理解成页表的高速缓存，保存了最高频被访问的页表项，由于一般是硬件实现的，因此速度极快，MMU 收到虚拟地址时一般会先通过硬件 TLB 查询对应的页表号，若命中且该页表项的访问操作合法，则直接从 TLB 取出对应的物理页框号返回，若不命中则穿透到内存页表里查询，并且会用这个从内存页表里查询到最新页表项替换到现有 TLB 里的其中一个，以备下次缓存命中。

如果没有TLB那么每一次内存映射都需要查表四次然后才是一次真正的内存访问，代价比较高。

有了TLB之后，CPU访问某个虚拟内存地址的过程如下

  1. CPU产生一个虚拟地址
  2. MMU从TLB中获取页表，翻译成物理地址
  3. MMU把物理地址发送给L1/L2/L3/内存
  4. L1/L2/L3/内存将地址对应数据返回给CPU

由于第2步是类似于寄存器的访问速度，所以如果TLB能命中，则虚拟地址到物理地址的时间开销几乎可以忽略。tlab miss比较高的话开启内存大页对性能是有提升的，但是会有一定的内存浪费。

内存布局

  • 代码段：CPU 运行一个程序，实质就是在顺序执行该程序的机器码。一个程序的机器码会被组织到同一个地方。
  • 数据段：程序在运行过程中必然要操作数据。这其中，对于有初值的变量，它的初始值会存放在程序的二进制文件中，而且，这些数据部分也会被装载到内存中，即程序的数据段。数据段存放的是程序中已经初始化且不为 0 的全局变量和静态变量。
  • BSS 段: 对于未初始化的全局变量和静态变量，因为编译器知道它们的初始值都是 0，因此便不需要再在程序的二进制映像中存放这么多 0 了，只需要记录他们的大小即可，这便是BSS段 。BSS 段这个缩写名字是 Block Started by Symbol，但很多人可能更喜欢把它记作 Better Save Space 的缩写。
  • 堆是程序员可以自由申请的空间，当我们在写程序时要保存数据，优先会选择堆；
  • 栈是函数执行时的活跃记录，这将是我们下一节课要重点分析的内容。

数据段和 BSS 段里存放的数据也只能是部分数据，主要是全局变量和静态变量，但程序在运行过程中，仍然需要记录大量的临时变量，以及运行时生成的变量，这里就需要新的内存区域了，即程序的堆空间跟栈空间。与代码段以及数据段不同的是，堆和栈并不是从磁盘中加载，它们都是由程序在运行的过程中申请，在程序运行结束后释放。

总的来说，一个程序想要运行起来所需要的几块基本内存区域：代码段、数据段、BSS 段、堆空间和栈空间。下面就是内存布局的示意图：

image-20211108115717113

其它内存形态：

  • 存放加载的共享库的内存空间：如果一个进程依赖共享库，那对应的，该共享库的代码段、数据段、BSS 段也需要被加载到这个进程的地址空间中。
  • 共享内存段：我们可以通过系统调用映射一块匿名区域作为共享内存，用来进行进程间通信。
  • 内存映射文件：我们也可以将磁盘的文件映射到内存中，用来进行文件编辑或者是类似共享内存的方式进行进程通信。

32位 x86机器下，通过 cat /proc/pid/maps 看到的进程所使用的内存分配空间：

image-20211108120532370

64位 x86机器下，通过 cat /proc/pid/maps 看到的进程所使用的内存分配空间：

image-20211108120718732

目前的 64 系统下的寻址空间是 2^48(太多用不完，高16位为Canonical空间），即 256TB。而且根据 canonical address 的划分，地址空间天然地被分割成两个区间，分别是 0x0 - 0x00007fffffffffff 和 0xffff800000000000 - 0xffffffffffffffff。这样就直接将低 128T 的空间划分为用户空间，高 128T 划分为内核空间。

brk:内核维护指向堆的顶部

Java程序对应的maps：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
#cat /proc/14011/maps
00400000-00401000 r-xp 00000000 08:03 3935494                            /opt/taobao/install/ajdk-8.3.6_fp9-b30/bin/java
00600000-00601000 rw-p 00000000 08:03 3935494                            /opt/taobao/install/ajdk-8.3.6_fp9-b30/bin/java
ed400000-1001e0000 rw-p 00000000 00:00 0
1001e0000-140000000 ---p 00000000 00:00 0
7f86e8000000-7f8a7fc00000 rw-p 00000000 00:00 0
..
7f8aaecfa000-7f8aaeff8000 rw-p 00000000 00:00 0
7f8aaeff8000-7f8aaf000000 r-xp 00000000 08:03 3935973                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libmanagement.so
7f8aaf000000-7f8aaf1ff000 ---p 00008000 08:03 3935973                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libmanagement.so
7f8aaf1ff000-7f8aaf200000 rw-p 00007000 08:03 3935973                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libmanagement.so
..
7f8ad8cea000-7f8ad8cec000 r--s 00004000 08:05 7078938                    /home/admin/drds-worker/lib/netty-handler-proxy-4.1.17.Final.jar
7f8ad8cec000-7f8ad8cf5000 r--s 0006f000 08:05 7078952                    /home/admin/drds-worker/lib/log4j-1.2.17.jar
7f8ad8cf5000-7f8ad8cf7000 r--s 00005000 08:05 7078960                    /home/admin/drds-worker/lib/objenesis-1.0.jar
7f8ad8cf7000-7f8ad8cff000 r--s 0004b000 08:05 7078929                    /home/admin/drds-worker/lib/spring-aop-3.2.18.RELEASE.jar
7f8ad8cff000-7f8ad8d00000 ---p 00000000 00:00 0
7f8ad8d00000-7f8ad9000000 rw-p 00000000 00:00 0
7f8ad90e3000-7f8ad90ef000 r--s 000b6000 08:05 7079066                    /home/admin/drds-worker/lib/transmittable-thread-local-2.5.1.jar
7f8ad9dd8000-7f8ad9dfe000 r--s 0026f000 08:05 7078997                    /home/admin/drds-worker/lib/druid-1.1.7-preview_12.jar
7f8ad9dfe000-7f8ad9dff000 ---p 00000000 00:00 0
7f8ad9dff000-7f8ad9eff000 rw-p 00000000 00:00 0
7f8ad9eff000-7f8ad9f00000 ---p 00000000 00:00 0
7f8ad9f00000-7f8ada200000 rw-p 00000000 00:00 0
7f8ada200000-7f8ada202000 r--s 00003000 08:05 7078944                    /home/admin/drds-worker/lib/liberate-rest-1.0.2.jar
7f8ada202000-7f8ada206000 r--s 00036000 08:05 7078912                    /home/admin/drds-worker/lib/jackson-core-lgpl-1.9.6.jar
7f8ada289000-7f8ada28b000 r--s 00001000 08:05 7078998                    /home/admin/drds-worker/lib/opencensus-contrib-grpc-metrics-0.10.0.jar
7f8ada2b5000-7f8ada2b9000 r--s 0003a000 08:05 7079099                    /home/admin/drds-worker/lib/tddl-repo-mysql-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8ada2b9000-7f8ada2c6000 r--s 0007d000 08:05 7078982                    /home/admin/drds-worker/lib/grpc-core-1.9.0.jar
7f8ada2c6000-7f8ada2d6000 r--s 00149000 08:05 7079000                    /home/admin/drds-worker/lib/protobuf-java-3.5.1.jar
7f8ada2d6000-7f8ada2db000 r--s 0002b000 08:05 7078927                    /home/admin/drds-worker/lib/tddl-net-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8ada2db000-7f8ada2e0000 r--s 0002a000 08:05 7078939                    /home/admin/drds-worker/lib/grpc-netty-1.9.0.jar
7f8ada2e0000-7f8ada2ff000 r--s 00150000 08:05 7078965                    /home/admin/drds-worker/lib/mockito-core-1.9.5.jar
7f8ada2ff000-7f8ada300000 ---p 00000000 00:00 0
7f8ada300000-7f8ada600000 rw-p 00000000 00:00 0
7f8ada600000-7f8ada601000 r--s 00003000 08:05 7079089                    /home/admin/drds-worker/lib/ushura-1.0.jar
7f8ae9ba2000-7f8ae9baa000 r-xp 00000000 08:03 3935984                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libzip.so
7f8ae9baa000-7f8ae9da9000 ---p 00008000 08:03 3935984                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libzip.so
7f8ae9da9000-7f8ae9daa000 rw-p 00007000 08:03 3935984                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libzip.so
7f8ae9daa000-7f8ae9db6000 r-xp 00000000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9db6000-7f8ae9fb5000 ---p 0000c000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9fb5000-7f8ae9fb6000 r--p 0000b000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9fb6000-7f8ae9fb7000 rw-p 0000c000 08:03 1837851                    /usr/lib64/libnss_files-2.17.so;614d5f07 (deleted)
7f8ae9fb7000-7f8ae9fbd000 rw-p 00000000 00:00 0
7f8ae9fbd000-7f8ae9fe7000 r-xp 00000000 08:03 3935961                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/jre/lib/amd64/libjava.so
7f8aebc03000-7f8aebc05000 r--s 00008000 08:05 7079098                    /home/admin/drds-worker/lib/grpc-stub-1.9.0.jar
7f8aebc05000-7f8aebc07000 r--s 00020000 08:05 7078930                    /home/admin/drds-worker/lib/tddl-group-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8aebc07000-7f8aebc1f000 r--s 001af000 08:05 7079085                    /home/admin/drds-worker/lib/aspectjweaver-1.8.5.jar
7f8aebc1f000-7f8aebc20000 ---p 00000000 00:00 0
7f8aebc20000-7f8aebd20000 rw-p 00000000 00:00 0
7f8aebd20000-7f8aebd35000 r-xp 00000000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebd35000-7f8aebf34000 ---p 00015000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebf34000-7f8aebf35000 r--p 00014000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebf35000-7f8aebf36000 rw-p 00015000 08:03 1837234                    /usr/lib64/libgcc_s-4.8.5-20150702.so.1
7f8aebf36000-7f8aec037000 r-xp 00000000 08:03 1837579                    /usr/lib64/libm-2.17.so;614d5f07 (deleted)
7f8aec037000-7f8aec236000 ---p 00101000 08:03 1837579                    /usr/lib64/libm-2.17.so;614d5f07 (deleted)
7f8aeca17000-7f8aeca18000 rw-p 0000d000 08:03 3936057                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/jli/libjli.so
7f8aeca18000-7f8aeca2d000 r-xp 00000000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aeca2d000-7f8aecc2c000 ---p 00015000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aecc2c000-7f8aecc2d000 r--p 00014000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aecc2d000-7f8aecc2e000 rw-p 00015000 08:03 1836998                    /usr/lib64/libz.so.1.2.7
7f8aecc2e000-7f8aecc45000 r-xp 00000000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aecc45000-7f8aece44000 ---p 00017000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aece44000-7f8aece45000 r--p 00016000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aece45000-7f8aece46000 rw-p 00017000 08:03 1836993                    /usr/lib64/libpthread-2.17.so;614d5f07 (deleted)
7f8aece46000-7f8aece4a000 rw-p 00000000 00:00 0
7f8aece4a000-7f8aecea1000 r-xp 00000000 08:03 3936059                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/libjemalloc.so.2
7f8aecea1000-7f8aed0a0000 ---p 00057000 08:03 3936059                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/libjemalloc.so.2
7f8aed0a0000-7f8aed0a3000 rw-p 00056000 08:03 3936059                    /opt/taobao/install/ajdk-8.3.6_fp9-b30/lib/amd64/libjemalloc.so.2
7f8aed0a3000-7f8aed0b5000 rw-p 00000000 00:00 0
7f8aed0b5000-7f8aed0d7000 r-xp 00000000 08:03 1837788                    /usr/lib64/ld-2.17.so;614d5f07 (deleted)
7f8aed0d7000-7f8aed0dc000 r--s 00038000 08:05 7079012                    /home/admin/drds-worker/lib/org.osgi.core-4.2.0.jar
7f8aed0dc000-7f8aed0e1000 r--s 00038000 08:05 7079018                    /home/admin/drds-worker/lib/commons-beanutils-1.9.3.jar
7f8aed0e1000-7f8aed0e3000 r--s 00001000 08:05 7079033                    /home/admin/drds-worker/lib/j2objc-annotations-1.1.jar
7f8aed0e3000-7f8aed0e8000 r--s 00017000 08:05 7079056                    /home/admin/drds-worker/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
7f8aed1be000-7f8aed1c6000 rw-s 00000000 08:04 393222                     /tmp/hsperfdata_admin/14011
7f8aed1c6000-7f8aed1ca000 ---p 00000000 00:00 0
7f8aed1ca000-7f8aed2cd000 rw-p 00000000 00:00 0
7f8aed2cd000-7f8aed2ce000 r--s 00005000 08:05 7079029                    /home/admin/drds-worker/lib/jersey-apache-connector-2.26.jar
7f8aed2ce000-7f8aed2d1000 r--s 0000a000 08:05 7079027                    /home/admin/drds-worker/lib/metrics-jvm-1.7.4.jar
7f8aed2d1000-7f8aed2d3000 r--s 00006000 08:05 7078961                    /home/admin/drds-worker/lib/tddl-client-5.2.7-2-EXTEND-HOTMAPPING-SNAPSHOT.jar
7f8aed2d3000-7f8aed2d4000 rw-p 00000000 00:00 0
7f8aed2d4000-7f8aed2d5000 r--p 00000000 00:00 0
7f8aed2d5000-7f8aed2d6000 rw-p 00000000 00:00 0
7f8aed2d6000-7f8aed2d7000 r--p 00021000 08:03 1837788                    /usr/lib64/ld-2.17.so;614d5f07 (deleted)
7f8aed2d7000-7f8aed2d8000 rw-p 00022000 08:03 1837788                    /usr/lib64/ld-2.17.so;614d5f07 (deleted)
7f8aed2d8000-7f8aed2d9000 rw-p 00000000 00:00 0
7fff087e0000-7fff08801000 rw-p 00000000 00:00 0                          [stack]
7fff089c2000-7fff089c4000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

内存管理和使用

malloc

malloc()分配内存时：

  • 如果用户分配的内存小于 128 KB，则通过 brk() 申请内存–在堆顶分配；
  • 如果用户分配的内存大于 128 KB，则通过 mmap() 申请内存–从文件映射区域分配；

图片

图片

对于 「malloc 申请的内存，free 释放内存会归还给操作系统吗？」：

  • malloc 通过 brk() 方式申请的内存，free 释放内存的时候，并不会把内存归还给操作系统，而是缓存在 malloc 的内存池中，待下次使用–小内存分配避免反复调用系统操作导致上下文切换，缺点是没回收容易导致内存碎片进而浪费内存。brk分配出来的内存在maps中显示有heap字样；
  • malloc 通过 mmap() 方式申请的内存，free 释放内存的时候，会把内存归还给操作系统，内存得到真正的释放。并且mmap分配的虚拟内存都是缺页状态的。

malloc和mmap

glibc中的malloc/free 负责向内核批发内存（不需要每次分配都真正地去调用内核态来分配），分配好的内存按大小分成不同的桶，每次malloc的时候实际到对应的桶上摘取对应的块(slab)就好，用完free的时候挂回去。

image-20211118121500859

mmap映射内存

image-20211108122432263

私有匿名映射常用于分配内存，也就是申请堆内存

分桶式内存管理比简单算法无论是在算法效率方面，还是在碎片控制方面都有很大的提升。但它的缺陷也很明显：区域内部的使用率不够高和动态扩展能力不够好。例如，4 字节的区域提前消耗完了，但 8 字节的空闲区域还有很多，此时就会面临两难选择，如果直接分配 8 字节的区域，则区域内部浪费就比较多，如果不分配，则明明还有空闲区域，却无法成功分配。

为了解决以上问题所以搞了buddy

node->zone->buddy->slab

img

假如需要分配一块 4 字节大小的空间，但是在 4 字节的 free list 上找不到空闲区域，系统就会往上找，假如 8 字节和 16 字节的 free list 中也没有空闲区域，就会一直向上找到 32 字节的 free list。

image-20211118120823595

伙伴系统不会直接把 32 的空闲区域分配出去，因为这样做的话，会带来巨大的浪费。它会先把 32 字节分成两个 16 字节，把后边一个挂入到 16 字节的 free list 中。然后继续拆分前一半。前一半继续拆成两个 8 字节，再把后一半挂入到 8 字节的 free list，最后，把前一半 8 字节拿去分配，当然这里也要继续拆分成两个 4 字节的空闲区域，其中一个用于本次 malloc 分配，另一个则挂入到 4 字节的 free list。分配后的内存的状态如下所示：

image-20211118120851731

查看zone

The zones are:

  • DMA is the low 16 MBytes of memory. At this point it exists for historical reasons; once upon what is now a long time ago, there was hardware that could only do DMA into this area of physical memory.
  • DMA32 exists only in 64-bit Linux; it is the low 4 GBytes of memory, more or less. It exists because the transition to large memory 64-bit machines has created a class of hardware that can only do DMA to the low 4 GBytes of memory.(This is where people mutter about everything old being new again.)
  • Normal is different on 32-bit and 64-bit machines. On 64-bit machines, it is all RAM from 4GB or so on upwards. On 32-bit machines it is all RAM from 16 MB to 896 MB for complex and somewhat historical reasons. Note that this implies that machines with a 64-bit kernel can have very small amounts of Normal memory unless they have significantly more than 4GB of RAM. For example, a 2 GB machine running a 64-bit kernel will have no Normal memory at all while a 4 GB machine will have only a tiny amount of it.
  • HighMem exists only on 32-bit Linux; it is all RAM above 896 MB, including RAM above 4 GB on sufficiently large machines.

每个zone下很多pages(大小为4K)，buddy就是这些Pages的组织管理者

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
# cat /proc/zoneinfo |grep Node -A10
Node 0, zone      DMA
  pages free     3972
        min      0
        low      0
        high     0
        scanned  0
        spanned  4095
        present  3993
        managed  3972
    nr_free_pages 3972
    nr_alloc_batch 0
--
Node 0, zone    DMA32
  pages free     361132
        min      30
        low      37
        high     45
        scanned  0
        spanned  1044480
        present  430773
        managed  361133
    nr_free_pages 361132
    nr_alloc_batch 8
--
Node 0, zone   Normal
  pages free     96017308
        min      16864
        low      21080
        high     25296
        scanned  0
        spanned  200736768
        present  200736768
        managed  197571780
    nr_free_pages 96017308
    nr_alloc_batch 3807
    
# free -g
              total        used        free      shared  buff/cache   available
Mem:            755         150         367           3         236         589
Swap:             0           0           0

每个页面大小是4K，很容易可以计算出每个 zone 的大小。比如对于上面 Node0 的 Normal， 197571780 * 4K/(1024*1024) = 753 GB。

dmidecode 可以查看到服务器上插着的所有内存条，也可以看到它是和哪个CPU直接连接的。每一个CPU以及和他直连的内存条组成了一个 node（节点）

/proc/buddyinfo

/proc/buddyinfo记录了可用内存的情况。

Normal那行之后的第二列表示： 643847*2^1*Page_Size(4K) ; 第三列表示： 357451*2^2*Page_Size(4K) ，高阶内存指的是2^3及更大的内存块。

应用申请大块连续内存（高阶内存，一般之4阶及以上, 也就是64K以上–2^4*4K）时，容易导致卡顿。这是因为大块连续内存确实系统需要触发回收或者碎片整理，需要一定的时间。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
#cat /proc/buddyinfo 
Node 0, zone      DMA      1      1      1      0      2      1      1      0      1      1      3 
Node 0, zone    DMA32      2      5      3      6      2      0      4      4      2      2    404 
Node 0, zone   Normal 243430 643847 357451  32531   9508   6159   3917   2960  17172   2633  22854

如果是多node机器：
#cat /proc/buddyinfo
Node 0, zone      DMA      4      6      3      2      3      3      1      1      2      3      1
Node 0, zone    DMA32   1607   1619   1552   1520   1370   1065    827    576    284    105     13
Node 0, zone   Normal  38337 145731 222145 199776 151452  91969  38086  10037   1762    104      1
Node 1, zone   Normal  21521 147637 299185 245533 172451  81459  19451   7198    579      3      0
Node 2, zone   Normal  68427 538670 446906 229138 123555  62539  21161   4407   1122    166    274
Node 3, zone   Normal  27353  54601 114355 123568 101892  79098  48610  21036   5021    475      6
Node 4, zone   Normal  45802  42758   8573 184548 148397  70540  20772   4147    381    148    109
Node 5, zone   Normal  19514  39583 140493 167901 134774  61888  22998   6326    457     32      0
Node 6, zone   Normal 104493 378362 355158  93138  12928   2248   1019    663    172     40    121
Node 7, zone   Normal  34185 256886 249560  95547  54526  51022  28180   9757   2038   1351    280

[root@hygon8 15:50 /root]
#numactl -H
available: 8 nodes (0-7)
node 0 cpus: 0 1 2 3 4 5 6 7 64 65 66 67 68 69 70 71
node 0 size: 64083 MB
node 0 free: 49838 MB
node 1 cpus: 8 9 10 11 12 13 14 15 72 73 74 75 76 77 78 79
node 1 size: 64480 MB
node 1 free: 43596 MB
node 2 cpus: 16 17 18 19 20 21 22 23 80 81 82 83 84 85 86 87
node 2 size: 64507 MB
node 2 free: 44216 MB
node 3 cpus: 24 25 26 27 28 29 30 31 88 89 90 91 92 93 94 95
node 3 size: 64507 MB
node 3 free: 51095 MB
node 4 cpus: 32 33 34 35 36 37 38 39 96 97 98 99 100 101 102 103
node 4 size: 64507 MB
node 4 free: 32877 MB
node 5 cpus: 40 41 42 43 44 45 46 47 104 105 106 107 108 109 110 111
node 5 size: 64507 MB
node 5 free: 33430 MB
node 6 cpus: 48 49 50 51 52 53 54 55 112 113 114 115 116 117 118 119
node 6 size: 64507 MB
node 6 free: 14233 MB
node 7 cpus: 56 57 58 59 60 61 62 63 120 121 122 123 124 125 126 127
node 7 size: 63483 MB
node 7 free: 36577 MB
node distances:
node   0   1   2   3   4   5   6   7
  0:  10  16  16  16  28  28  22  28
  1:  16  10  16  16  28  28  28  22
  2:  16  16  10  16  22  28  28  28
  3:  16  16  16  10  28  22  28  28
  4:  28  28  22  28  10  16  16  16
  5:  28  28  28  22  16  10  16  16
  6:  22  28  28  28  16  16  10  16
  7:  28  22  28  28  16  16  16  10
  
[root@hygon8 15:51 /root]
#cat /proc/pagetypeinfo
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    0, zone      DMA, type    Unmovable      1      2      1      1      3      2      0      0      1      0      0
Node    0, zone      DMA, type      Movable      0      0      0      0      0      0      0      0      0      3      1
Node    0, zone      DMA, type  Reclaimable      3      4      2      1      0      1      1      1      1      0      0
Node    0, zone      DMA, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone      DMA, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type    Unmovable    151    164    162    165    140     78     19      8      0      0      0
Node    0, zone    DMA32, type      Movable   1435   1430   1374   1335   1214    974    798    563    281     98     12
Node    0, zone    DMA32, type  Reclaimable     21     25     16     20     16     13     10      5      3      7      1
Node    0, zone    DMA32, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone    DMA32, type      Isolate      0      0      0      0      0      0      0      0      0      0      0
Node    0, zone   Normal, type    Unmovable   4849   6607   4133   1629    654    121     15      3      0      0      0
Node    0, zone   Normal, type      Movable  21088 >100000 >100000 >100000 >100000  90231  37197   9379   1552     83      1
Node    0, zone   Normal, type  Reclaimable    153    139   3012   3113   2437   1617    874    655    210     21      0
Node    0, zone   Normal, type   HighAtomic      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

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 0, zone      DMA            1            6            1            0            0
Node 0, zone    DMA32           27          974           15            0            0
Node 0, zone   Normal          856        30173          709            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    1, zone   Normal, type    Unmovable    842   2898   2495   1316    490    102     23      1      2      0      0
Node    1, zone   Normal, type      Movable  22484 >100000 >100000 >100000 >100000  80084  18922   6889     48      4      0
Node    1, zone   Normal, type  Reclaimable      1   2022   3850   3534   2582   1273    506    308    529      0      0
Node    1, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    1, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 1, zone   Normal          810        31221          737            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    2, zone   Normal, type    Unmovable   2833   6802   3888   1636    329      3      1      2      0      0      0
Node    2, zone   Normal, type      Movable  72017 >100000 >100000 >100000 >100000  61710  20764   4242    841     55    239
Node    2, zone   Normal, type  Reclaimable    114      8   2056   2221   1544    826    396    163    281    111     35
Node    2, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    2, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 2, zone   Normal         1066        31063          639            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    3, zone   Normal, type    Unmovable   2508   6171   3802   1502    365     93     30      1      2      0      0
Node    3, zone   Normal, type      Movable  23396  48450 >100000 >100000  99802  77850  47910  20587   4796    428      5
Node    3, zone   Normal, type  Reclaimable     10      0    609   2111   1726   1155    670    448    223     46      1
Node    3, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    3, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 3, zone   Normal          768        31425          575            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    4, zone   Normal, type    Unmovable   3817   3739   1716    992    261     39      4      1      0      0      1
Node    4, zone   Normal, type      Movable  27857  39138   6875 >100000 >100000  70501  20752   4115    362     49    104
Node    4, zone   Normal, type  Reclaimable      1      8      3      5      0      0     16     31     19     97      4
Node    4, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    4, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 4, zone   Normal          712        31706          350            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    5, zone   Normal, type    Unmovable   4875   4728   3165   1202    464     67      3      0      0      0      0
Node    5, zone   Normal, type      Movable  18382  34874 >100000 >100000 >100000  61296  22711   6235    348     32      0
Node    5, zone   Normal, type  Reclaimable     16      0      1      7      2    525    284     91    109      0      0
Node    5, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    5, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 5, zone   Normal          736        31716          316            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    6, zone   Normal, type    Unmovable  10489   6842   2821    434    257     22      1      1      1      3      0
Node    6, zone   Normal, type      Movable  90841 >100000 >100000  92129  11336   1526    704    552    141     34    118
Node    6, zone   Normal, type  Reclaimable    434     41      0    576   1338    700    314    110     30      5      3
Node    6, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    6, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 6, zone   Normal          807        31686          275            0            0
Page block order: 9
Pages per block:  512

Free pages count per migrate type at order       0      1      2      3      4      5      6      7      8      9     10
Node    7, zone   Normal, type    Unmovable   1516   1894   2285    908    633    121     16      7      4      2      0
Node    7, zone   Normal, type      Movable  18209 >100000 >100000  93283  52811  50349  27973   9703   2026   1341    248
Node    7, zone   Normal, type  Reclaimable      0      1      0   1341   1082    552    191     47      8      8     32
Node    7, zone   Normal, type   HighAtomic      0      0      0      0      0      0      0      0      0      0      0
Node    7, zone   Normal, type      Isolate      0      0      0      0      0      0      0      0      0      0      0

Number of blocks type     Unmovable      Movable  Reclaimable   HighAtomic      Isolate
Node 7, zone   Normal         1262        31265          241            0            0

/proc/pagetypeinfo

cat /proc/pagetypeinfo, 你可以看到当前系统里伙伴系统里各个尺寸的可用连续内存块数量。unmovable pages是不可以被迁移的，比如slab等kmem都不可以被迁移，因为内核里面对这些内存很多情况下是通过指针来访问的，而不是通过页表，如果迁移的话，就会导致原来的指针访问出错。

img

当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重

alloc_pages分配内存的时候就到上面对应大小的free_area的链表上寻找可用连续页面。alloc_pages是怎么工作的呢？我们举个简单的小例子。假如要申请8K-连续两个页框的内存。为了描述方便，我们先暂时忽略UNMOVEABLE、RELCLAIMABLE等不同类型

img

基于伙伴系统的内存分配中，有可能需要将大块内存拆分成两个小伙伴。在释放中，可能会将两个小伙伴合并再次组成更大块的连续内存。

伙伴系统中的伙伴指的是两个内存块，大小相同，地址连续，同属于一个大块区域。

对于应用来说基本分配单位是4K(开启大页后一般是2M)，对于内核来说4K有点浪费。所以内核又专门给自己定制了一个更精细的内存管理系统slab。

slab

对于内核运行中实际使用的对象来说，多大的对象都有。有的对象有1K多，但有的对象只有几百、甚至几十个字节。如果都直接分配一个 4K的页面 来存储的话也太浪费了，所以伙伴系统并不能直接使用。

在伙伴系统之上，内核又给自己搞了一个专用的内存分配器， 叫slab。

这个分配器最大的特点就是，一个slab内只分配特定大小、甚至是特定的对象。这样当一个对象释放内存后，另一个同类对象可以直接使用这块内存。通过这种办法极大地降低了碎片发生的几率。

1
2
3
4
#cat /proc/meminfo
Slab:             102076 kB
SReclaimable:      70816 kB
SUnreclaim:        31260 kB
  • Slab 内核通过slab分配管理的内存总数。
  • SReclaimable 内核通过slab分配的可回收的内存（例如dentry），通过echo 2 > /proc/sys/vm/drop_caches回收。
  • SUnreclaim 内核通过slab分配的不可回收的内存。

kmem cache

slabtop和/proc/slabinfo 查看cached使用情况 主要是：pagecache（页面缓存）， dentries（目录缓存）， inodes

通过查看 /proc/slabinfo 我们可以查看到所有的 kmem cache。

img

slabtop 按占用内存从大往小进行排列。用来分析 slab 内存开销。

0d8a26db-3663-40af-b215-f8601ef23676.png (1388×1506)

无论是 /proc/slabinfo，还是 slabtop 命令的输出。里面都包含了每个 cache 中 slab的如下几个关键属性。

  • objsize：每个对象的大小

  • objperslab：一个 slab 里存放的对象的数量

  • pagesperslab：一个slab 占用的页面的数量，每个页面4K，这样也就能算出每个 slab 占用的内存大小。

比如如下TCP slabinfo中可以看到每个slab占用8(pagesperslab)个Page(8*4096=32768)，每个对象的大小是1984(objsize)，每个slab存放了16(objperslab)个对象. 那么1984 *16=31744，现在的空间基本用完，剩下接近1K，又放不下一个1984大小的对象，算是额外开销了。

1
2
3
4
#cat /proc/slabinfo |grep -E "active_objs|TCP"
# name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> : tunables <limit> <batchcount> <sharedfactor> : slabdata <active_slabs> <num_slabs> <sharedavail>
tw_sock_TCP         5372   5728    256   32    2 : tunables    0    0    0 : slabdata    179    179      0
TCP                 6090   6144   1984   16    8 : tunables    0    0    0 : slabdata    384    384      0

内存分配和延迟

内存不够、脏页太多、碎片太多，都会导致分配失败，从而触发回收，导致卡顿。

系统中脏页过多引起 load 飙高

直接回收过程中，如果存在较多脏页就可能涉及在回收过程中进行回写，这可能会造成非常大的延迟，而且因为这个过程本身是阻塞式的，所以又可能进一步导致系统中处于 D 状态的进程数增多，最终的表现就是系统的 load 值很高。

image.png

可以通过 sar -r 来观察系统中的脏页个数：

1
2
3
4
5
6
$ sar -r 1
07:30:01 PM kbmemfree kbmemused  %memused kbbuffers  kbcached  kbcommit   %commit  kbactive   kbinact   kbdirty
09:20:01 PM   5681588   2137312     27.34         0   1807432    193016      2.47    534416   1310876         4
09:30:01 PM   5677564   2141336     27.39         0   1807500    204084      2.61    539192   1310884        20
09:40:01 PM   5679516   2139384     27.36         0   1807508    196696      2.52    536528   1310888        20
09:50:01 PM   5679548   2139352     27.36         0   1807516    196624      2.51    536152   1310892        24

kbdirty 就是系统中的脏页大小，它同样也是对 /proc/vmstat 中 nr_dirty 的解析。你可以通过调小如下设置来将系统脏页个数控制在一个合理范围:

vm.dirty_background_bytes = 0

vm.dirty_background_ratio = 10

vm.dirty_bytes = 0

vm.dirty_expire_centisecs = 3000

vm.dirty_ratio = 20

至于这些值调整大多少比较合适，也是因系统和业务的不同而异，我的建议也是一边调整一边观察，将这些值调整到业务可以容忍的程度就可以了，即在调整后需要观察业务的服务质量 (SLA)，要确保 SLA 在可接受范围内。调整的效果你可以通过 /proc/vmstat 来查看：

1
2
3
#grep "nr_dirty_" /proc/vmstat
nr_dirty_threshold 3071708
nr_dirty_background_threshold 1023902

在4.20的内核并且sar 的版本为12.3.3可以看到PSI（Pressure-Stall Information）

1
2
some avg10=45.49 avg60=10.23 avg300=5.41 total=76464318
full avg10=40.87 avg60=9.05 avg300=4.29 total=58141082

你需要重点关注 avg10 这一列，它表示最近 10s 内存的平均压力情况，如果它很大（比如大于 40）那 load 飙高大概率是由于内存压力，尤其是 Page Cache 的压力引起的。

image.png

容器中的内存回收

kswapd线程(每个node一个kswapd进程，负责本node）回收内存时，可以先对脏页进行回写（writeback）再进行回收，而直接内存回收只回收干净页。也叫同步回收.

直接内存回收是在当前进程的上下文中进行的，要等内存回收完成才能继续尝试进行分配，所以是阻塞了当前进程的执行，会导致响应延迟增加

如果是在容器里，也就是在某个子memory cgroup 中，那么在分配内存后，还有一个记账（charge）的步骤，就是要把这次分配的内存页记在某个memory cgroup的账上，这样才能控制这个容器里的进程所能使用的内存数量。

在开源社区的linux代码中，如果charge 失败，也就是说，当新分配的内存加上原先的usage超过了limit，就会触发内存回收，try_to_free_mem_cgroup_pages，这个也是同步回收，等同于直接内存回收（发生在当前进程的上下文忠），所以会对应用的响应造成影响（表现为卡顿）。

碎片化

内存碎片严重的话会导致系统hang很久(回收、压缩内存）

尽量让系统的free多一点(比例高一点）可以调整 vm.min_free_kbytes(128G 以内 2G，256G以内 4G/8G), 线上机器直接修改vm.min_free_kbytes会触发回收，导致系统hang住 https://www.atatech.org/articles/163233 https://www.atatech.org/articles/97130

每个zone都有自己的min low high,如下，但是单位是page, 计算案例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
#cat /proc/zoneinfo  |grep "Node"
Node 0, zone      DMA
Node 0, zone    DMA32
Node 0, zone   Normal
Node 1, zone   Normal

#cat /proc/zoneinfo  |grep "Node 0, zone" -A10
Node 0, zone      DMA
  pages free     3975
        min      20
        low      25
        high     30
        scanned  0
        spanned  4095
        present  3996
        managed  3975
    nr_free_pages 3975
    nr_alloc_batch 5
--
Node 0, zone    DMA32
  pages free     382873
        min      2335
        low      2918
        high     3502
        scanned  0
        spanned  1044480
        present  513024
        managed  450639
    nr_free_pages 382873
    nr_alloc_batch 584
--
Node 0, zone   Normal
  pages free     11105097
        min      61463
        low      76828
        high     92194
        scanned  0
        spanned  12058624
        present  12058624
        managed  11859912
    nr_free_pages 11105097
    nr_alloc_batch 12344
    
    low = 5/4 * min
high = 3/2 * min


#T=min;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=499 MB

#T=low;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=624 MB

#T=high;sum=0;for i in `cat /proc/zoneinfo  |grep $T | awk '{print $NF}'`;do sum=`echo "$sum+$i" |bc`;done;sum=`echo "$sum*4/1024" |bc`;echo "sum=${sum} MB"
sum=802 MB

内存碎片化导致rt升高的诊断

判定方法如下：

  1. 运行 sar -B 观察 pgscand/s，其含义为每秒发生的直接内存回收次数，当在一段时间内持续大于 0 时，则应继续执行后续步骤进行排查；
  2. 运行 cat /sys/kernel/debug/extfrag/extfrag_index 观察内存碎片指数，重点关注 order >= 3 的碎片指数，当接近 1.000 时，表示碎片化严重，当接近 0 时表示内存不足；
  3. 运行 cat /proc/buddyinfo, cat /proc/pagetypeinfo 查看内存碎片情况， 指标含义参考 ，同样关注 order >= 3 的剩余页面数量，pagetypeinfo 相比 buddyinfo 展示的信息更详细一些，根据迁移类型 （伙伴系统通过迁移类型实现反碎片化）进行分组，需要注意的是，当迁移类型为 Unmovable 的页面都聚集在 order < 3 时，说明内核 slab 碎片化严重，我们需要结合其他工具来排查具体原因，在本文就不做过多介绍了；
  4. 对于 CentOS 7.6 等支持 BPF 的 kernel 也可以运行我们研发的 drsnoop，compactsnoop 工具对延迟进行定量分析，使用方法和解读方式请参考对应文档；
  5. (Opt) 使用 ftrace 抓取 mm_page_alloc_extfrag 事件，观察因内存碎片从备用迁移类型“盗取”页面的信息。

一个阿里云ECS 因为宿主机碎片导致性能衰退的案例

LVS后面三个RS在同样压力流量下，其中一个节点CPU非常高，通过top看起来是所有操作都很慢，像是CPU被降频了一样，但是直接跑CPU Prime性能又没有问题

image.png

原因：ECS所在的宿主机内存碎片比较严重，导致分配到的内存主要是4K Page，在ECS中大页场景下会慢很多

通过 openssl speed aes-256-ige 能稳定重现 在大块的加密上慢很多

image.png

小块上性能一致，这也就是为什么算Prime性能没问题。导致慢只涉及到大块内存分配的场景，这里需要映射到宿主机，但是碎片多分配慢导致了问题。

如果reboot ECS的话实际只是就地重启ECS，仍然使用的reboot前分配好的宿主机内存，不会解决问题。重启ECS中的进程也不会解决问题，只有将ECS迁移到别的物理机（也就是通过控制台重启，会重新选择物理机）才有可能解决这个问题。

或者购买新的ECS机型（比如第6代之后ECS）能避免这个问题。

ECS内部没法查看到这个碎片，只能在宿主机上通过命令查看大页情况：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
有问题NC上buddyinfo信息
$cat /proc/buddyinfo
Node 0, zone      DMA      1      1      0      0      2      1      1      0      1      1      3
Node 0, zone    DMA32     23     23     17     15     13      9      8      8      4      3    367
Node 0, zone   Normal 295291 298652 286048 266597 218191 156837  93156  45930  25856      0      0

最新建的vm，大页不多
$sudo cat /proc/9550/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
210944
------------------------
第一台正常ECS所在的NC
$cat /proc/buddyinfo
Node 0, zone      DMA      1      1      0      0      2      1      1      0      1      1      3
Node 0, zone    DMA32      7      5      5      9      8      4      6     10      5      5    366
Node 0, zone   Normal 203242 217888 184465 176280 148612 102122  55787  26642  24824      0      0

早期的vm，大页充足
$sudo cat /proc/87369/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
8275968

近期的vm，大页不够
$sudo cat /proc/22081/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
251904

$sudo cat /proc/44073/smaps |grep AnonHuge |awk '{sum+=$2}END{print sum}'
10240

内存使用分析

pmap

1
2
3
4
5
6
7
8
9
10
11
12
13
pmap -x 24282 | less
24282:   /usr/sbin/rsyslogd -n
Address           Kbytes     RSS   Dirty Mode  Mapping
000055ce1a99f000     596     580       0 r-x-- rsyslogd
000055ce1ac34000      12      12      12 r---- rsyslogd
000055ce1ac37000      28      28      28 rw--- rsyslogd
000055ce1ac3e000       4       4       4 rw---   [ anon ]
000055ce1c1f1000     364     204     204 rw---   [ anon ]
00007fff8b5a4000     132      20      20 rw---   [ stack ]
00007fff8b5e6000      12       0       0 r----   [ anon ]
00007fff8b5e9000       8       4       0 r-x--   [ anon ]
---------------- ------- ------- -------
total kB          620060   17252    3304
  • Address：占用内存的文件的内存起始地址。
  • Kbytes：占用内存的字节数。
  • RSS：实际占用内存大小。
  • Dirty：脏页大小。
  • Mapping：占用内存的文件，[anon] 为已分配的内存，[stack] 为程序堆栈

/proc/pid/

/proc/[pid]/ 下面与进程内存相关的文件主要有maps , smaps, status。
maps： 文件可以查看某个进程的代码段、栈区、堆区、动态库、内核区对应的虚拟地址
smaps: 显示每个分区更详细的内存占用数据，能看到一个动态库被共享了几次
status: 包含了所有CPU活跃的信息，该文件中的所有值都是从系统启动开始累计到当前时刻

Java内存使用分析

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
创建1000个线程，ss为2M
java -XX:NativeMemoryTracking=detail -Xms10g -Xmx10g -Xmn5g -XX:ReservedCodeCacheSize=512m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=1g -Xss2048K ThreadPoolExample

分析结果：
#jcmd 81849 VM.native_memory summary
81849:

Native Memory Tracking:

Total: reserved=14737064KB, committed=13157168KB
-                 Java Heap (reserved=10485760KB, committed=10485760KB)
                            (mmap: reserved=10485760KB, committed=10485760KB)

-                     Class (reserved=1102016KB, committed=50112KB)
                            (classes #416)
                            (malloc=45248KB #1420)
                            (mmap: reserved=1056768KB, committed=4864KB)

//committed 已向OS提请分配，实际要到使用时page fault才会实际分配物理内存并在RSS中反应出来
-                    Thread (reserved=2134883KB, committed=2134883KB)//reserved还没分配,不能访问
                            (thread #1070) //1000个应用线程，加70个JVM native线程
                            (stack: reserved=2128820KB, committed=2128820KB) //需要2G多点
                            (malloc=3500KB #5390)
                            (arena=2563KB #2138)

-                      Code (reserved=532612KB, committed=4620KB)
                            (malloc=132KB #528)
                            (mmap: reserved=532480KB, committed=4488KB)

-                        GC (reserved=430421KB, committed=430421KB)
                            (malloc=50737KB #235)
                            (mmap: reserved=379684KB, committed=379684KB)

-                  Compiler (reserved=137KB, committed=137KB)
                            (malloc=6KB #53)
                            (arena=131KB #3)

-                  Internal (reserved=48901KB, committed=48901KB)
                            (malloc=48869KB #14030)
                            (mmap: reserved=32KB, committed=32KB)

-                    Symbol (reserved=1479KB, committed=1479KB)
                            (malloc=959KB #110)
                            (arena=520KB #1)

-    Native Memory Tracking (reserved=608KB, committed=608KB)
                            (malloc=193KB #2556)
                            (tracking overhead=415KB)

-               Arena Chunk (reserved=248KB, committed=248KB)
                            (malloc=248KB)

We can see two types of memory:

  • Reserved — the size which is guaranteed to be available by a host’s OS (but still not allocated and cannot be accessed by JVM) — it’s just a promise
  • Committed — already taken, accessible, and allocated by JVM

page fault

内核给用户态申请的内存，默认都只是一段虚拟地址空间而已，并没有分配真正的物理内存。在第一次读写的时候才触发物理内存的分配，这个过程叫做page fault。那么，为了访问到真正的物理内存，page fault的时候，就需要更新对应的page table了。

参考资料

https://www.atatech.org/articles/66885

https://cloud.tencent.com/developer/article/1087455

https://www.cnblogs.com/xiaolincoding/p/13719610.html

rsyslog占用内存高

https://sunsea.im/rsyslogd-systemd-journald-high-memory-solution.html

鸟哥 journald 介绍

说出来你可能不信，内核这家伙在内存的使用上给自己开了个小灶！

socket 与 slab dentry

技巧

如何在工作中学习--V2.0

如何在工作中学习–V2.0

本文被网友翻译的英文版 （medium 需要梯子）

先说一件值得思考的事情：高考的时候大家都是一样的教科书，同一个教室，同样的老师辅导，时间精力基本差不多，可是最后别人考的是清华北大或者一本，而你的实力只能考个三本，为什么？ 当然这里主要是智商的影响，那么其他因素呢？智商解决的问题能不能后天用其他方式来补位一下？

大家平时都看过很多方法论的文章，看的时候很爽觉得非常有用，但是一两周后基本还是老样子了。其中有很大一部分原因那些方法对脑力有要求、或者方法论比较空缺少落地的步骤。 下文中描述的方式方法是不需要智商也能学会的，非常具体的。

关键问题点

为什么你的知识积累不了？

有些知识看过就忘、忘了再看，实际碰到问题还是联系不上这个知识，这其实是知识的积累出了问题，没有深入的理解自然就不能灵活运用，也就谈不上解决问题了。这跟大家一起看相同的高考教科书但是高考结果不一样是一个原因。问题出在了理解上，每个人的理解能力不一样（智商），绝大多数人对知识的理解要靠不断地实践（做题）来巩固。

同样实践效果不一样？

同样工作一年碰到了10个问题（或者说做了10套高考模拟试卷），但是结果不一样，那是因为在实践过程中方法不够好。或者说你对你为什么做对了、为什么做错了没有去复盘

假如碰到一个问题，身边的同事解决了，而我解决不了。那么我就去想这个问题他是怎么解决的，他看到这个问题后的逻辑和思考是怎么样的，有哪些知识指导了他这么逻辑推理，这些知识哪些我也知道但是我没有想到这么去运用推理（说明我对这个知识理解的不到位导致灵活运用缺乏）；这些知识中又有哪些是我不知道的（知识缺乏，没什么好说的快去Google什么学习下–有场景案例和目的加持，学习理解起来更快）。

等你把这个问题基本按照你同事掌握的知识和逻辑推理想明白后，需要再去琢磨一下他的逻辑推理解题思路中有没有不对的，有没有啰嗦的地方，有没有更直接的方式（对知识更好地运用）。

我相信每个问题都这么去实践的话就不应该再抱怨灵活运用、举一反三，同时知识也积累下来了，这种场景下积累到的知识是不会那么容易忘记的。

这就是向身边的牛人学习，同时很快超过他的办法。这就是为什么高考前你做了10套模拟题还不如其他人做一套的效果好

知识+逻辑 基本等于你的能力，知识让你知道那个东西，逻辑让你把东西和问题联系起来

这里的问题你可以理解成方案、架构、设计等

系统化的知识哪里来？

知识之间是可以联系起来的并且像一颗大树一样自我生长，但是当你都没理解透彻，自然没法产生联系，也就不能够自我生长了。

真正掌握好的知识点会慢慢生长连接最终组成一张大网

但是我们最容易陷入的就是掌握的深度、系统化（工作中碎片时间过多，学校里缺少时间）不够，所以一个知识点每次碰到花半个小时学习下来觉得掌握了，但是3个月后就又没印象了。总是感觉自己在懵懵懂懂中，或者一个领域学起来总是不得要领，根本的原因还是在于：宏观整体大图了解不够（缺乏体系，每次都是盲人摸象）；关键知识点深度不够，理解不透彻，这些关键点就是这个领域的骨架、支点、抓手。缺了抓手自然不能生长，缺了宏观大图容易误入歧途。

我们有时候发现自己在某个领域学起来特别快，但是换个领域就总是不得要领，问题出在了上面，即使花再多时间也是徒然。这也就是为什么学霸看两个小时的课本比你看两天效果还好，感受下来还觉得别人好聪明，是不是智商比我高啊。

所以新进入一个领域的时候要去找他的大图和抓手。

好的同事总是能很轻易地把这个大图交给你，再顺便给你几个抓手，你就基本入门了，这就是培训的魅力，这种情况肯定比自学效率高多了。但是目前绝大部分的培训都做不到这点

好的逻辑又怎么来？

实践、复盘

img

讲个前同事的故事

有一个前同事是5Q过来的，负责技术（所有解决不了的问题都找他），这位同学从chinaren出道，跟着王兴一块创业5Q，5Q在学校靠鸡腿打下大片市场，最后被陈一舟的校内收购（据说被收购后5Q的好多技术都走了，最后王兴硬是呆在校内网把合约上的所有钱都拿到了）。这位同学让我最佩服的解决问题的能力，好多问题其实他也不一定就擅长，但是他就是有本事通过Help、Google不停地验证尝试就把一个不熟悉的问题给解决了，这是我最羡慕的能力，在后面的职业生涯中一直不停地往这个方面尝试。

应用刚启动连接到数据库的时候比较慢，但又不是慢查询

  1. 这位同学的解决办法是通过tcpdump来分析网络包，看网络包的时间戳和网络包的内容，然后找到了具体卡在了哪里。

  2. 如果是专业的DBA可能会通过show processlist 看具体连接在做什么，比如看到这些连接状态是 authentication 状态，然后再通过Google或者对这个状态的理解知道创建连接的时候MySQL需要反查IP、域名这里比较耗时，通过配置参数 skip-name-resolve 跳过去就好了。

  3. 如果是MySQL的老司机，一上来就知道连接慢的话跟 skip-name-resolve 关系最大。

    在我眼里这三种方式都解决了问题，最后一种最快但是纯靠积累和经验，换个问题也许就不灵了；第一种方式是最牛逼和通用的，只需要最少的知识就把问题解决了。

我当时跟着他从sudo、ls等linux命令开始学起。当然我不会轻易去打搅他问他，每次碰到问题我尽量让他在我的电脑上来操作，解决后我再自己复盘，通过history调出他的所有操作记录，看他在我的电脑上用Google搜啥了，然后一个个去学习分析他每个动作，去想他为什么搜这个关键字，复盘完还有不懂的再到他面前跟他面对面的讨论他为什么要这么做，指导他这么做的知识和逻辑又是什么。

有哪些好的行为帮你更好地掌握知识

笔记+写博客

看东西的时候要做笔记，要不当时看得再爽也很容易忘记，我们需要反复复习来加深印象和理解，复习的根据就是笔记（不可能再完整又看一次），笔记整理出里面的要点和你的盲点。

一段时间后把相关的笔记整理成一篇体系性的博客文章，这样既加深了理解又系统化了相关知识。以后再看到跟这篇博客相关的案例、知识点时不断地更新博客（完善你的知识点）

场景式学习、体感的来源、面对问题学习

前面提到的对知识的深入理解这有点空，如何才能做到深入理解？

举个学习TCP三次握手例子

经历稍微丰富点的工程师都觉得TCP三次握手看过很多次、很多篇文章了，但是文章写得再好似乎当时理解了，但是总是过几个月就忘了或者一看就懂，过一阵子被人一问就模模糊糊了，或者两个为什么就答不上了，自己都觉得自己的回答是在猜或者不确定

为什么会这样呢？而学其它知识就好通畅多了，我觉得这里最主要的是我们对TCP缺乏体感，比如没有几个工程师去看过TCP握手的代码，也没法想象真正的TCP握手是如何在电脑里运作的（打电话能给你一些类似的体感，但是细节覆盖面不够）。

如果这个时候你一边学习的时候一边再用wireshark抓包看看三次握手具体在干什么，比抽象的描述实在多了，你能看到具体握手的一来一回，并且看到一来一回带了哪些内容，这些内容又是用来做什么、为什么要带，这个时候你再去看别人讲解的理论顿时会觉得好理解多了，以后也很难忘记。

但是这里很多人执行能力不强，想去抓包，但是觉得要下载安装wireshark，要学习wireshark就放弃了。只看不动手当然是最舒适的，但是这个最舒适给了你在学习的假象，没有结果。

这是不是跟你要解决一个难题非常像，这个难题需要你去做很多事，比如下载源代码（翻不了墙，放弃）；比如要编译（还要去学习那些编译参数，放弃）；比如要搭建环境（太琐屑，放弃）。你看这中间九九八十一难你放弃了一难都取不了真经。这也是为什么同样学习、同样的问题，他能学会，他能解决，你不可以。

167211888bc4f2a368df3d16c68e6d51.png

再来看一个解决问题的例子

会员系统双11优化这个问题对我来说，我是个外来者，完全不懂这里面的部署架构、业务逻辑。但是在问题的关键地方（会员认为自己没问题–压力测试正常的；淘宝API更是认为自己没问题，alimonitor监控显示正常），结果就是会员的同学说我们没有问题，淘宝API肯定有问题，然后就不去思考自己这边可能出问题的环节了。思想上已经甩包了，那么即使再去review流程、环节也就不会那么仔细，自然更是发现不了问题了。

但是我的经验告诉我要有证据地甩包，或者说拿着证据优雅地甩包，这迫使我去找更多的细节证据（证据要给力哦，不能让人家拍回来）。如果我是这么说的，这个问题在淘宝API这里，你看理由是…………，我做了这些实验，看到了这些东东。那么淘宝API那边想要证明我的理由错了就会更积极地去找一些数据。

事实上我就是做这些实验找证据过程中发现了会员的问题，这就是态度、执行力、知识、逻辑能力综合下来拿到的一个结果。我最不喜欢的一句话就是我的程序没问题，因为我的逻辑是这样的，不会错的。你当然不会写你知道的错误逻辑，程序之所以有错误都是在你的逻辑、意料之外的东西。有很多次一堆人电话会议中扯皮的时候，我一般把电话静音了，直接上去人肉一个个过对方的逻辑，一般来说电话会议还没有结束我就给出来对方逻辑之外的东西。

钉子式学习方法和系统性学习方法

系统性学习方法就是想掌握MySQL，那么搞几本MySQL专著和MySQL 官方DOC看下来，一般课程设计的好的话还是比较容易掌握下来，绝大部分时候都是这种学习方法，可是在种学习方法的问题在于学完后当时看着似乎理解了，但是很容易忘记，一片一片地系统性的忘记，并且缺少应用能力（理解不深）。这是因为一般人对知识的理解没那么容易真正理解（掌握或者说应用）。

钉子式的学习方式，就是在一大片知识中打入几个桩，反复演练将这个桩不停地夯实，夯稳，做到在这个知识点上用通俗的语言跟小白都能讲明白，然后再这几个桩中间发散像星星之火燎原一样把整个一片知识都掌握下来。这种学习方法的缺点就是很难找到一片知识点的这个点，然后没有很好整合的话知识过于零散。

钉子式学习方法看着慢但是因为这样掌握的更透彻和牢固实际最终反而快。

我们常说的一个人很聪明，就是指系统性的看看书就都理解了，是真的理解那种，还能灵活运用，但是大多数普通人就不是这样的，看完书似乎理解了，实际几周后基本都忘记了，真正实践需要用的时候还是用不好。

举个Open-SSH的例子

为了做通 SSH 的免密登陆，大家都需要用到 ssh-keygen/ssh-copy-id， 如果我们把这两个命令当一个小的钉子的话，会去了解ssh-keygen做了啥（生成了密钥对），或者ssh-copy-id 的时候报错了（原来是需要秘钥对），然后将 ssh-keygen 生成的pub key复制到server的~/.ssh/authorized_keys 中。

然后你应该会对这个原理要有一些理解（更大的钉子），于是理解了密钥对，和ssh验证的流程，顺便学会怎么看ssh debug信息，那么接下来网络上各种ssh攻略、各种ssh卡顿的解决都是很简单的事情了。

比如你通过SSH可以解决这些问题：

  • 免密登陆
  • ssh卡顿
  • 怎么去掉ssh的时候需要手工多输入yes
  • 我的ssh怎么很快就断掉了
  • 我怎么样才能一次通过跳板机ssh到目标机器
  • 我怎么样通过ssh科学上网
  • 我的ansible（底层批量命令都是基于ssh）怎么这么多问题，到底是为什么
  • 我的git怎么报网络错误了
  • X11 forward我怎么配置不好
  • https为什么需要随机数加密，还需要签名
  • …………

这些问题都是一步步在扩大ssh的外延，让这个钉子变成一个巨大的桩。

然后就会学习到一些高级一些的ssh配置，比如干掉经常ssh的时候要yes一下(StrictHostKeyChecking=no), 或者怎么配置一下ssh就不会断线了（ServerAliveInterval=15），或者将 ssh跳板机->ssh server的过程做成 ssh server一步就可以了(ProxyCommand)，进而发现用 ssh的ProxyCommand很容易科学上网了，或者git有问题的时候轻而易举地把ssh debug打开，对git进行debug了……

这基本都还是ssh的本质范围，像ansible、git在底层都是依赖ssh来通讯的，你会发现学、调试X11、ansible和git简直太容易了。

另外理解了ssh的秘钥对，也就理解了非对称加密，同时也很容易理解https流程（SSL），同时知道对称和非对称加密各自的优缺点，SSL为什么需要用到这两种加密算法了。

你看一个简单日常的知识我们只要沿着它用钉子精神，深挖细挖你就会发现知识之间的连接，这个小小的知识点成为你知识体系的一根结实的柱子。

我见过太多的老的工程师、年轻的工程师，天天在那里ssh 密码，ssh 跳板机，ssh 目标机，一小会ssh断了，重来一遍；或者ssh后卡住了，等吧……

在这个问题上表现得没有求知欲、没有探索精神、没有一次把问题搞定的魄力，所以就习惯了

空洞的口号

很多老师和文章都会教大家：举一反三、灵活运用、活学活用、多做多练。但是只有这些口号是没法落地的，落地的基本步骤就是前面提到的，却总是被忽视了。

什么是工程效率，什么是知识效率

有些人纯看理论就能掌握好一门技能，还能举一反三，这是知识效率，这种人非常少；

大多数普通人都是看点知识然后结合实践来强化理论，要经过反反复复才能比较好地掌握一个知识，这就是工程效率，讲究技巧、工具来达到目的。

肯定知识效率最牛逼，但是拥有这种技能的人毕竟非常少（天生的高智商吧）。从小我们周边那种不怎么学的学霸型基本都是这类，这种学霸都还能触类旁通非常快的掌握一个新知识，非常气人。剩下的绝大部分只能拼时间+方法+总结等也能掌握一些知识

非常遗憾我就是工程效率型，只能羡慕那些知识效率型的学霸。但是这事又不能独立看待有些人在某些方向上是工程效率型，有些方向就又是知识效率型（有一种知识效率型是你掌握的实在太多也就比较容易触类旁通了，这算灰色知识效率型）

使劲挖掘自己在知识效率型方面的能力吧，两者之间当然没有明显的界限，知识积累多了逻辑训练好了在别人看来你的智商就高了

知识分两种

一种是通用知识（不是说对所有人通用，而是说在一个专业领域去到哪个公司都能通用）；另外一种是跟业务公司绑定的特定知识

通用知识没有任何疑问碰到后要非常饥渴地扑上去掌握他们（受益终生，这还有什么疑问吗？）。对于特定知识就要看你对业务需要掌握的深度了，肯定也是需要掌握一些的，特定知识掌握好的一般在公司里混的也会比较好。

一个具体知识体系里面又有一些核心知识点（抓手、essential knowledge），也就是掌握可以快速帮你膨胀、延伸到其他相关知识的知识点。

还有一些知识、工具一旦掌握就能帮你贯穿、具象、理解别的知识点，比如网络知识体系中的wireshark；理工科中的数学；知识体系中的学习方法、行为方式。我们要多去发现这些知识、工具（how？）

哪些品质能够决定一个人学习好坏

排在第一名的品质是复盘、总结能力

简单的说，这个能力就是这个孩子心里是否有个“小教练”，能够每次跳脱出当前任务，帮助自己分析，失败在哪里，成功在哪里，如何进阶，如何训练等等。

举几个例子：

  1. 如果写不出作文，这个“小教练”能告诉孩子，是没有素材，还是文字能力不强。

    如果是文字能力不强，应该如何训练（是造句，还是拆段落）

  2. 如果数学题做不出来，这个“小教练”能告诉孩子，我的弱点在哪里，哪个类型题我有重大问题，是因为哪里没有理解和打通。

有内化的“自我教练”，这个能力系数是1.67。也就是其他能力相当，学习效果可以翻1.67倍。

排在第二名的是建构能力。简单的说是逻辑推理，做事顺序等等

在内心“小教练”能把问题进行拆解之后，建构能力能把这些问题进行排序，应该怎么做更合理。

最终怎么把训练步骤整合。遇见一个问题，先干什么，再干什么等等。

有很强的顺序能力，系数为1.44。也就是其他能力相当，学习效果可以翻1.44倍。

排在第三名的能力是智商和过去成绩

这个毋庸置疑，聪明做事就会简单一些。平均效应系数为0.67。

也就是说，其他能力相当，智商高和过去成绩好，学习效果提升67%

智商重要程度应该比这里更高，但是实际高智商的太少，大多都是因为基础知识好给人产生了智商高的误解！

排在第四名的能力是自我驱动力

简单的说，知道自己为什么学习，能够自我鼓励，遇见失败能抗挫，有很强的心理驱动力。

平均效应系数为0.48。也就是说，其他能力相当，有自我驱动力的人，学习效果提升48%。

排在第五名的才是集中注意力

也就是说，注意力强。注意力对学习影响，并没有很多家长想象的那么大。

注意力的平均效应系数为0.44

也就是说，其他能力相当，注意力好的孩子，效果能提升44%

———总结一下——-

学习提升的个人因素：

自我分析，自我教练的元认知能力 》 逻辑排序与制定计划的建构能力》 智商和过去成绩 》自我驱动力》 集中注意力。

很多家长痴迷于“专注力”。当然专注力是一个效应量很强的学习力，但是从整体数据看，对学习的提升效果，仅仅排到第五名。

帮助孩子建立元认知能力和建构能力的培训，才能给他们对终身学习有帮助的技能包

以上缺少了对方法的落地执行能力的评估，实际这是影响最大的

为什么一直努力却没有结果

人生不是走斜坡，你持续走就可以走到巅峰；人生像走阶梯（有时候需要跳上台阶），每一阶有每一阶的难点，学物理有物理的难点，学漫画有漫画的难点，你没有克服难点，再怎么努力都是原地跳。所以当你克服难点，你跳上去就不会下来了。

这里的克服难点可以理解成真正掌握知识点，大多时候只是似是而非，所以一直在假忙碌、假学习，只有真正掌握后才像是上了个台阶。

这句话本身就是对知识的具象化理解，本来要描述的是有些人很容易达到目的、有些人则很难，我们很容易归结到天赋等原因，但是还是不能完全理解这个事情，知道天赋差异也不会帮助到我们跳楼梯，而这句话给出了一个形象的描述，一下子就会记住并在日常中尽量尝试跳上去和脱离假忙碌的状态。

image.png

在上述截图中，温伯格拿他自己玩弹子球游戏的经验，来描述”跃迁模式”。
　 为啥在跃迁之前会出现一个【低谷】捏？温伯格认为：要想提升到一个新的 level，你需要放弃某些你擅长的技能，然后尝试你所【不】擅长的技能。
温伯格以他的弹子球游戏举例说：
为了得到更高的分数，他必须放弃以前熟悉的【低】难度技巧，转而尝试某种【高】难度技巧。在练习高难度技巧的过程中，他的分数会跌得比原先更低（也就是截图中下凹的低谷）。经过了一段时间的练习，当他掌握了高难度技巧，他的游戏得分就突然飞跃到一个新的 level。

TCP

举三反一--从理论知识到实际问题的推导

举三反一–从理论知识到实际问题的推导

怎么样才能获取举三反一的秘籍， 普通人为什么要案例来深化对理论知识的理解。

什么是工程效率，什么是知识效率

有些人纯看理论就能掌握好一门技能，还能举三反一，这是知识效率，这种人非常少；

大多数普通人都是看点知识然后结合实践来强化理解理论，要经过反反复复才能比较好地掌握一个知识，这就是工程效率，讲究技巧、工具来达到目的。

对于费曼（参考费曼学习法）这样的聪明人就是很容易看到一个理论知识就能理解这个理论知识背后的本质。

肯定知识效率最牛逼，但是拥有这种能力的人毕竟非常少。从小我们周边那种不怎么学的学霸型基本都是这类，这种学霸都还能触类旁通非常快地掌握一个新知识。剩下的绝大部分只能拼时间(刷题)+方法+总结等也能掌握一些知识

但是这事又不能独立看待有些人在某些方向上是工程效率型，有些方向就又是知识效率型（有一种知识效率型是你掌握的实在太多也就比较容易触类旁通了，这算灰色知识效率型）

使劲挖掘自己在知识效率型方面的能力吧，即使灰色地带也行啊。

接下来看看TCP状态中的CLOSE_WAIT状态的含义

先看TCP连接状态图

这是网络、书本上凡是描述TCP状态一定会出现的状态图，理论上看这个图能解决任何TCP状态问题。

image.png

反复看这个图的右下部分的CLOSE_WAIT ，从这个图里可以得到如下结论：

CLOSE_WAIT是被动关闭端在等待应用进程的关闭

基本上这一结论要能帮助解决所有CLOSE_WAIT相关的问题，如果不能说明对这个知识点理解的不够。

server端大量close_wait案例

用实际案例来检查自己对CLOSE_WAIT 理论（CLOSE_WAIT是被动关闭端在等待应用进程的关闭）的掌握 – 能不能用这个结论来解决实际问题。同时也可以看看自己从知识到问题的推理能力（跟前面的知识效率呼应一下）。

问题描述：

服务端出现大量CLOSE_WAIT 个数正好 等于somaxconn（调整somaxconn大小后 CLOSE_WAIT 也会跟着变成一样的值）

根据这个描述先不要往下看，自己推理分析下可能的原因。

我的推理如下：

从这里看起来，client跟server成功建立了somaxconn个连接（somaxconn小于backlog，所以accept queue只有这么大），但是应用没有accept这个连接，导致这些连接一直在accept queue中。但是这些连接的状态已经是ESTABLISHED了，也就是client可以发送数据了，数据发送到server后OS ack了，并放在os的tcp buffer中，应用一直没有accept也就没法读取数据。client于是发送fin（可能是超时、也可能是简单发送数据任务完成了得结束连接），这时Server上这个连接变成了CLOSE_WAIT .

也就是从开始到结束这些连接都在accept queue中，没有被应用accept，很快他们又因为client 发送 fin 包变成了CLOSE_WAIT ，所以始终看到的是服务端出现大量CLOSE_WAIT 并且个数正好等于somaxconn（调整somaxconn后 CLOSE_WAIT 也会跟着变成一样的值）。

如下图所示，在连接进入accept queue后状态就是ESTABLISED了，也就是可以正常收发数据和fin了。client是感知不到server是否accept()了，只是发了数据后server的os代为保存在OS的TCP buffer中，因为应用没来取自然在CLOSE_WAIT 后应用也没有close()，所以一直维持CLOSE_WAIT 。

得检查server 应用为什么没有accept。

Recv-Q和Send-Q

如上是老司机的思路靠经验缺省了一些理论推理，缺省还是对理论理解不够， 这个分析抓住了 大量CLOSE_WAIT 个数正好 等于somaxconn（调整somaxconn后 CLOSE_WAIT 也会跟着变成一样的值）但是没有抓住 CLOSE_WAIT 背后的核心原因

更简单的推理

如果没有任何实战经验，只看上面的状态图的学霸应该是这样推理的：

看到server上有大量的CLOSE_WAIT说明client主动断开了连接，server的OS收到client 发的fin，并回复了ack，这个过程不需要应用感知，进而连接从ESTABLISHED进入CLOSE_WAIT，此时在等待server上的应用调用close连关闭连接（处理完所有收发数据后才会调close()） —- 结论：server上的应用一直卡着没有调close().

同时这里很奇怪的现象： 服务端出现大量CLOSE_WAIT 个数正好 等于somaxconn，进而可以猜测是不是连接建立后很快accept队列满了（应用也没有accept() ), 导致 大量CLOSE_WAIT 个数正好 等于somaxconn —- 结论： server 上的应用不但没有调close(), 连close() 前面必须调用 accept() 都一直卡着没调 （这个结论需要有accept()队列的理论知识)

从上面两个结论可以清楚地看到 server的应用卡住了

实际结论：

这个case的最终原因是因为OS的open files设置的是1024,达到了上限，进而导致server不能accept，但这个时候的tcp连接状态已经是ESTABLISHED了（这个状态变换是取决于内核收发包，跟应用是否accept()无关）。

同时从这里可以推断 netstat 即使看到一个tcp连接状态是ESTABLISHED也不能代表占用了 open files句柄。此时client可以正常发送数据了，只是应用服务在accept之前没法receive数据和close连接。

这个结论的图解如下：

image.png

假如全连接队列满了，握手第三步后对于client端来说是无法感知的，client端只需要回复ack后这个连接对于client端就是ESTABLISHED了，这时client是可以发送数据的。但是Server会扔掉收到的ack，回复syn+ack给client。

如果全连接队列没满，但是fd不够，那么在Server端这个Socket也是ESTABLISHED，但是只是暂存在全连接队列中，等待应用来accept，这个时候client端同样无法感知这个连接没有被accept，client是可以发送数据的，这个数据会保存在tcp receive memory buffer中，等到accept后再给应用。

如果自己无法得到上面的分析，那么再来看看如果把 CLOSE_WAIT 状态更细化地分析下(类似有老师帮你把知识点揉开跟实际案例联系下—-未必是上面的案例)，看完后再来分析下上面的案例。

CLOSE_WAIT 状态拆解

通常，CLOSE_WAIT 状态在服务器停留时间很短，如果你发现大量的 CLOSE_WAIT 状态，那么就意味着被动关闭的一方没有及时发出 FIN 包，一般有如下几种可能：

  • 程序问题：如果代码层面忘记了 close 相应的 socket 连接，那么自然不会发出 FIN 包，从而导致 CLOSE_WAIT 累积；或者代码不严谨，出现死循环之类的问题，导致即便后面写了 close 也永远执行不到。
  • 响应太慢或者超时设置过小：如果连接双方不和谐，一方不耐烦直接 timeout，另一方却还在忙于耗时逻辑，就会导致 close 被延后。响应太慢是首要问题，不过换个角度看，也可能是 timeout 设置过小。
  • BACKLOG 太大：此处的 backlog 不是 syn backlog，而是 accept 的 backlog，如果 backlog 太大的话，设想突然遭遇大访问量的话，即便响应速度不慢，也可能出现来不及消费的情况，导致多余的请求还在队列里就被对方关闭了。

如果你通过「netstat -ant」或者「ss -ant」命令发现了很多 CLOSE_WAIT 连接，请注意结果中的「Recv-Q」和「Local Address」字段，通常「Recv-Q」会不为空，它表示应用还没来得及接收数据，而「Local Address」表示哪个地址和端口有问题，我们可以通过「lsof -i:」来确认端口对应运行的是什么程序以及它的进程号是多少。

如果是我们自己写的一些程序，比如用 HttpClient 自定义的蜘蛛，那么八九不离十是程序问题，如果是一些使用广泛的程序，比如 Tomcat 之类的，那么更可能是响应速度太慢或者 timeout 设置太小或者 BACKLOG 设置过大导致的故障。

看完这段 CLOSE_WAIT 更具体深入点的分析后再来分析上面的案例看看，能否推导得到正确的结论。

一些疑问

连接都没有被accept(), client端就能发送数据了？

答：是的。只要这个连接在OS看来是ESTABLISHED的了就可以，因为握手、接收数据都是由内核完成的，内核收到数据后会先将数据放在内核的tcp buffer中，然后os回复ack。另外三次握手之后client端是没法知道server端是否accept()了。

CLOSE_WAIT与accept queue有关系吗？

答：没有关系。只是本案例中因为open files不够了，影响了应用accept(), 导致accept queue满了，同时因为即使应用不accept（三次握手后，server端是否accept client端无法感知），client也能发送数据和发 fin断连接，这些响应都是os来负责，跟上层应用没关系，连接从握手到ESTABLISHED再到CLOSE_WAIT都不需要fd，也不需要应用参与。CLOSE_WAIT只跟应用不调 close() 有关系。

CLOSE_WAIT与accept queue为什么刚好一致并且联动了？

答：这里他们的数量刚好一致是因为所有新建连接都没有accept，堵在queue中。同时client发现问题后把所有连接都fin了，也就是所有queue中的连接从来没有被accept过，但是他们都是ESTABLISHED，过一阵子之后client端发了fin所以所有accept queue中的连接又变成了 CLOSE_WAIT, 所以二者刚好一致并且联动了

openfiles和accept()的关系是？

答：accept()的时候才会创建文件句柄，消耗openfiles

一个连接如果在accept queue中了，但是还没有被应用 accept，那么这个时候在server上看这个连接的状态他是ESTABLISHED的吗？

答：是

如果server的os参数 open files到了上限（就是os没法打开新的文件句柄了）会导致这个accept queue中的连接一直没法被accept对吗？

答：对

如果通过gdb attach 应用进程，故意让进程accept，这个时候client还能连上应用吗？

答： 能，这个时候在client和server两边看到的连接状态都是 ESTABLISHED，只是Server上的全连接队列占用加1。连接握手并切换到ESTABLISHED状态都是由OS来负责的，应用不参与，ESTABLISHED后应用才能accept，进而收发数据。也就是能放入到全连接队列里面的连接肯定都是 ESTABLISHED 状态的了

接着上面的问题，如果新连接继续连接进而全连接队列满了呢？

答：那就连不上了，server端的OS因为全连接队列满了直接扔掉第一个syn握手包，这个时候连接在client端是SYN_SENT，Server端没有这个连接，这是因为syn到server端就直接被OS drop 了。

1
2
3
//如下图，本机测试，只有一个client端发起的syn_send, 3306的server端没有任何连接
$netstat -antp  |grep -i 127.0.0.1:3306
tcp     0   1 127.0.0.1:61106      127.0.0.1:3306    SYN_SENT    21352/telnet

能进入到accept queue中的连接都是 ESTABLISHED，不管用户态有没有accept，用户态accept后队列大小减1

如果一个连接握手成功进入到accept queue但是应用accept前被对方RESET了呢？

答： 如果此时收到对方的RESET了，那么OS会释放这个连接。但是内核认为所有 listen 到的连接, 必须要 accept 走, 因为用户有权利知道有过这么一个连接存在过。所以OS不会到全连接队列拿掉这个连接，全连接队列数量也不会减1，直到应用accept这个连接，然后read/write才发现这个连接断开了，报communication failure异常

什么时候连接状态变成 ESTABLISHED

三次握手成功就变成 ESTABLISHED 了，不需要用户态来accept，如果握手第三步的时候OS发现全连接队列满了，这时OS会扔掉这个第三次握手ack，并重传握手第二步的syn+ack, 在OS端这个连接还是 SYN_RECV 状态的，但是client端是 ESTABLISHED状态的了。

这是在4000（tearbase）端口上全连接队列没满，但是应用不再accept了，nc用12346端口去连4000（tearbase）端口的结果

1
2
3
4
5
6
# netstat -at |grep ":12346 "
tcp   0      0 dcep-blockchain-1:12346 dcep-blockchai:terabase ESTABLISHED //server
tcp   0      0 dcep-blockchai:terabase dcep-blockchain-1:12346 ESTABLISHED //client
[root@dcep-blockchain-1 cfl-sm2-sm3]# ss -lt
State       Recv-Q Send-Q      Local Address:Port         Peer Address:Port   
LISTEN      73     1024            *:terabase                 *:*

这是在4000（tearbase）端口上全连接队列满掉后，nc用12346端口去连4000（tearbase）端口的结果

1
2
3
4
5
6
# netstat -at |grep ":12346 "  
tcp   0      0 dcep-blockchai:terabase dcep-blockchain-1:12346 SYN_RECV    //server
tcp   0      0 dcep-blockchain-1:12346 dcep-blockchai:terabase ESTABLISHED //client
# ss -lt
State       Recv-Q Send-Q      Local Address:Port       Peer Address:Port   
LISTEN      1025   1024             *:terabase              *:*
docker

kubernetes service 和 kube-proxy详解

kubernetes service 和 kube-proxy详解

service 是Kubernetes里面非常重要的一个功能，用以解决负载均衡、弹性伸缩、升级灰度等等

本文先从概念介绍到实际负载均衡运转过程中追踪每个环节都做哪些处理，同时这些包会相应地怎么流转最终到达目标POD，以阐明service工作原理以及kube-proxy又在这个过程中充当了什么角色。

service 模式

根据创建Service的type类型不同，可分成4种模式：

  • ClusterIP： 默认方式。根据是否生成ClusterIP又可分为普通Service和Headless Service两类：
    • 普通Service：通过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP（Cluster IP），实现集群内的访问。为最常见的方式。
    • Headless Service：该服务不会分配Cluster IP，也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为podIP列表。主要供StatefulSet中对应POD的序列用。
  • NodePort：除了使用Cluster IP之外，还通过将service的port映射到集群内每个节点的相同一个端口，实现通过nodeIP:nodePort从集群外访问服务。NodePort会RR转发给后端的任意一个POD，跟ClusterIP类似
  • LoadBalancer：和nodePort类似，不过除了使用一个Cluster IP和nodePort之外，还会向所使用的公有云申请一个负载均衡器，实现从集群外通过LB访问服务。在公有云提供的 Kubernetes 服务里，都使用了一个叫作 CloudProvider 的转接层，来跟公有云本身的 API 进行对接。所以，在上述 LoadBalancer 类型的 Service 被提交后，Kubernetes 就会调用 CloudProvider 在公有云上为你创建一个负载均衡服务，并且把被代理的 Pod 的 IP 地址配置给负载均衡服务做后端。
  • ExternalName：是 Service 的特例。此模式主要面向运行在集群外部的服务，通过它可以将外部服务映射进k8s集群，且具备k8s内服务的一些特征（如具备namespace等属性），来为集群内部提供服务。此模式要求kube-dns的版本为1.7或以上。这种模式和前三种模式（除headless service）最大的不同是重定向依赖的是dns层次，而不是通过kube-proxy。

service yaml案例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Service
metadata:
  name: nginx-ren
  labels:
    app: web
spec:
  type: NodePort
# clusterIP: None  
  ports:
  - port: 8080
    targetPort: 80
    nodePort: 30080
  selector:
    app: ren

ports 字段指定服务的端口信息：

  • port：虚拟 ip 要绑定的 port，每个 service 会创建出来一个虚拟 ip，通过访问 vip:port 就能获取服务的内容。这个 port 可以用户随机选取，因为每个服务都有自己的 vip，也不用担心冲突的情况
  • targetPort：pod 中暴露出来的 port，这是运行的容器中具体暴露出来的端口，一定不能写错–一般用name来代替具体的port
  • protocol：提供服务的协议类型，可以是 TCP 或者 UDP
  • nodePort： 仅在type为nodePort模式下有用，宿主机暴露端口

nodePort和loadbalancer可以被外部访问，loadbalancer需要一个外部ip，流量走外部ip进出

NodePort向外部暴露了多个宿主机的端口，外部可以部署负载均衡将这些地址配置进去。

默认情况下，服务会rr转发到可用的后端。如果希望保持会话（同一个 client 永远都转发到相同的 pod），可以把 service.spec.sessionAffinity 设置为 ClientIP。

Service和kube-proxy的工作原理

kube-proxy有两种主要的实现（userspace基本没有使用了）：

  • iptables来做NAT以及负载均衡（默认方案）
  • ipvs来做NAT以及负载均衡

Service 是由 kube-proxy 组件通过监听 Pod 的变化事件，在宿主机上维护iptables规则或者ipvs规则。

Kube-proxy 主要监听两个对象，一个是 Service，一个是 Endpoint，监听他们启停。以及通过selector将他们绑定。

IPVS 是专门为LB设计的。它用hash table管理service，对service的增删查找都是*O(1)*的时间复杂度。不过IPVS内核模块没有SNAT功能，因此借用了iptables的SNAT功能。IPVS 针对报文做DNAT后，将连接信息保存在nf_conntrack中，iptables据此接力做SNAT。该模式是目前Kubernetes网络性能最好的选择。但是由于nf_conntrack的复杂性，带来了很大的性能损耗。

iptables 实现负载均衡的工作流程

如果kube-proxy不是用的ipvs模式，那么主要靠iptables来做DNAT和SNAT以及负载均衡

iptables+clusterIP工作流程：

  1. 集群内访问svc 10.10.35.224:3306 命中 kube-services iptables（两条规则，宿主机、以及pod内）
  2. iptables 规则：KUBE-SEP-F4QDAAVSZYZMFXZQ 对应到 KUBE-SEP-F4QDAAVSZYZMFXZQ
  3. KUBE-SEP-F4QDAAVSZYZMFXZQ 指示 DNAT到 宿主机：192.168.0.83:10379（在内核中将包改写了ip port）
  4. 从svc description中可以看到这个endpoint的地址 192.168.0.83:10379（pod使用Host network）

image.png

iptables规则解析如下（case不一样，所以看到的端口、ip都不一样）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
-t nat -A {PREROUTING, OUTPUT} -m conntrack --ctstate NEW -j KUBE-SERVICES

# 宿主机访问 nginx Service 的流量，同时满足 4 个条件：
# 1. src_ip 不是 Pod 网段
# 2. dst_ip=3.3.3.3/32 (ClusterIP)
# 3. proto=TCP
# 4. dport=80
# 如果匹配成功，直接跳转到 KUBE-MARK-MASQ；否则，继续匹配下面一条（iptables 是链式规则，高优先级在前）
# 跳转到 KUBE-MARK-MASQ 是为了保证这些包出宿主机时，src_ip 用的是宿主机 IP。
-A KUBE-SERVICES ! -s 1.1.0.0/16 -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-MARK-MASQ
# Pod 访问 nginx Service 的流量：同时满足 4 个条件：
# 1. 没有匹配到前一条的，（说明 src_ip 是 Pod 网段）
# 2. dst_ip=3.3.3.3/32 (ClusterIP)
# 3. proto=TCP
# 4. dport=80
-A KUBE-SERVICES -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-SVC-NGINX

# 以 50% 的概率跳转到 KUBE-SEP-NGINX1
-A KUBE-SVC-NGINX -m statistic --mode random --probability 0.50 -j KUBE-SEP-NGINX1
# 如果没有命中上面一条，则以 100% 的概率跳转到 KUBE-SEP-NGINX2
-A KUBE-SVC-NGINX -j KUBE-SEP-NGINX2

# 如果 src_ip=1.1.1.1/32，说明是 Service->client 流量，则
# 需要做 SNAT（MASQ 是动态版的 SNAT），替换 src_ip -> svc_ip，这样客户端收到包时，
# 看到就是从 svc_ip 回的包，跟它期望的是一致的。
-A KUBE-SEP-NGINX1 -s 1.1.1.1/32 -j KUBE-MARK-MASQ
# 如果没有命令上面一条，说明 src_ip != 1.1.1.1/32，则说明是 client-> Service 流量，
# 需要做 DNAT，将 svc_ip -> pod1_ip，
-A KUBE-SEP-NGINX1 -p tcp -m tcp -j DNAT --to-destination 1.1.1.1:80
# 同理，见上面两条的注释
-A KUBE-SEP-NGINX2 -s 1.1.1.2/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-NGINX2 -p tcp -m tcp -j DNAT --to-destination 1.1.1.2:80

image.png

在对应的宿主机上可以清楚地看到容器中的mysqld进程正好监听着 10379端口

1
2
3
4
5
6
7
8
[root@az1-drds-83 ~]# ss -lntp |grep 10379
LISTEN     0      128         :::10379                   :::*                   users:(("mysqld",pid=17707,fd=18))
[root@az1-drds-83 ~]# ps auxff | grep 17707 -B2
root     13606  0.0  0.0  10720  3764 ?        Sl   17:09   0:00  \_ containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/ead57b52b11902b9b5004db0b72abb060b56a1af7ee7ad7066bd09c946abcb97 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc

root     13624  0.0  0.0 103044 10424 ?        Ss   17:09   0:00  |   \_ python /entrypoint.py
root     14835  0.0  0.0  11768  1636 ?        S    17:10   0:00  |   \_ /bin/sh /u01/xcluster/bin/mysqld_safe --defaults-file=/home/mysql/my10379.cnf
alidb    17707  0.6  0.0 1269128 67452 ?       Sl   17:10   0:25  |       \_ /u01/xcluster_20200303/bin/mysqld --defaults-file=/home/mysql/my10379.cnf --basedir=/u01/xcluster_20200303 --datadir=/home/mysql/data10379/dbs10379 --plugin-dir=/u01/xcluster_20200303/lib/plugin --user=mysql --log-error=/home/mysql/data10379/mysql/master-error.log --open-files-limit=8192 --pid-file=/home/mysql/data10379/dbs10379/az1-drds-83.pid --socket=/home/mysql/data10379/tmp/mysql.sock --port=10379

对应的这个pod的description：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#kubectl describe pod apsaradbcluster010-cv6w
Name:         apsaradbcluster010-cv6w
Namespace:    default
Priority:     0
Node:         az1-drds-83/192.168.0.83
Start Time:   Thu, 10 Sep 2020 17:09:33 +0800
Labels:       alisql.clusterName=apsaradbcluster010
              alisql.pod_name=apsaradbcluster010-cv6w
              alisql.pod_role=leader
Annotations:  apsara.metric.pod_name: apsaradbcluster010-cv6w
Status:       Running
IP:           192.168.0.83
IPs:
  IP:           192.168.0.83
Controlled By:  ApsaradbCluster/apsaradbcluster010
Containers:
  engine:
    Container ID:   docker://ead57b52b11902b9b5004db0b72abb060b56a1af7ee7ad7066bd09c946abcb97
    Image:          reg.docker.alibaba-inc.com/apsaradb/alisqlcluster-engine:develop-20200910140415
    Image ID:       docker://sha256:7ad5cc53c87b34806eefec829d70f5f0192f4127c7ee4e867cb3da3bb6c2d709
    Ports:          10379/TCP, 20383/TCP, 46846/TCP
    Host Ports:     10379/TCP, 20383/TCP, 46846/TCP
    State:          Running
      Started:      Thu, 10 Sep 2020 17:09:35 +0800
    Ready:          True
    Restart Count:  0
    Environment:
      ALISQL_POD_NAME:  apsaradbcluster010-cv6w (v1:metadata.name)
      ALISQL_POD_PORT:  10379
    Mounts:
      /dev/shm from devshm (rw)
      /etc/localtime from etclocaltime (rw)
      /home/mysql/data from data-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-n2bmn (ro)
  exporter:
    Container ID:  docker://b49865b7798f9036b431203d54994ac8fdfcadacb01a2ab4494b13b2681c482d
    Image:         reg.docker.alibaba-inc.com/apsaradb/alisqlcluster-exporter:latest
    Image ID:      docker://sha256:432cdd0a0e7c74c6eb66551b6f6af9e4013f60fb07a871445755f6577b44da19
    Port:          47272/TCP
    Host Port:     47272/TCP
    Args:
      --web.listen-address=:47272
      --collect.binlog_size
      --collect.engine_innodb_status
      --collect.info_schema.innodb_metrics
      --collect.info_schema.processlist
      --collect.info_schema.tables
      --collect.info_schema.tablestats
      --collect.slave_hosts
    State:          Running
      Started:      Thu, 10 Sep 2020 17:09:35 +0800
    Ready:          True
    Restart Count:  0
    Environment:
      ALISQL_POD_NAME:   apsaradbcluster010-cv6w (v1:metadata.name)
      DATA_SOURCE_NAME:  root:@(127.0.0.1:10379)/
    Mounts:
      /dev/shm from devshm (rw)
      /etc/localtime from etclocaltime (rw)
      /home/mysql/data from data-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-n2bmn (ro)

DNAT 规则的作用，就是在 PREROUTING 检查点之前，也就是在路由之前，将流入 IP 包的目的地址和端口，改成–to-destination 所指定的新的目的地址和端口。可以看到，这个目的地址和端口，正是被代理 Pod 的 IP 地址和端口。

如下是一个iptables来实现service的案例中的iptables流量分配规则：

三个pod，每个pod承担三分之一的流量

1
2
3
4
5
6
7
8
9
10
iptables-save | grep 3306

iptables-save | grep KUBE-SERVICES

#iptables-save |grep KUBE-SVC-RVEVH2XMONK6VC5O
:KUBE-SVC-RVEVH2XMONK6VC5O - [0:0]
-A KUBE-SERVICES -d 10.10.70.95/32 -p tcp -m comment --comment "drds/mysql-read:mysql cluster IP" -m tcp --dport 3306 -j KUBE-SVC-RVEVH2XMONK6VC5O
-A KUBE-SVC-RVEVH2XMONK6VC5O -m comment --comment "drds/mysql-read:mysql" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-XC4TZYIZFYB653VI
-A KUBE-SVC-RVEVH2XMONK6VC5O -m comment --comment "drds/mysql-read:mysql" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-MK4XPBZUIJGFXKED
-A KUBE-SVC-RVEVH2XMONK6VC5O -m comment --comment "drds/mysql-read:mysql" -j KUBE-SEP-AAYXWGQJBDHUJUQ3

到这里我们基本可以看到，利用iptables规则，宿主机内核把发到宿主机上的流量按照iptables规则做dnat后发给service后端的pod，同时iptables规则可以配置每个pod的流量大小。再辅助kube-proxy监听pod的起停和健康状态并相应地更新iptables规则，这样整个service实现逻辑就很清晰了。

看起来 service 是个完美的方案，可以解决服务访问的所有问题，但是 service 这个方案（iptables 模式）也有自己的缺点。

首先，如果转发的 pod 不能正常提供服务，它不会自动尝试另一个 pod，当然这个可以通过 readiness probes 来解决。每个 pod 都有一个健康检查的机制，当有 pod 健康状况有问题时，kube-proxy 会删除对应的转发规则。

另外，nodePort 类型的服务也无法添加 TLS 或者更复杂的报文路由机制。因为只做了NAT

ipvs 实现负载均衡的原理

ipvs模式下，kube-proxy会先创建虚拟网卡，kube-ipvs0下面的每个ip都对应着svc的一个clusterIP：

1
2
3
4
5
6
# ip addr
  ...
5: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default 
    link/ether de:29:17:2a:8d:79 brd ff:ff:ff:ff:ff:ff
    inet 10.68.70.130/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever

kube-ipvs0下面绑的这些ip就是在发包的时候让内核知道如果目标ip是这些地址的话，这些地址是自身的所以包不会发出去，而是给INPUT链，这样ipvs内核模块有机会改写包做完NAT后再发走。

ipvs会放置DNAT钩子在INPUT链上，因此必须要让内核识别 VIP 是本机的 IP。这样才会过INPUT 链，要不然就通过OUTPUT链出去了。k8s 通过kube-proxy将service cluster ip 绑定到虚拟网卡kube-ipvs0。

同时在路由表中增加一些ipvs 的路由条目：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# ip route show table local  //等于ip route list table local
local 10.68.0.1 dev kube-ipvs0 proto kernel scope host src 10.68.0.1 
local 10.68.0.2 dev kube-ipvs0 proto kernel scope host src 10.68.0.2 
local 10.68.70.130 dev kube-ipvs0 proto kernel scope host src 10.68.70.130 -- ipvs
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 
broadcast 172.17.0.0 dev docker0 proto kernel scope link src 172.17.0.1 
local 172.17.0.1 dev docker0 proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 proto kernel scope link src 172.17.0.1 
local 172.20.185.192 dev tunl0 proto kernel scope host src 172.20.185.192 
broadcast 172.20.185.192 dev tunl0 proto kernel scope link src 172.20.185.192 
broadcast 172.26.128.0 dev eth0 proto kernel scope link src 172.26.137.117 
local 172.26.137.117 dev eth0 proto kernel scope host src 172.26.137.117 
broadcast 172.26.143.255 dev eth0 proto kernel scope link src 172.26.137.117 

//访问本机IP（不是 127.0.0.1），内核在路由项查找的时候判断类型是 RTN_LOCAL，仍然会使用 net->loopback_dev。也就是 lo 虚拟网卡。

而接下来，kube-proxy 就会通过 Linux 的 IPVS 模块，为这个 IP 地址设置三个 IPVS 虚拟主机，并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略。我们可以通过 ipvsadm 查看到这个设置，如下所示：

1
2
3
4
5
ipvsadm -ln |grep 10.68.114.131 -A5
TCP  10.68.114.131:3306 rr
  -> 172.20.120.143:3306          Masq    1      0          0         
  -> 172.20.185.209:3306          Masq    1      0          0         
  -> 172.20.248.143:3306          Masq    1      0          0

172.20.. 是后端真正pod的ip， 10.68.114.131 是cluster-ip.

完整的工作流程如下：

  1. 因为service cluster ip 绑定到虚拟网卡kube-ipvs0上，内核可以识别访问的 VIP 是本机的 IP.
  2. 数据包到达INPUT链.
  3. ipvs监听到达input链的数据包，比对数据包请求的服务是为集群服务，修改数据包的目标IP地址为对应pod的IP，然后将数据包发至POSTROUTING链.
  4. 数据包经过POSTROUTING链选路由后，将数据包通过tunl0网卡(calico网络模型)发送出去。从tunl0虚拟网卡获得源IP.
  5. 经过tunl0后进行ipip封包，丢到物理网络，路由到目标node（目标pod所在的node）
  6. 目标node进行ipip解包后给pod对应的网卡
  7. pod接收到请求之后，构建响应报文，改变源地址和目的地址，返回给客户端。

image.png

ipvs实际案例

ipvs负载均衡下一次完整的syn握手抓包。

宿主机上访问 curl clusterip+port 后因为这个ip绑定在kube-ipvs0上，本来是应该发出去的包（prerouting）但是内核认为这个包是访问自己，于是给INPUT链，接着被ipvs放置在INPUT中的DNAT钩子勾住，将dest ip根据负载均衡逻辑改成pod-ip，然后将数据包再发至POSTROUTING链。这时因为目标ip是POD-IP了，根据ip route 选择到出口网卡是tunl0。

可以看下内核中的路由规则：

1
2
3
4
5
# ip route get 10.68.70.130
local 10.68.70.130 dev lo src 10.68.70.130  //这条规则指示了clusterIP是发给自己的
    cache <local> 
# ip route get 172.20.185.217
172.20.185.217 via 172.26.137.117 dev tunl0 src 172.20.22.192  //这条规则指示clusterIP替换成POD IP后发给本地tunl0做ipip封包

于是cip变成了tunl0的IP，这个tunl0是ipip模式，于是将这个包打包成ipip，也就是外层sip、dip都是宿主机ip，再将这个包丢入到物理网络

网络收包到达内核后的处理流程如下，核心都是查路由表，出包也会查路由表（判断是否本机内部通信，或者外部通信的话需要选用哪个网卡）

ipvs的一些分析

ipvs是一个内核态的四层负载均衡，支持NAT以及IPIP隧道模式，但LB和RS不能跨子网，IPIP性能次之，通过ipip隧道解决跨网段传输问题，因此能够支持跨子网。而NAT模式没有限制，这也是唯一一种支持端口映射的模式。

但是ipvs只有NAT（也就是DNAT），NAT也俗称三角模式，要求RS和LVS 在一个二层网络，并且LVS是RS的网关，这样回包一定会到网关，网关再次做SNAT，这样client看到SNAT后的src ip是LVS ip而不是RS-ip。默认实现不支持ful-NAT，所以像公有云厂商为了适应公有云场景基本都会定制实现ful-NAT模式的lvs。

我们不难猜想，由于Kubernetes Service需要使用端口映射功能，因此kube-proxy必然只能使用ipvs的NAT模式。

如下Masq表示MASQUERADE（也就是SNAT），跟iptables里面的 MASQUERADE 是一个意思

1
2
3
# ipvsadm -L -n  |grep 70.130 -A12
TCP  10.68.70.130:12380 rr
  -> 172.20.185.217:9376          Masq    1      0          0

为什么clusterIP不能ping通

集群内访问cluster ip（不能ping，只能cluster ip+port）就是在到达网卡之前被内核iptalbes做了dnat/snat, cluster IP是一个虚拟ip，可以针对具体的服务固定下来，这样服务后面的pod可以随便变化。

iptables模式的svc会ping不通clusterIP，可以看如下iptables和route（留意：–reject-with icmp-port-unreachable）：

1
2
3
4
5
6
7
8
9
10
11
12
#ping 10.96.229.40
PING 10.96.229.40 (10.96.229.40) 56(84) bytes of data.
^C
--- 10.96.229.40 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

#iptables-save |grep 10.96.229.40
-A KUBE-SERVICES -d 10.96.229.40/32 -p tcp -m comment --comment "***-service:https has no endpoints" -m tcp --dport 8443 -j REJECT --reject-with icmp-port-unreachable

#ip route get 10.96.229.40
10.96.229.40 via 11.164.219.253 dev eth0  src 11.164.219.119 
    cache

如果用ipvs实现的clusterIP是可以ping通的：

  • 如果用iptables 来做转发是ping不通的，因为iptables里面这条规则只处理tcp包，reject了icmp
  • ipvs实现的clusterIP都能ping通
  • ipvs下的clusterIP ping通了也不是转发到pod，ipvs负载均衡只转发tcp协议的包
  • ipvs 的clusterIP在本地配置了route路由到回环网卡，这个包是lo网卡回复的

ipvs实现的clusterIP，在本地有添加路由到lo网卡

image.png

然后在本机抓包（到ipvs后端的pod上抓不到icmp包）：

image.png

从上面可以看出显然ipvs只会转发tcp包到后端pod，所以icmp包不会通过ipvs转发到pod上，同时在本地回环网卡lo上抓到了进去的icmp包。因为本地添加了一条路由规则，目标clusterIP被指示发到lo网卡上，lo网卡回复了这个ping包，所以通了。

NodePort Service

这种类型的 Service 也能被宿主机和 pod 访问，但与 ClusterIP 不同的是，它还能被 集群外的服务访问。

  • External node IP + port in NodePort range to any endpoint (pod), e.g. 10.0.0.1:31000
  • Enables access from outside

实现上，kube-apiserver 会从预留的端口范围内分配一个端口给 Service，然后 每个宿主机上的 kube-proxy 都会创建以下规则：

1
2
3
4
5
6
7
8
9
10
11
12
-t nat -A {PREROUTING, OUTPUT} -m conntrack --ctstate NEW -j KUBE-SERVICES

-A KUBE-SERVICES ! -s 1.1.0.0/16 -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 3.3.3.3/32 -p tcp -m tcp --dport 80 -j KUBE-SVC-NGINX
# 如果前面两条都没匹配到（说明不是 ClusterIP service 流量），并且 dst 是 LOCAL，跳转到 KUBE-NODEPORTS
-A KUBE-SERVICES -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS

-A KUBE-NODEPORTS -p tcp -m tcp --dport 31000 -j KUBE-MARK-MASQ
-A KUBE-NODEPORTS -p tcp -m tcp --dport 31000 -j KUBE-SVC-NGINX

-A KUBE-SVC-NGINX -m statistic --mode random --probability 0.50 -j KUBE-SEP-NGINX1
-A KUBE-SVC-NGINX -j KUBE-SEP-NGINX2
  1. 前面几步和 ClusterIP Service 一样；如果没匹配到 ClusterIP 规则，则跳转到 KUBE-NODEPORTS chain。
  2. KUBE-NODEPORTS chain 里做 Service 匹配，但这次只匹配协议类型和目的端口号。
  3. 匹配成功后，转到对应的 KUBE-SVC- chain，后面的过程跟 ClusterIP 是一样的。

NodePort 的一些问题

  • 首先endpoint回复不能走node 1给client，因为会被client reset（如果在node1上将src ip替换成node2的ip可能会路由不通）。回复包在 node1上要snat给node2
  • 经过snat后endpoint没法拿到client ip（slb之类是通过option带过来）
1
2
3
4
5
6
7
8
9
          client
            \ ^
             \ \
              v \
  node 1 <--- node 2
   | ^   SNAT
   | |   --->
   v |
endpoint

可以将 Service 的 spec.externalTrafficPolicy 字段设置为 local，这就保证了所有 Pod 通过 Service 收到请求之后，一定可以看到真正的、外部 client 的源地址。

而这个机制的实现原理也非常简单：这时候，一台宿主机上的 iptables 规则，会设置为只将 IP 包转发给运行在这台宿主机上的 Pod。所以这时候，Pod 就可以直接使用源地址将回复包发出，不需要事先进行 SNAT 了。这个流程，如下所示：

1
2
3
4
5
6
7
8
9
      client
      ^ /   \
     / /     \
    / v       X
  node 1     node 2
   ^ |
   | |
   | v
endpoint

当然，这也就意味着如果在一台宿主机上，没有任何一个被代理的 Pod 存在，比如上图中的 node 2，那么你使用 node 2 的 IP 地址访问这个 Service，就是无效的。此时，你的请求会直接被 DROP 掉。

kube-proxy

在 Kubernetes v1.0 版本，代理完全在 userspace 实现。Kubernetes v1.1 版本新增了 iptables 代理模式，但并不是默认的运行模式。从 Kubernetes v1.2 起，默认使用 iptables 代理。在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理模式

kube-proxy相当于service的管理方，业务流量不会走到kube-proxy，业务流量的负载均衡都是由内核层面的iptables或者ipvs来分发。

kube-proxy的三种模式：

image.png

一直以来，基于 iptables 的 Service 实现，都是制约 Kubernetes 项目承载更多量级的 Pod 的主要障碍。

ipvs 就是用于解决在大量 Service 时，iptables 规则同步变得不可用的性能问题。与 iptables 比较像的是，ipvs 的实现虽然也基于 netfilter 的钩子函数，但是它却使用哈希表作为底层的数据结构并且工作在内核态，这也就是说 ipvs 在重定向流量和同步代理规则有着更好的性能。

除了能够提升性能之外，ipvs 也提供了多种类型的负载均衡算法，除了最常见的 Round-Robin 之外，还支持最小连接、目标哈希、最小延迟等算法，能够很好地提升负载均衡的效率。

而相比于 iptables，IPVS 在内核中的实现其实也是基于 Netfilter 的 NAT 模式，所以在转发这一层上，理论上 IPVS 并没有显著的性能提升。但是，IPVS 并不需要在宿主机上为每个 Pod 设置 iptables 规则，而是把对这些“规则”的处理放到了内核态，从而极大地降低了维护这些规则的代价。这也正印证了我在前面提到过的，“将重要操作放入内核态”是提高性能的重要手段。

IPVS 模块只负责上述的负载均衡和代理功能。而一个完整的 Service 流程正常工作所需要的包过滤、SNAT 等操作，还是要靠 iptables 来实现。只不过，这些辅助性的 iptables 规则数量有限，也不会随着 Pod 数量的增加而增加。

ipvs 和 iptables 都是基于 Netfilter 实现的。

Kubernetes 中已经使用 ipvs 作为 kube-proxy 的默认代理模式。

1
/opt/kube/bin/kube-proxy --bind-address=172.26.137.117 --cluster-cidr=172.20.0.0/16 --hostname-override=172.26.137.117 --kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig --logtostderr=true --proxy-mode=ipvs

image.png

port-forward

port-forward后外部也能够像nodePort一样访问到，但是port-forward不适合大流量，一般用于管理端口，启动的时候port-forward会固定转发到一个具体的Pod上，也没有负载均衡的能力。

1
2
#在本机监听1080端口，并转发给后端的svc/nginx-ren(总是给发给svc中的一个pod)
kubectl port-forward --address 0.0.0.0 svc/nginx-ren 1080:80

kubectl looks up a Pod from the service information provided on the command line and forwards directly to a Pod rather than forwarding to the ClusterIP/Service port and allowing the cluster to load balance the service like regular service traffic.

The portforward.go Complete function is where kubectl portforward does the first look up for a pod from options via AttachablePodForObjectFn:

The AttachablePodForObjectFn is defined as attachablePodForObject in this interface, then here is the attachablePodForObject function.

To my (inexperienced) Go eyes, it appears the attachablePodForObject is the thing kubectl uses to look up a Pod to from a Service defined on the command line.

Then from there on everything deals with filling in the Pod specific PortForwardOptions (which doesn’t include a service) and is passed to the kubernetes API.

Service 和 DNS 的关系

Service 和 Pod 都会被分配对应的 DNS A 记录（从域名解析 IP 的记录）。

对于 ClusterIP 模式的 Service 来说（比如我们上面的例子），它的 A 记录的格式是：..svc.cluster.local。当你访问这条 A 记录的时候，它解析到的就是该 Service 的 VIP 地址。

而对于指定了 clusterIP=None 的 Headless Service 来说，它的 A 记录的格式也是：..svc.cluster.local。但是，当你访问这条 A 记录的时候，它返回的是所有被代理的 Pod 的 IP 地址的集合。当然，如果你的客户端没办法解析这个集合的话，它可能会只会拿到第一个 Pod 的 IP 地址。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#kubectl get pod -l app=mysql-r -o wide
NAME        READY   STATUS    RESTARTS IP               NODE          
mysql-r-0   2/2     Running   0        172.20.120.143   172.26.137.118
mysql-r-1   2/2     Running   4        172.20.248.143   172.26.137.116
mysql-r-2   2/2     Running   0        172.20.185.209   172.26.137.117

/ # nslookup mysql-r-1.mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r-1.mysql-r
Address 1: 172.20.248.143 mysql-r-1.mysql-r.default.svc.cluster.local
/ # 
/ # nslookup mysql-r-2.mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r-2.mysql-r
Address 1: 172.20.185.209 mysql-r-2.mysql-r.default.svc.cluster.local

#如果service是headless(也就是明确指定了 clusterIP: None)
/ # nslookup mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r
Address 1: 172.20.185.209 mysql-r-2.mysql-r.default.svc.cluster.local
Address 2: 172.20.248.143 mysql-r-1.mysql-r.default.svc.cluster.local
Address 3: 172.20.120.143 mysql-r-0.mysql-r.default.svc.cluster.local

#如果service 没有指定 clusterIP: None，也就是会分配一个clusterIP给集群
/ # nslookup mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r
Address 1: 10.68.90.172 mysql-r.default.svc.cluster.local

不是每个pod都会向DNS注册，只有：

  • StatefulSet中的POD会向dns注册，因为他们要保证顺序行
  • POD显式指定了hostname和subdomain，说明要靠hostname/subdomain来解析
  • Headless Service代理的POD也会注册

Ingress

kube-proxy 只能路由 Kubernetes 集群内部的流量，而我们知道 Kubernetes 集群的 Pod 位于 CNI 创建的外网络中，集群外部是无法直接与其通信的，因此 Kubernetes 中创建了 ingress 这个资源对象，它由位于 Kubernetes 边缘节点（这样的节点可以是很多个也可以是一组）的 Ingress controller 驱动，负责管理南北向流量，Ingress 必须对接各种 Ingress Controller 才能使用，比如 nginx ingress controller、traefik。Ingress 只适用于 HTTP 流量，使用方式也很简单，只能对 service、port、HTTP 路径等有限字段匹配来路由流量，这导致它无法路由如 MySQL、Redis 和各种私有 RPC 等 TCP 流量。要想直接路由南北向的流量，只能使用 Service 的 LoadBalancer 或 NodePort，前者需要云厂商支持，后者需要进行额外的端口管理。有些 Ingress controller 支持暴露 TCP 和 UDP 服务，但是只能使用 Service 来暴露，Ingress 本身是不支持的，例如 nginx ingress controller，服务暴露的端口是通过创建 ConfigMap 的方式来配置的。

Ingress是授权入站连接到达集群服务的规则集合。 你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。 用户通过POST Ingress资源到API server的方式来请求ingress。

1
2
3
4
5
 internet
     |
[ Ingress ]
--|-----|--
[ Services ]

可以将 Ingress 配置为服务提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及提供基于名称的虚拟主机等能力。 Ingress 控制器 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。

Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 类型的服务。

Ingress 其实不是Service的一个类型，但是它可以作用于多个Service，作为集群内部服务的入口。Ingress 能做许多不同的事，比如根据不同的路由，将请求转发到不同的Service上等等。

image.png

Ingress 对象，其实就是 Kubernetes 项目对“反向代理”的一种抽象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  tls:
  - hosts:
    - cafe.example.com
    secretName: cafe-secret
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea              --入口url路径
        backend:
          serviceName: tea-svc  --对应的service
          servicePort: 80
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

在实际的使用中，你只需要从社区里选择一个具体的 Ingress Controller，把它部署在 Kubernetes 集群里即可。然后，这个 Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。

目前，业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为 Kubernetes 专门维护了对应的 Ingress Controller。

一个 Ingress Controller 可以根据 Ingress 对象和被代理后端 Service 的变化，来自动进行更新的 Nginx 负载均衡器。

eBPF（extended Berkeley Packet Filter）和网络

eBPF允许程序对内核本身进行编程（即 通过程序动态修改内核的行为。传统方式要么是给内核打补丁，要么是修改内核源码 重新编译）。一句话来概括：编写代码监听内核事件，当事件发生时，BPF 代码就会在内核执行。

eBPF 最早出现在 3.18 内核中，此后原来的 BPF 就被称为 “经典” BPF（classic BPF, cBPF），cBPF 现在基本已经废弃了。很多人知道 cBPF 是因为它是 tcpdump 的包过滤语言。现在，Linux 内核只运行 eBPF，内核会将加载的 cBPF 字节码 透明地转换成 eBPF 再执行。如无特殊说明，本文中所说的 BPF 都是泛指 BPF 技术。

2015年eBPF 添加了一个新 fast path：XDP，XDP 是 eXpress DataPath 的缩写，支持在网卡驱动中运行 eBPF 代码（在软件中最早可以处理包的位置），而无需将包送 到复杂的协议栈进行处理，因此处理代价很小，速度极快。

BPF 当时用于 tcpdump，在内核中尽量前面的位置抓包，它不会 crash 内核；

bcc 是 tracing frontend for eBPF。

内核添加了一个新 socket 类型 AF_XDP。它提供的能力是：在零拷贝（ zero-copy）的前提下将包从网卡驱动送到用户空间。

AF_XDP 提供的能力与 DPDK 有点类似，不过：

  • DPDK 需要重写网卡驱动，需要额外维护用户空间的驱动代码。
  • AF_XDP 在复用内核网卡驱动的情况下，能达到与 DPDK 一样的性能。

而且由于复用了内核基础设施，所有的网络管理工具还都是可以用的，因此非常方便， 而 DPDK 这种 bypass 内核的方案导致绝大大部分现有工具都用不了了。

由于所有这些操作都是发生在 XDP 层的，因此它称为 AF_XDP。插入到这里的 BPF 代码 能直接将包送到 socket。

Facebook 公布了生产环境 XDP+eBPF 使用案例（DDoS & LB）

  • 用 XDP/eBPF 重写了原来基于 IPVS 的 L4LB，性能 10x。
  • eBPF 经受住了严苛的考验：从 2017 开始，每个进入 facebook.com 的包，都是经过了 XDP & eBPF 处理的。

Cilium 1.6 发布 第一次支持完全干掉基于 iptables 的 kube-proxy，全部功能基于 eBPF。Cilium 1.8 支持基于 XDP 的 Service 负载均衡和 host network policies。

传统的 kube-proxy 处理 Kubernetes Service 时，包在内核中的 转发路径是怎样的？如下图所示：

image.png

步骤：

  1. 网卡收到一个包（通过 DMA 放到 ring-buffer）。
  2. 包经过 XDP hook 点。
  3. 内核给包分配内存，此时才有了大家熟悉的 skb（包的内核结构体表示），然后 送到内核协议栈。
  4. 包经过 GRO 处理，对分片包进行重组。
  5. 包进入 tc（traffic control）的 ingress hook。接下来，所有橙色的框都是 Netfilter 处理点。
  6. Netfilter：在 PREROUTING hook 点处理 raw table 里的 iptables 规则。
  7. 包经过内核的连接跟踪（conntrack）模块。
  8. Netfilter：在 PREROUTING hook 点处理 mangle table 的 iptables 规则。
  9. Netfilter：在 PREROUTING hook 点处理 nat table 的 iptables 规则。
  10. 进行路由判断（FIB：Forwarding Information Base，路由条目的内核表示，译者注） 。接下来又是四个 Netfilter 处理点。
  11. Netfilter：在 FORWARD hook 点处理 mangle table 里的iptables 规则。
  12. Netfilter：在 FORWARD hook 点处理 filter table 里的iptables 规则。
  13. Netfilter：在 POSTROUTING hook 点处理 mangle table 里的iptables 规则。
  14. Netfilter：在 POSTROUTING hook 点处理 nat table 里的iptables 规则。
  15. 包到达 TC egress hook 点，会进行出方向（egress）的判断，例如判断这个包是到本 地设备，还是到主机外。
  16. 对大包进行分片。根据 step 15 判断的结果，这个包接下来可能会：发送到一个本机 veth 设备，或者一个本机 service endpoint， 或者，如果目的 IP 是主机外，就通过网卡发出去。

Cilium 如何处理POD之间的流量（东西向流量）

image.png

如上图所示，Socket 层的 BPF 程序主要处理 Cilium 节点的东西向流量（E-W）。

  • 将 Service 的 IP:Port 映射到具体的 backend pods，并做负载均衡。
  • 当应用发起 connect、sendmsg、recvmsg 等请求（系统调用）时，拦截这些请求， 并根据请求的IP:Port 映射到后端 pod，直接发送过去。反向进行相反的变换。

这里实现的好处：性能更高。

  • 不需要包级别（packet leve）的地址转换（NAT）。在系统调用时，还没有创建包，因此性能更高。
  • 省去了 kube-proxy 路径中的很多中间节点（intermediate node hops） 可以看出，应用对这种拦截和重定向是无感知的（符合 Kubernetes Service 的设计）。

Cilium处理外部流量（南北向流量）

image.png

集群外来的流量到达 node 时，由 XDP 和 tc 层的 BPF 程序进行处理， 它们做的事情与 socket 层的差不多，将 Service 的 IP:Port 映射到后端的 PodIP:Port，如果 backend pod 不在本 node，就通过网络再发出去。发出去的流程我们 在前面 Cilium eBPF 包转发路径 讲过了。

这里 BPF 做的事情：执行 DNAT。这个功能可以在 XDP 层做，也可以在 TC 层做，但 在XDP 层代价更小，性能也更高。

总结起来，Cilium的核心理念就是：

  • 将东西向流量放在离 socket 层尽量近的地方做。
  • 将南北向流量放在离驱动（XDP 和 tc）层尽量近的地方做。

性能比较

测试环境：两台物理节点，一个发包，一个收包，收到的包做 Service loadbalancing 转发给后端 Pods。

image.png

可以看出：

  • Cilium XDP eBPF 模式能处理接收到的全部 10Mpps（packets per second）。
  • Cilium tc eBPF 模式能处理 3.5Mpps。
  • kube-proxy iptables 只能处理 2.3Mpps，因为它的 hook 点在收发包路径上更后面的位置。
  • kube-proxy ipvs 模式这里表现更差，它相比 iptables 的优势要在 backend 数量很多的时候才能体现出来。

cpu：

  • XDP 性能最好，是因为 XDP BPF 在驱动层执行，不需要将包 push 到内核协议栈。
  • kube-proxy 不管是 iptables 还是 ipvs 模式，都在处理软中断（softirq）上消耗了大量 CPU。

利用 ebpf sockmap/redirection 提升 socket 性能

通过bpf监听socket来拦截所有sendmsg事件，如果是发送到本地另一个socket那么bpf就绕过TCP/IP协议栈，直接将msg送给对方socket。依赖用cgroups来指定监听的sockets事件

img

实现这个功能依赖两个东西：

  1. sockmap：这是一个存储 socket 信息的映射表。作用：

    • 一段 BPF 程序监听所有的内核 socket 事件，并将新建的 socket 记录到这个 map；
    • 另一段 BPF 程序拦截所有 sendmsg 系统调用，然后去 map 里查找 socket 对端，之后 调用 BPF 函数绕过 TCP/IP 协议栈，直接将数据发送到对端的 socket queue。

  2. cgroups：绑定cgroup下的进程，从而将这些进程下的所有 socket 加入到sockmap。

参考资料

https://imroc.cc/blog/2019/08/12/troubleshooting-with-kubernetes-network Kubernetes 网络疑难杂症排查方法

https://blog.csdn.net/qq_36183935/article/details/90734936 kube-proxy ipvs模式详解

http://arthurchiao.art/blog/ebpf-and-k8s-zh/ 大规模微服务利器：eBPF 与 Kubernetes

http://arthurchiao.art/blog/cilium-life-of-a-packet-pod-to-service-zh/ Life of a Packet in Cilium：实地探索 Pod-to-Service 转发路径及 BPF 处理逻辑

http://arthurchiao.art/blog/understanding-ebpf-datapath-in-cilium-zh/ 深入理解 Cilium 的 eBPF 收发包路径（datapath）（KubeCon, 2019）

利用 ebpf sockmap/redirection 提升 socket 性能

利用 eBPF 支撑大规模 K8s Service (LPC, 2019)

https://jiayu0x.com/2014/12/02/iptables-essential-summary/

imroc 电子书

performance

delay ack拉高实际rt的case

delay ack拉高实际rt的case

案例描述

开发人员发现client到server的rtt是2.5ms，每个请求1ms server就能处理完毕，但是监控发现的rt不是3.5（1+2.5），而是6ms，想知道这个6ms怎么来的？

如下业务监控图：实际处理时间（逻辑服务时间1ms，rtt2.4ms，加起来3.5ms），但是系统监控到的rt（蓝线）是6ms，如果一个请求分很多响应包串行发给client，这个6ms是正常的（1+2.4*N），但实际上如果send buffer足够的话，按我们前面的理解多个响应包会并发发出去，所以如果整个rt是3.5ms才是正常的。

image.png

分析

抓包来分析原因：

image.png

实际看到大量的response都是3.5ms左右，符合我们的预期，但是有少量rt被delay ack严重影响了

从下图也可以看到有很多rtt超过3ms的，这些超长时间的rtt会最终影响到整个服务rt

image.png

docker

kubernetes容器网络

kubernetes 容器网络

cni 网络

cni0 is a Linux network bridge device, all veth devices will connect to this bridge, so all Pods on the same node can communicate with each other, as explained in Kubernetes Network Model and the hotel analogy above.

cni（Container Network Interface）

CNI 全称为 Container Network Interface，是用来定义容器网络的一个 规范。containernetworking/cni 是一个 CNCF 的 CNI 实现项目，包括基本额 bridge,macvlan等基本网络插件。

一般将cni各种网络插件的可执行文件二进制放到 /opt/cni/bin ，在 /etc/cni/net.d/ 下创建配置文件，剩下的就交给 K8s 或者 containerd 了，我们不关心也不了解其实现。

比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#ls -lh /opt/cni/bin/
总用量 90M
-rwxr-x--- 1 root root 4.0M 12月 23 09:39 bandwidth
-rwxr-x--- 1 root root  35M 12月 23 09:39 calico
-rwxr-x--- 1 root root  35M 12月 23 09:39 calico-ipam
-rwxr-x--- 1 root root 3.0M 12月 23 09:39 flannel
-rwxr-x--- 1 root root 3.5M 12月 23 09:39 host-local
-rwxr-x--- 1 root root 3.1M 12月 23 09:39 loopback
-rwxr-x--- 1 root root 3.8M 12月 23 09:39 portmap
-rwxr-x--- 1 root root 3.3M 12月 23 09:39 tuning

[root@hygon3 15:55 /root]
#ls -lh /etc/cni/net.d/
总用量 12K
-rw-r--r-- 1 root root  607 12月 23 09:39 10-calico.conflist
-rw-r----- 1 root root  292 12月 23 09:47 10-flannel.conflist
-rw------- 1 root root 2.6K 12月 23 09:39 calico-kubeconfig

CNI 插件都是直接通过 exec 的方式调用，而不是通过 socket 这样 C/S 方式，所有参数都是通过环境变量、标准输入输出来实现的。

Step-by-step communication from Pod 1 to Pod 6:

  1. Package leaves *Pod 1 netns* through the *eth1* interface and reaches the root netns* through the virtual interface veth1*;
  2. Package leaves veth1* and reaches cni0*, looking for Pod 6*’s* address;
  3. Package leaves cni0* and is redirected to eth0*;
  4. Package leaves *eth0* from Master 1* and reaches the gateway*;
  5. Package leaves the *gateway* and reaches the *root netns* through the eth0* interface on Worker 1*;
  6. Package leaves eth0* and reaches cni0*, looking for Pod 6*’s* address;
  7. Package leaves *cni0* and is redirected to the *veth6* virtual interface;
  8. Package leaves the *root netns* through *veth6* and reaches the *Pod 6 netns* though the *eth6* interface;

image-20220115124747936

flannel 网络

假如POD1访问POD4：

  1. 从POD1中出来的包先到Bridge cni0上（因为POD1对应的veth挂在了cni0上）
  2. 然后进入到宿主机网络，宿主机有路由 10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink ，也就是目标ip 10.244.2.3的包交由 flannel.1 来处理
  3. flanneld 进程将包封装成vxlan 丢到eth0从宿主机1离开（封装后的目标ip是192.168.2.91）
  4. 这个封装后的vxlan udp包正确路由到宿主机2
  5. 然后经由 flanneld 解包成 10.244.2.3 ，命中宿主机2上的路由：10.244.2.0/24 dev cni0 proto kernel scope link src 10.244.2.1 ，交给cni0（这里会过宿主机iptables）
  6. cni0将包送给POD4

image-20220115132938290

对应宿主机查询到的ip、路由信息（和上图不是对应的）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#ip -d -4 addr show cni0
475: cni0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 8e:34:ba:e2:a4:c6 brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 0 vlan_protocol 802.1Q bridge_id 8000.8e:34:ba:e2:a4:c6 designated_root 8000.8e:34:ba:e2:a4:c6 root_port 0 root_path_cost 0 topology_change 0 topology_change_detected 0 hello_timer    0.00 tcn_timer    0.00 topology_change_timer    0.00 gc_timer  161.46 vlan_default_pvid 1 vlan_stats_enabled 0 group_fwd_mask 0 group_address 01:80:c2:00:00:00 mcast_snooping 1 mcast_router 1 mcast_query_use_ifaddr 0 mcast_querier 0 mcast_hash_elasticity 4 mcast_hash_max 512 mcast_last_member_count 2 mcast_startup_query_count 2 mcast_last_member_interval 100 mcast_membership_interval 26000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_response_interval 1000 mcast_startup_query_interval 3124 mcast_stats_enabled 0 mcast_igmp_version 2 mcast_mld_version 1 nf_call_iptables 0 nf_call_ip6tables 0 nf_call_arptables 0 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
    inet 192.168.3.1/24 brd 192.168.3.255 scope global cni0
       valid_lft forever preferred_lft forever

#ip -d -4 addr show flannel.1
474: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
    link/ether fe:49:64:ae:36:af brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 68 maxmtu 65535
    vxlan id 1 local 10.133.2.252 dev bond0 srcport 0 0 dstport 8472 nolearning ttl auto ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
    inet 192.168.3.0/32 brd 192.168.3.0 scope global flannel.1
       valid_lft forever preferred_lft forever
       
[root@hygon239 20:06 /root]
#kubectl describe node hygon252 | grep -C5 -i vtep  //可以看到VetpMAC 以及对应的宿主机IP（vxlan封包后的IP）
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/arch=amd64
                    kubernetes.io/hostname=hygon252
                    kubernetes.io/os=linux
Annotations:        flannel.alpha.coreos.com/backend-data: {"VNI":1,"VtepMAC":"fe:49:64:ae:36:af"}
                    flannel.alpha.coreos.com/backend-type: vxlan
                    flannel.alpha.coreos.com/kube-subnet-manager: true
                    flannel.alpha.coreos.com/public-ip: 10.133.2.252
                    kubeadm.alpha.kubernetes.io/cri-socket: /var/run/dockershim.sock
                    node.alpha.kubernetes.io/ttl: 0

image-20220115133500854

kubernetes calico 网络

1
2
3
4
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

#或者老版本的calico
curl https://docs.projectcalico.org/v3.15/manifests/calico.yaml -o calico.yaml

默认calico用的是ipip封包（这个性能跟原生网络差多少有待验证，本质也是overlay网络，比flannel那种要好很多吗？）

跨宿主机的两个容器之间的流量链路是：

cali-容器eth0->宿主机cali27dce37c0e8->tunl0->内核ipip模块封包->物理网卡（ipip封包后）—远程–> 物理网卡->内核ipip模块解包->tunl0->cali-容器

image.png

Calico IPIP模式对物理网络无侵入，符合云原生容器网络要求；使用IPIP封包，性能略低于Calico BGP模式；无法使用传统防火墙管理、也无法和存量网络直接打通。Pod在Node做SNAT访问外部，Pod流量不易被监控。

calico ipip网络不通

集群有五台机器192.168.0.110-114, 同时每个node都有另外一个ip：192.168.3.110-114，部分节点之间不通。每台机器部署好calico网络后，会分配一个 /26 CIRD 子网（64个ip）。

案例1

目标机是10.122.127.128（宿主机ip 192.168.3.112），如果从10.122.17.64（宿主机ip 192.168.3.110） ping 10.122.127.128不通，查看10.122.127.128路由表：

1
2
3
4
5
6
[root@az3-k8s-13 ~]# ip route |grep tunl0
10.122.17.64/26 via 10.122.127.128 dev tunl0  //这条路由不通
[root@az3-k8s-13 ~]# ip route del 10.122.17.64/26 via 10.122.127.128 dev tunl0 ; ip route add 10.122.17.64/26 via 192.168.3.110 dev tunl0 proto bird onlink

[root@az3-k8s-13 ~]# ip route |grep tunl0
10.122.17.64/26 via 192.168.3.110 dev tunl0 proto bird onlink //这样就通了

在10.122.127.128抓包如下，明显可以看到icmp request到了 tunl0网卡，tunl0网卡也回复了，但是回复包没有经过kernel ipip模块封装后发到eth1上：

image.png

正常机器应该是这样，上图不正常的时候缺少红框中的reply：

image.png

解决：

1
2
ip route del 10.122.17.64/26 via 10.122.127.128 dev tunl0 ; 
ip route add 10.122.17.64/26 via 192.168.3.110 dev tunl0 proto bird onlink

删除错误路由增加新的路由就可以了，新增路由的意思是从tunl0发给10.122.17.64/26的包下一跳是 192.168.3.110。

via 192.168.3.110 表示下一跳的ip

onlink参数的作用：
使用这个参数将会告诉内核，不必检查网关是否可达。因为在linux内核中，网关与本地的网段不同是被认为不可达的，从而拒绝执行添加路由的操作。

因为tunl0网卡ip的 CIDR 是32，也就是不属于任何子网，那么这个网卡上的路由没有网关，配置路由的话必须是onlink, 内核存也没法根据子网来选择到这块网卡，所以还会加上 dev 指定网卡。

案例2

集群有五台机器192.168.0.110-114, 同时每个node都有另外一个ip：192.168.3.110-114，只有node2没有192.168.3.111这个ip，结果node2跟其他节点都不通：

1
2
3
4
5
6
7
8
9
10
11
12
#calicoctl node status
Calico process is running.

IPv4 BGP status
+---------------+-------------------+-------+------------+-------------+
| PEER ADDRESS  |     PEER TYPE     | STATE |   SINCE    |    INFO     |
+---------------+-------------------+-------+------------+-------------+
| 192.168.0.111 | node-to-node mesh | up    | 2020-08-29 | Established |
| 192.168.3.112 | node-to-node mesh | up    | 2020-08-29 | Established |
| 192.168.3.113 | node-to-node mesh | up    | 2020-08-29 | Established |
| 192.168.3.114 | node-to-node mesh | up    | 2020-08-29 | Established |
+---------------+-------------------+-------+------------+-------------+

从node4 ping node2，然后在node2上抓包，可以看到 icmp request都发到了node2上，但是node2收到后没有发给tunl0：

image.png

所以icmp没有回复，这里的问题在于kernel收到包后为什么不给tunl0

同样，在node2上ping node4，同时在node2上抓包，可以看到发给node4的request包和reply包：

image.png

从request包可以看到src ip 是0.111， dest ip是 3.113，因为 node2 没有192.168.3.111这个ip

非常关键的我们看到node4的回复包 src ip 不是3.113，而是0.113（根据node4的路由就应该是0.113）

image.png

这就是问题所在，从node4过来的ipip包src ip都是0.113，实际这里ipip能认识的只是3.113.

如果这个时候在3.113机器上把0.113网卡down掉，那么3.113上的：

10.122.124.128/26 via 192.168.0.111 dev tunl0 proto bird onlink 路由被自动删除，3.113将不再回复request。这是因为calico记录的node2的ip是192.168.0.111，所以会自动增加

解决办法，在node4上删除这条路由记录，也就是强制让回复包走3.113网卡，这样收发的ip就能对应上了

1
2
3
4
ip route del 192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.113
//同时将默认路由改到3.113
ip route del default via 192.168.0.253 dev eth0; 
ip route add default via 192.168.3.253 dev eth1

最终OK后，node4上的ip route是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[root@az3-k8s-14 ~]# ip route
default via 192.168.3.253 dev eth1 
10.122.17.64/26 via 192.168.3.110 dev tunl0 proto bird onlink 
10.122.124.128/26 via 192.168.0.111 dev tunl0 proto bird onlink 
10.122.127.128/26 via 192.168.3.112 dev tunl0 proto bird onlink 
blackhole 10.122.157.128/26 proto bird 
10.122.157.129 dev cali19f6ea143e3 scope link 
10.122.157.130 dev cali09e016ead53 scope link 
10.122.157.131 dev cali0ad3225816d scope link 
10.122.157.132 dev cali55a5ff1a4aa scope link 
10.122.157.133 dev cali01cf8687c65 scope link 
10.122.157.134 dev cali65232d7ada6 scope link 
10.122.173.128/26 via 192.168.3.114 dev tunl0 proto bird onlink 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
192.168.3.0/24 dev eth1 proto kernel scope link src 192.168.3.113

正常后的抓包, 注意这里drequest的est ip 和reply的 src ip终于一致了：

1
2
3
4
5
6
7
8
9
//request
00:16:3e:02:06:1e > ee:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 64, id 57971, offset 0, flags [DF], proto IPIP (4), length 104)
    192.168.0.111 > 192.168.3.110: (tos 0x0, ttl 64, id 18953, offset 0, flags [DF], proto ICMP (1), length 84)
    10.122.124.128 > 10.122.17.64: ICMP echo request, id 22001, seq 4, length 64
    
//reply    
ee:ff:ff:ff:ff:ff > 00:16:3e:02:06:1e, ethertype IPv4 (0x0800), length 118: (tos 0x0, ttl 64, id 2565, offset 0, flags [none], proto IPIP (4), length 104)
    192.168.3.110 > 192.168.0.111: (tos 0x0, ttl 64, id 26374, offset 0, flags [none], proto ICMP (1), length 84)
    10.122.17.64 > 10.122.124.128: ICMP echo reply, id 22001, seq 4, length 64

总结下来这两个案例都还是对路由不够了解，特别是案例2，因为有了多个网卡后导致路由更复杂。calico ipip的基本原理就是利用内核进行ipip封包，然后修改路由来保证网络的畅通。

flannel网络不通

firewalld

在麒麟系统的物理机上通过kubeadm setup集群，发现有的环境flannel网络不通，在宿主机上ping 其它物理机flannel.0网卡的ip，通过在对端宿主机抓包发现icmp收到后被防火墙扔掉了，抓包中可以看到错误信息：icmp unreachable - admin prohibited

下图中正常的icmp是直接ping 物理机ip

image-20211228203650921

The “admin prohibited filter” seen in the tcpdump output means there is a firewall blocking a connection. It does it by sending back an ICMP packet meaning precisely that: the admin of that firewall doesn’t want those packets to get through. It could be a firewall at the destination site. It could be a firewall in between. It could be iptables on the Linux system.

发现有问题的环境中宿主机的防火墙设置报错了：

1
2
12月 28 23:35:08 hygon253 firewalld[10493]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -X DOCKER-ISOLATION-STAGE-1' failed: iptables: No chain/target/match by that name.
12月 28 23:35:08 hygon253 firewalld[10493]: WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w10 -t filter -F DOCKER-ISOLATION-STAGE-2' failed: iptables: No chain/target/match by that name.

应该是因为启动docker的时候 firewalld 是运行着的

Do you have firewalld enabled, and was it (re)started after docker was started? If so, then it’s likely that firewalld wiped docker’s IPTables rules. Restarting the docker daemon should re-create those rules.

停掉 firewalld 服务可以解决这个问题

掉电重启后flannel网络不通

flannel能收到包，但是cni0收不到包，说明包进到了目标宿主机，但是从flannel解开udp转送到cni的时候出了问题，大概率是iptables 拦截了包

1
2
3
4
5
It seems docker version >=1.13 will add iptables rule like below,and it make this issue happen:
iptables -P FORWARD DROP

All you need to do is add a rule below:
iptables -P FORWARD ACCEPT

清理

cni信息

1
2
/etc/cni/net.d/*
/var/lib/cni/ 下存放有ip分配信息

calico创建的tunl0网卡是个tunnel，可以通过 ip tunnel show来查看，清理不掉（重启可以清理掉tunl0）

1
2
3
4
5
6
ip link set dev tunl0 name tunl0_fallback

或者
/sbin/ip link set eth1 down
/sbin/ip link set eth1 name eth123
/sbin/ip link set eth123 up

flannel

1
2
ip link delete flannel.1
ip link delete cni0

netns

以下case创建一个名为 ren 的netns，然后在里面增加一对虚拟网卡veth1 veth1_p, veth1放置在ren里面，veth1_p 放在物理机上，给他们配置上ip并up就能通了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
1004  [2021-10-27 10:49:08] ip netns add ren
1005  [2021-10-27 10:49:12] ip netns show
1006  [2021-10-27 10:49:22] ip netns exec ren route   //为空
1007  [2021-10-27 10:49:29] ip netns exec ren iptables -L
1008  [2021-10-27 10:49:55] ip link add veth1 type veth peer name veth1_p //此时宿主机上能看到这两块网卡
1009  [2021-10-27 10:50:07] ip link set veth1 netns ren //将veth1从宿主机默认网络空间挪到ren中，宿主机中看不到veth1了
1010  [2021-10-27 10:50:18] ip netns exec ren route  
1011  [2021-10-27 10:50:25] ip netns exec ren iptables -L
1012  [2021-10-27 10:50:39] ifconfig
1013  [2021-10-27 10:50:51] ip link list
1014  [2021-10-27 10:51:29] ip netns exec ren ip link list
1017  [2021-10-27 10:53:27] ip netns exec ren ip addr add 172.19.0.100/24 dev veth1 
1018  [2021-10-27 10:53:31] ip netns exec ren ip link list
1019  [2021-10-27 10:53:39] ip netns exec ren ifconfig
1020  [2021-10-27 10:53:42] ip netns exec ren ifconfig -a
1021  [2021-10-27 10:54:13] ip netns exec ren ip link set dev veth1 up
1022  [2021-10-27 10:54:16] ip netns exec ren ifconfig
1023  [2021-10-27 10:54:22] ping 172.19.0.100
1024  [2021-10-27 10:54:35] ifconfig -a
1025  [2021-10-27 10:55:03] ip netns exec ren ip addr add 172.19.0.101/24 dev veth1_p
1026  [2021-10-27 10:55:10] ip addr add 172.19.0.101/24 dev veth1_p
1027  [2021-10-27 10:55:16] ifconfig veth1_p
1028  [2021-10-27 10:55:30] ip link set dev veth1_p up
1029  [2021-10-27 10:55:32] ifconfig veth1_p
1030  [2021-10-27 10:55:38] ping 172.19.0.101
1031  [2021-10-27 10:55:43] ping 172.19.0.100
1032  [2021-10-27 10:55:53] ip link set dev veth1_p down
1033  [2021-10-27 10:55:54] ping 172.19.0.100
1034  [2021-10-27 10:55:58] ping 172.19.0.101
1035  [2021-10-27 10:56:08] ifconfig veth1_p
1036  [2021-10-27 10:56:32] ping 172.19.0.101
1037  [2021-10-27 10:57:04] ip netns exec ren route
1038  [2021-10-27 10:57:52] ip netns exec ren ping 172.19.0.101
1039  [2021-10-27 10:57:58] ip link set dev veth1_p up
1040  [2021-10-27 10:57:59] ip netns exec ren ping 172.19.0.101
1041  [2021-10-27 10:58:06] ip netns exec ren ping 172.19.0.100
1042  [2021-10-27 10:58:14] ip netns exec ren ifconfig
1043  [2021-10-27 10:58:19] ip netns exec ren route
1044  [2021-10-27 10:58:26] ip netns exec ren ping 172.19.0.100 -I veth1
1045  [2021-10-27 10:58:58] ifconfig veth1_p
1046  [2021-10-27 10:59:10] ping 172.19.0.100
1047  [2021-10-27 10:59:26] ip netns exec ren ping 172.19.0.101 -I veth1

把网卡加入到docker0的bridge下
1160  [2021-10-27 12:17:37] brctl show
1161  [2021-10-27 12:18:05] ip link set dev veth3_p master docker0
1162  [2021-10-27 12:18:09] ip link set dev veth1_p master docker0
1163  [2021-10-27 12:18:13] ip link set dev veth2 master docker0
1164  [2021-10-27 12:18:15] brctl show

btctl showmacs br0

Linux 上存在一个默认的网络命名空间，Linux 中的 1 号进程初始使用该默认空间。Linux 上其它所有进程都是由 1 号进程派生出来的，在派生 clone 的时候如果没有额外特别指定，所有的进程都将共享这个默认网络空间。

所有的网络设备刚创建出来都是在宿主机默认网络空间下的。可以通过 ip link set 设备名 netns 网络空间名 将设备移动到另外一个空间里去，socket也是归属在某一个网络命名空间下的，由创建socket进程所在的netns来决定socket所在的netns

1
2
3
4
5
6
7
8
9
10
11
12
//file: net/socket.c
int sock_create(int family, int type, int protocol, struct socket **res)
{
 return __sock_create(current->nsproxy->net_ns, family, type, protocol, res, 0);
}

//file: include/net/sock.h
static inline
void sock_net_set(struct sock *sk, struct net *net)
{
 write_pnet(&sk->sk_net, net);
}

内核提供了三种操作命名空间的方式，分别是 clone、setns 和 unshare。ip netns add 使用的是 unshare，原理和 clone 是类似的。

Image

每个 net 下都包含了自己的路由表、iptable 以及内核参数配置等等

参考资料

https://morven.life/notes/networking-3-ipip/

https://www.cnblogs.com/bakari/p/10564347.html

https://www.cnblogs.com/goldsunshine/p/10701242.html

MySQL

MySQL JDBC StreamResult 和 net_write_timeout

MySQL JDBC StreamResult 和 net_write_timeout

MySQL JDBC 拉取数据的三种方式

MySQL JDBC 在从 MySQL 拉取数据的时候有三种方式：

  1. 简单模式，也就是默认模式，数据都先要从MySQL Server发到client的OS TCP buffer，然后JDBC把 OS buffer读取到JVM内存中，读取到JVM内存的过程中憋着不让client读取，全部读完再通知inputStream.read(). 数据大的话容易导致JVM OOM
  2. useCursorFetch=true，配合FetchSize，也就是MySQL Server把查到的数据先缓存到本地磁盘，然后按照FetchSize挨个发给client。这需要占用MySQL很高的IOPS（先写磁盘缓存），其次每次Fetch需要一个RTT，效率不高。
  3. Stream读取，Stream读取是在执行SQL前设置FetchSize：statement.setFetchSize(Integer.MIN_VALUE)，同时确保游标是只读、向前滚动的（为游标的默认值），MySQL JDBC内置的操作方法是将Statement强制转换为：com.mysql.jdbc.StatementImpl，调用其方法：enableStreamingResults()，这2者达到的效果是一致的，都是启动Stream流方式读取数据。这个时候MySQL不停地发数据，inputStream.read()不停地读取。一般来说发数据更快些，很快client的OS TCP recv buffer就满了，这时MySQL停下来等buffer有空闲就继续发数据。等待过程中如果超过 net_write_timeout MySQL就会报错，中断这次查询。

从这里的描述来看，数据小的时候第一种方式还能接受，但是数据大了容易OOM，方式三看起来不错，但是要特别注意 net_write_timeout。

1和3对MySQL Server来说处理上没有啥区别，也感知不到这两种方式的不同。只是对1来说从OS Buffer中的数据复制到JVM内存中速度快，JVM攒多了数据内存就容易爆掉；对3来说JDBC一条条将OS Buffer中的数据复制到JVM(内存复制速度快)同时返回给execute挨个处理（慢），一般来说挨个处理要慢一些，这就导致了从OS Buffer中复制数据较慢，容易导致 TCP Receive Buffer满了，那么MySQL Server感知到的就是TCP 传输窗口为0了，导致暂停传输数据。

在数据量很小的时候方式三没什么优势，因为总是多一次set net_write_tiemout，也就是多了一次RTT。

img

MySQL timeout

  1. Creates a statement by calling Connection.createStatement().
  2. Calls Statement.executeQuery().
  3. The statement transmits the Query to MySqlServer by using the internal connection.
  4. The statement creates a new timeout-execution thread for timeout process.
  5. For version 5.1.x, it changes to assign 1 thread for each connection.
  6. Registers the timeout execution to the thread.
  7. Timeout occurs.
  8. The timeout-execution thread creates a connection that has the same configurations as the statement.
  9. Transmits the cancel Query (KILL QUERY “connectionId“) by using the connection.

Figure 6: QueryTimeout Execution Process for MySQL JDBC Statement (5.0.8).

参考《揭秘JDBC超时机制》

net_read_timeout

Command-Line Format --net-read-timeout=#
System Variable net_read_timeout
Scope Global, Session
Dynamic Yes
Type Integer
Default Value 30
Minimum Value 1
Maximum Value 31536000
Unit seconds

The number of seconds to wait for more data from a connection before aborting the read. When the server is reading from the client, net_read_timeout is the timeout value controlling when to abort.

如下图，MySQL Server监听3017端口，195228号包 客户端发一个SQL 给 MySQL Server，但是似乎这个时候正好网络异常，30秒钟后（从 SQL 请求的前一个 ack 开始算，Server应该一直都没有收到），Server 端触发 net_read_timeout 超时异常（疑问：这里没有 net_read_timeout 描述的读取了一半的现象）

image-20230209155545142

解决方案：建议调大 net_read_timeout 以应对可能出现的网络丢包

net_write_timeout

show processlist 看到的State的值一直处于**“Sending to client”**，说明SQL这个语句已经执行完毕，而此时由于请求的数据太多，MySQL不停写入net buffer，而net buffer又不停的将数据写入服务端的网络棧，服务器端的网络栈（socket send buffer）被写满了，又没有被客户端读取并消化，这时读数据的流程就被MySQL暂停了。直到客户端完全读取了服务端网络棧的数据，这个状态才会消失。

先看下 net_write_timeout的解释：The number of seconds to wait for a block to be written to a connection before aborting the write. 只针对执行查询中的等待超时，网络不好，tcp buffer满了（应用迟迟不读走数据）等容易导致mysql server端报net_write_timeout错误，指的是mysql server hang在那里长时间无法发送查询结果。

Property Value
Command-Line Format --net-write-timeout=#
System Variable net_write_timeout
Scope Global, Session
Dynamic Yes
Type Integer
Default Value 60
Minimum Value 1

报这个错就是RDS等了net_write_timeout这么久没写数据，可能是客户端卡死没有读走数据，也可能是从多个分片挨个拉取，还没开始拉第7片前面6片拉取耗时就超过了net_write_timeout。

案例：DRDS 到 MySQL 多个分片拉取数据生成了许多 cursor 并发执行,但拉数据的时候是串行拉取的,如果用户端拉取数据过慢会导致最后一个 cursor 执行完成之后要等待很久.会超过 MySQL 的 net_write_timeout 配置从而引发报错. 也就是最后一个cursor打开后一直没有去读取数据，直到MySQL Server 触发 net_write_timeout 异常

首先可以尝试在 DRDS jdbcurl 配置 netTimeoutForStreamingResults 参数,设置为 0 可以使其一直等待,或设置一个合理的值(秒).

从JDBC驱动中可以看到，当调用PreparedStatement的executeQuery() 方法的时候，如果我们是去获取流式resultset的话，就会默认执行SET net_write_timeout= ？ 这个命令去重新设置timeout时间。源代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
if (doStreaming && this.connection.getNetTimeoutForStreamingResults() > 0) {  
            java.sql.Statement stmt = null;  
            try {  
                stmt = this.connection.createStatement();                    ((com.mysql.jdbc.StatementImpl)stmt).executeSimpleNonQuery(this.connection, "SET net_write_timeout="   
                        + this.connection.getNetTimeoutForStreamingResults());  
            } finally {  
                if (stmt != null) {  
                    stmt.close();  
                }  
            }  
        }  
        
//另外DRDS代码 AppLoader.java 中写死了net_write_timeout 8小时
ds.putConnectionProperties(ConnectionProperties.NET_WRITE_TIMEOUT, 28800);

而 this.connection.getNetTimeoutForStreamingResults() 默认是600秒，或者在JDBC连接串种通过属性 netTimeoutForStreamingResults 来指定。

netTimeoutForStreamingResults 默认值：

What value should the driver automatically set the server setting ‘net_write_timeout’ to when the streaming result sets feature is in use? Value has unit of seconds, the value “0” means the driver will not try and adjust this value.

Default Value 600
Since Version 5.1.0

一般在数据导出场景中容易出现 net_write_timeout 这个错误，比如这个错误堆栈：

或者：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
ErrorMessage:
Communications link failure
The last packet successfully received from the server was 7 milliseconds ago.  The last packet sent successfully to the server was 709,806 milliseconds ago. - com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 7 milliseconds ago.  The last packet sent successfully to the server was 709,806 milliseconds ago.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:377)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:1036)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3427)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3327)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3814)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:870)
	at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1928)
	at com.mysql.jdbc.RowDataDynamic.nextRecord(RowDataDynamic.java:378)
	at com.mysql.jdbc.RowDataDynamic.next(RowDataDynamic.java:358)
	at com.mysql.jdbc.ResultSetImpl.next(ResultSetImpl.java:6337)
	at com.alibaba.datax.plugin.rdbms.reader.CommonRdbmsReader$Task.startRead(CommonRdbmsReader.java:275)
	at com.alibaba.datax.plugin.reader.drdsreader.DrdsReader$Task.startRead(DrdsReader.java:148)
	at com.alibaba.datax.core.taskgroup.runner.ReaderRunner.run(ReaderRunner.java:62)
	at java.lang.Thread.run(Thread.java:834)
Caused by: java.io.EOFException: Can not read response from server. Expected to read 258 bytes, read 54 bytes before connection was unexpectedly lost.
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:2914)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3387)
	... 11 more

特别注意

JDBC驱动报如下错误

Application was streaming results when the connection failed. Consider raising value of ‘net_write_timeout’ on the server. - com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Application was streaming results when the connection failed. Consider raising value of ‘net_write_timeout’ on the server.

不一定是 net_write_timeout 设置过小导致的，JDBC 在 streaming 流模式下只要连接异常就会报如上错误，比如：

  • 连接被 TCP reset
  • 连接因为某种原因(比如 QueryTimeOut、比如用户监控kill 慢查询) 触发 kill Query导致连接中断

比如出现内核bug，内核卡死不发包的话，客户端同样报 net_write_timeout 错误

max_allowed_packet: 单个SQL或者单条记录的最大大小

一些其他的 Timeout

connectTimeout：表示等待和MySQL数据库建立socket链接的超时时间，默认值0，表示不设置超时，单位毫秒，建议30000。 JDBC驱动连接属性

queryTimeout：超时后jdbc驱动触发新建一个连接来发送一个 kill 给DB

socketTimeout：JDBC参数，表示客户端发送请求给MySQL数据库后block在read的等待数据的超时时间，linux系统默认的socketTimeout为30分钟，可以不设置。socketTimeout 超时不会触发发kill，只会断开tcp连接。

要特别注意socketTimeout仅仅是指等待socket数据时间，如果在传输数据那么这个值就没有用了。socketTimeout通过mysql-connector中的NativeProtocol最终设置在socketOptions上

image-20211024171459127

static final int SO_TIMEOUT。 Set a timeout on blocking Socket operations:

ServerSocket.accept();
SocketInputStream.read();
DatagramSocket.receive();

The option must be set prior to entering a blocking operation to take effect. If the timeout expires and the operation would continue to block, java.io.InterruptedIOException is raised. The Socket is not closed in this case.

Statement Timeout：用来限制statement的执行时长，timeout的值通过调用JDBC的java.sql.Statement.setQueryTimeout(int timeout) API进行设置。不过现在开发者已经很少直接在代码中设置，而多是通过框架来进行设置。

max_execution_time：The execution timeout for SELECT statements, in milliseconds. If the value is 0, timeouts are not enabled. MySQL 属性，可以set修改，一般用来设置一个查询最长不超过多少秒，避免一个慢查询一直在跑，跟statement timeout对应。

Property Value
Command-Line Format --max-execution-time=#
System Variable max_execution_time
Scope Global, Session
Dynamic Yes
Type Integer
Default Value 0

wait_timeout The number of seconds the server waits for activity on a noninteractive connection before closing it. MySQL 属性，一般设置tcp keepalive后这个值基本不会超时（这句话存疑 202110）。

On thread startup, the session wait_timeout value is initialized from the global wait_timeout value or from the global interactive_timeout value, depending on the type of client (as defined by the CLIENT_INTERACTIVE connect option to mysql_real_connect()). See also interactive_timeout.

Property Value
Command-Line Format --wait-timeout=#
System Variable wait_timeout
Scope Global, Session
Dynamic Yes
Type Integer
Default Value 28800
Minimum Value 1
Maximum Value (Other) 31536000
Maximum Value (Windows) 2147483

一般来说应该设置： max_execution_time/statement timeout < Tranction Timeout < socketTimeout

SocketTimeout

这个 httpclient 的bug 就是在 TCP 连接握手成功(只受ConnectTimeout影响，SocketTimeout还不起作用)后，还需要进行 SSL的数据交换(HandShake)，但因为httpclient是在连接建立后(含 SSL HandShake)才设置的 SocketTimeout，导致在SSL HandShake的时候卡在了读数据，此时恰好还没设置SocketTimeout，导致连接永久卡死在SSL HandShake的读数据

所以代码的fix方案就是在建连接前就设置好 SocketTimeout。

一次 PreparedStatement 执行

useServerPrepStmts=true&cachePrepStmts=true

5.0.5版本后的驱动 useServerPrepStmts 默认值是false；另外跨Statement是没法重用PreparedStatement预编译的，还需要设置 cachePrepStmts 才可以。

对于打开预编译的URL（String url = “jdbc:mysql://localhost:3306/studb?useServerPrepStmts=true&cachePrepStmts=true”）获取数据库连接之后，本质是获取预编译语句 **pstmt = conn.prepareStatement(sql)**时会向MySQL服务端发送一个RPC，发送一个预编译的SQL模板（驱动会拼接MySQL预编译语句prepare s1 from ‘select * from user where id = ?’），然后MySQL服务端会编译好收到的SQL模板，再会为此预编译模板语句分配一个 serverStatementId发送给JDBC驱动，这样以后PreparedStatement就会持有当前预编译语句的服务端的serverStatementId,并且会把此 PreparedStatement缓存在当前数据库连接中，以后对于相同SQL模板的操作 pstmt.executeUpdate()，都用相同的PreparedStatement，执行SQL时只需要发送 serverStatementId 和参数，节省一次SQL编译, 直接执行。并且对于每一个连接(驱动端及MySQL服务端)都有自己的prepare cache,具体的源码实现是在com.mysql.jdbc.ServerPreparedStatement中实现。

根据SQL模板和设置的参数，解析成一条完整的SQL语句，最后根据MySQL协议，序列化成字节流，RPC发送给MySQL服务端

1
2
// 解析封装需要发送的SQL语句,序列化成MySQL协议对应的字节流
Buffer sendPacket = fillSendPacket();

准备好需要发送的MySQL协议的字节流（sendPacket）后，就可以一路通过ConnectionImpl.execSQL –> MysqlIO.sqlQueryDirect –> MysqlIO.send – > OutPutStram.write把字节流数据通过Socket发送给MySQL服务器，然后线程阻塞等待服务端返回结果数据，拿到数据后再根据MySQL协议反序列化成我们熟悉的ResultSet对象。

image-20230802101859567

SocketTimeoutException: Read timed out

如果SQL 超过 SocketTimeout 报错如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
#java -cp .:./mysql-connector-java-5.1.45.jar Test "jdbc:mysql://127.0.0.1:3306/test?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&connectTimeout=15000&socketTimeout=3700" root 123 "select sleep(10), id from sbtest1 where id= ?" 100
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 3,705 milliseconds ago.  The last packet sent successfully to the server was 3,705 milliseconds ago.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3559)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3459)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3900)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2527)
	at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1283)
	at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:783)
	at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1966)
	at Test.main(Test.java:31)
Caused by: java.net.SocketTimeoutException: Read timed out
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
	at java.net.SocketInputStream.read(SocketInputStream.java:171)
	at java.net.SocketInputStream.read(SocketInputStream.java:141)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3008)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3469)
	... 7 more

连接超时

在防火墙里设置了 3306 的包都 drop

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#java -cp .:./mysql-connector-java-5.1.45.jar Test "jdbc:mysql://127.0.0.1:3306/test?useSSL=false&useServerPrepStmts=true&cachePrepStmts=true&connectTimeout=15000&socketTimeout=3700" root 123 "select sleep(10), id from sbtest1 where id= ?" 100
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:990)
	at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:341)
	at com.mysql.jdbc.ConnectionImpl.coreConnect(ConnectionImpl.java:2186)
	at com.mysql.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:2219)
	at com.mysql.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:2014)
	at com.mysql.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:776)
	at com.mysql.jdbc.JDBC4Connection.<init>(JDBC4Connection.java:47)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.ConnectionImpl.getInstance(ConnectionImpl.java:386)
	at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:330)
	at java.sql.DriverManager.getConnection(DriverManager.java:664)
	at java.sql.DriverManager.getConnection(DriverManager.java:247)
	at Test.main(Test.java:26)
Caused by: java.net.ConnectException: 连接超时 (Connection timed out)
	at java.net.PlainSocketImpl.socketConnect(Native Method)
	at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
	at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
	at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
	at java.net.Socket.connect(Socket.java:607)
	at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:211)
	at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:300)
	... 15 more

SocketException connection timed out

image-20240522165928366

image-20240522165849942

案例

设置JDBC参数不合理（不设置的话默认值是：queryTimeout=10s，socketTimeout=10s），会导致在异常情况下，第二条get获得了第一条的结果，拿到了错误的数据，数据库则表现正常

触发：

同事设置了queryTimeout 和socketTimeout，当queryTimeout 先触发，并发送了 kill id 给 Server，此时标志链接是 Cancle 状态，在网络不太好的场景下 Server 没有收到或者收到这个 kill 晚了，这时 socketTimeout 到达触发时间，连接抛CommunicationsException（严重异常，触发后连接应该断开）, 但JDBC会检查请求是否被cancle了，如果Cancle 就会抛出MySQLTimeoutException异常，这是一个普通异常，连接会被重新放回连接池重用（导致下一个获取这个连接的线程可能会得到前一个请求的response）。

解决办法：

  1. TDDL：在TDDL JDBC接口层面屏蔽掉用户所有的queryTimeout设置，全部使用socketTimeout进行设置，同时配置好正确的mysql exception sorter(断开超时链接).
  2. JDBC Driver：判断这个query是否被cancel时，同时判断当前 SQLException的errorCode，如果errorCode是ER_QUERY_INTERRUPTED且callingStatement被cancel掉，才会用MySQLTimeoutException覆盖原来的SQLexception。避免了CommunicationsException被覆盖的问题
  3. MYSQL Server：添加了 max_statement_time，来替代queryTimeout，当执行时间超过 max_statement_time 时，Server 直接 kill，不需要客户端发送 kill

queryTimeout（queryTimeoutKillsConnection=True–来强制关闭连接）会触发启动一个新的连接向server发送 kill id的命令，MySQL5.7增加了max_statement_time/max_execution_time来做到在server上直接检测到这种查询，然后结束掉。

jdbc 和 RDS之间 socket_timeout

jdbc驱动设置socketTimeout=1459，如果是socketTimeout触发客户端断开后，server端的SQL会继续执行，如果是client被kill则server端的SQL会被终止

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
# java -cp /home/admin/drds-server/lib/*:. Test "jdbc:mysql://172.16.40.215:3008/bank_000000?socketTimeout=1459" "user" "pass" "select sleep(2)" "1"
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 1,461 milliseconds ago.  The last packet sent successfully to the server was 1,461 milliseconds ago.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3749)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3649)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4090)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2658)
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2811)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2806)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2764)
	at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1399)
	at Test.main(Test.java:29)
Caused by: java.net.SocketTimeoutException: Read timed out
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
	at java.net.SocketInputStream.read(SocketInputStream.java:171)
	at java.net.SocketInputStream.read(SocketInputStream.java:141)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 8 more
	
	或者开协程后的错误堆栈
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 1,460 milliseconds ago.  The last packet sent successfully to the server was 1,459 milliseconds ago.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3749)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3649)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4090)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2658)
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2811)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2806)
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2764)
	at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1399)
	at Test.main(Test.java:29)
Caused by: java.net.SocketTimeoutException: time out
	at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:244)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 8 more

对应抓包，没有 kill动作

image-20220601141709318

CN 和 DN 间socket_timeout案例

设置CN到DN的socket_timeout为2秒，然后执行一个sleep

CN上抓包分析(stream 5是客户端到CN、stream6是CN到DN）如下，首先CN会计时2秒钟后发送quit给DN，然后断开和DN的连接，并返回一个错误给client，client发送quit断开连接：

image-20220601122556415

CN完整报错堆栈：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
2022-06-01 12:10:00.178 [ServerExecutor-bucket-2-19-thread-181] ERROR com.alibaba.druid.pool.DruidPooledStatement - [user=polardbx_root,host=10.101.32.6,port=43947,schema=bank] CommunicationsException, druid version 1.1.24, jdbcUrl : jdbc:mysql://172.16.40.215:3008/bank_000000?maintainTimeStats=false&rewriteBatchedStatements=false&failOverReadOnly=false&cacheResultSetMetadata=true&allowMultiQueries=true&clobberStreamingResults=true&autoReconnect=false&usePsMemOptimize=true&useServerPrepStmts=true&netTimeoutForStreamingResults=0&useSSL=false&metadataCacheSize=256&readOnlyPropagatesToServer=false&prepStmtCacheSqlLimit=4096&connectTimeout=5000&socketTimeout=9000000&cachePrepStmts=true&characterEncoding=utf8&prepStmtCacheSize=256, testWhileIdle true, idle millis 11861, minIdle 5, poolingCount 4, timeBetweenEvictionRunsMillis 60000, lastValidIdleMillis 11861, driver com.mysql.jdbc.Driver, exceptionSorter com.alibaba.polardbx.common.jdbc.sorter.MySQLExceptionSorter
2022-06-01 12:10:00.179 [ServerExecutor-bucket-2-19-thread-181] ERROR com.alibaba.druid.pool.DruidDataSource - [user=polardbx_root,host=10.101.32.6,port=43947,schema=bank] discard connection
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
	at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3749)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3649)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4090)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2658)
	at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1281)
	at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:782)
	at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1367)
	at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:497)
	at com.alibaba.polardbx.group.jdbc.TGroupDirectPreparedStatement.execute(TGroupDirectPreparedStatement.java:84)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQueryInner(MyJdbcHandler.java:1133)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQuery(MyJdbcHandler.java:990)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.doInit(MyPhyQueryCursor.java:83)
	at com.alibaba.polardbx.executor.cursor.AbstractCursor.init(AbstractCursor.java:53)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.<init>(MyPhyQueryCursor.java:67)
	at com.alibaba.polardbx.repo.mysql.spi.CursorFactoryMyImpl.repoCursor(CursorFactoryMyImpl.java:42)
	at com.alibaba.polardbx.repo.mysql.handler.MyPhyQueryHandler.handle(MyPhyQueryHandler.java:24)
	at com.alibaba.polardbx.executor.handler.HandlerCommon.handlePlan(HandlerCommon.java:102)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.executeInner(AbstractGroupExecutor.java:58)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.execByExecPlanNode(AbstractGroupExecutor.java:36)
	at com.alibaba.polardbx.executor.TopologyExecutor.execByExecPlanNode(TopologyExecutor.java:34)
	at com.alibaba.polardbx.transaction.TransactionExecutor.execByExecPlanNode(TransactionExecutor.java:120)
	at com.alibaba.polardbx.executor.ExecutorHelper.executeByCursor(ExecutorHelper.java:155)
	at com.alibaba.polardbx.executor.ExecutorHelper.execute(ExecutorHelper.java:70)
	at com.alibaba.polardbx.executor.PlanExecutor.execByExecPlanNodeByOne(PlanExecutor.java:130)
	at com.alibaba.polardbx.executor.PlanExecutor.execute(PlanExecutor.java:75)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeQuery(TConnection.java:682)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeSQL(TConnection.java:457)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.executeSQL(TPreparedStatement.java:65)
	at com.alibaba.polardbx.matrix.jdbc.TStatement.executeInternal(TStatement.java:133)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.execute(TPreparedStatement.java:50)
	at com.alibaba.polardbx.server.ServerConnection.innerExecute(ServerConnection.java:1131)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:883)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:850)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:844)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:82)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:31)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeSql(ServerQueryHandler.java:155)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeStatement(ServerQueryHandler.java:133)
	at com.alibaba.polardbx.server.ServerQueryHandler.queryRaw(ServerQueryHandler.java:118)
	at com.alibaba.polardbx.net.FrontendConnection.query(FrontendConnection.java:460)
	at com.alibaba.polardbx.net.handler.FrontendCommandHandler.handle(FrontendCommandHandler.java:49)
	at com.alibaba.polardbx.net.FrontendConnection.lambda$handleData$0(FrontendConnection.java:753)
	at com.alibaba.polardbx.common.utils.thread.RunnableWithCpuCollector.run(RunnableWithCpuCollector.java:36)
	at com.alibaba.polardbx.common.utils.thread.ServerThreadPool$RunnableAdapter.run(ServerThreadPool.java:793)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:874)
	at com.alibaba.wisp.engine.WispTask.runOutsideWisp(WispTask.java:277)
	at com.alibaba.wisp.engine.WispTask.runCommand(WispTask.java:252)
	at com.alibaba.wisp.engine.WispTask.access$100(WispTask.java:33)
	at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
Caused by: java.net.SocketTimeoutException: time out
	at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:244)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 53 common frames omitted
2022-06-01 12:10:00.179 [ServerExecutor-bucket-2-19-thread-181] WARN  com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler - [user=polardbx_root,host=10.101.32.6,port=43947,schema=bank]  [TDDL] [1461cdf8b2809000]Execute ERROR on GROUP: BANK_000000_GROUP, ATOM: dskey_bank_000000_group#pxc-xdb-s-pxcunrcbmk4g9lcpk0f24#172.16.40.215-3008#bank_000000, MERGE_UNION_SIZE:1, SQL: /*DRDS /10.101.32.6/1461cdf8b2809000/0// */SELECT SLEEP(?) AS `sleep(236)`, PARAM: [236], ERROR: Communications link failure, tddl version: 5.4.13-16522656
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
	at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3749)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3649)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4090)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2658)
	at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1281)
	at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:782)
	at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1367)
	at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:497)
	at com.alibaba.polardbx.group.jdbc.TGroupDirectPreparedStatement.execute(TGroupDirectPreparedStatement.java:84)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQueryInner(MyJdbcHandler.java:1133)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQuery(MyJdbcHandler.java:990)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.doInit(MyPhyQueryCursor.java:83)
	at com.alibaba.polardbx.executor.cursor.AbstractCursor.init(AbstractCursor.java:53)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.<init>(MyPhyQueryCursor.java:67)
	at com.alibaba.polardbx.repo.mysql.spi.CursorFactoryMyImpl.repoCursor(CursorFactoryMyImpl.java:42)
	at com.alibaba.polardbx.repo.mysql.handler.MyPhyQueryHandler.handle(MyPhyQueryHandler.java:24)
	at com.alibaba.polardbx.executor.handler.HandlerCommon.handlePlan(HandlerCommon.java:102)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.executeInner(AbstractGroupExecutor.java:58)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.execByExecPlanNode(AbstractGroupExecutor.java:36)
	at com.alibaba.polardbx.executor.TopologyExecutor.execByExecPlanNode(TopologyExecutor.java:34)
	at com.alibaba.polardbx.transaction.TransactionExecutor.execByExecPlanNode(TransactionExecutor.java:120)
	at com.alibaba.polardbx.executor.ExecutorHelper.executeByCursor(ExecutorHelper.java:155)
	at com.alibaba.polardbx.executor.ExecutorHelper.execute(ExecutorHelper.java:70)
	at com.alibaba.polardbx.executor.PlanExecutor.execByExecPlanNodeByOne(PlanExecutor.java:130)
	at com.alibaba.polardbx.executor.PlanExecutor.execute(PlanExecutor.java:75)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeQuery(TConnection.java:682)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeSQL(TConnection.java:457)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.executeSQL(TPreparedStatement.java:65)
	at com.alibaba.polardbx.matrix.jdbc.TStatement.executeInternal(TStatement.java:133)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.execute(TPreparedStatement.java:50)
	at com.alibaba.polardbx.server.ServerConnection.innerExecute(ServerConnection.java:1131)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:883)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:850)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:844)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:82)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:31)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeSql(ServerQueryHandler.java:155)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeStatement(ServerQueryHandler.java:133)
	at com.alibaba.polardbx.server.ServerQueryHandler.queryRaw(ServerQueryHandler.java:118)
	at com.alibaba.polardbx.net.FrontendConnection.query(FrontendConnection.java:460)
	at com.alibaba.polardbx.net.handler.FrontendCommandHandler.handle(FrontendCommandHandler.java:49)
	at com.alibaba.polardbx.net.FrontendConnection.lambda$handleData$0(FrontendConnection.java:753)
	at com.alibaba.polardbx.common.utils.thread.RunnableWithCpuCollector.run(RunnableWithCpuCollector.java:36)
	at com.alibaba.polardbx.common.utils.thread.ServerThreadPool$RunnableAdapter.run(ServerThreadPool.java:793)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:874)
	at com.alibaba.wisp.engine.WispTask.runOutsideWisp(WispTask.java:277)
	at com.alibaba.wisp.engine.WispTask.runCommand(WispTask.java:252)
	at com.alibaba.wisp.engine.WispTask.access$100(WispTask.java:33)
	at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
Caused by: java.net.SocketTimeoutException: time out
	at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:244)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 53 common frames omitted
2022-06-01 12:10:00.179 [ServerExecutor-bucket-2-19-thread-181] WARN  com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler - [user=polardbx_root,host=10.101.32.6,port=43947,schema=bank]  [TDDL] Reset conn socketTimeout failed, lastSocketTimeout is 9000000, tddl version: 5.4.13-16522656
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.Util.getInstance(Util.java:408)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:918)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:897)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:886)
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:860)
	at com.mysql.jdbc.ConnectionImpl.throwConnectionClosedException(ConnectionImpl.java:1326)
	at com.mysql.jdbc.ConnectionImpl.checkClosed(ConnectionImpl.java:1321)
	at com.mysql.jdbc.ConnectionImpl.setNetworkTimeout(ConnectionImpl.java:5888)
	at com.alibaba.polardbx.atom.utils.NetworkUtils.setNetworkTimeout(NetworkUtils.java:18)
	at com.alibaba.polardbx.group.jdbc.TGroupDirectConnection.setNetworkTimeout(TGroupDirectConnection.java:433)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.resetPhyConnSocketTimeout(MyJdbcHandler.java:721)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQueryInner(MyJdbcHandler.java:1173)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQuery(MyJdbcHandler.java:990)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.doInit(MyPhyQueryCursor.java:83)
	at com.alibaba.polardbx.executor.cursor.AbstractCursor.init(AbstractCursor.java:53)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.<init>(MyPhyQueryCursor.java:67)
	at com.alibaba.polardbx.repo.mysql.spi.CursorFactoryMyImpl.repoCursor(CursorFactoryMyImpl.java:42)
	at com.alibaba.polardbx.repo.mysql.handler.MyPhyQueryHandler.handle(MyPhyQueryHandler.java:24)
	at com.alibaba.polardbx.executor.handler.HandlerCommon.handlePlan(HandlerCommon.java:102)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.executeInner(AbstractGroupExecutor.java:58)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.execByExecPlanNode(AbstractGroupExecutor.java:36)
	at com.alibaba.polardbx.executor.TopologyExecutor.execByExecPlanNode(TopologyExecutor.java:34)
	at com.alibaba.polardbx.transaction.TransactionExecutor.execByExecPlanNode(TransactionExecutor.java:120)
	at com.alibaba.polardbx.executor.ExecutorHelper.executeByCursor(ExecutorHelper.java:155)
	at com.alibaba.polardbx.executor.ExecutorHelper.execute(ExecutorHelper.java:70)
	at com.alibaba.polardbx.executor.PlanExecutor.execByExecPlanNodeByOne(PlanExecutor.java:130)
	at com.alibaba.polardbx.executor.PlanExecutor.execute(PlanExecutor.java:75)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeQuery(TConnection.java:682)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeSQL(TConnection.java:457)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.executeSQL(TPreparedStatement.java:65)
	at com.alibaba.polardbx.matrix.jdbc.TStatement.executeInternal(TStatement.java:133)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.execute(TPreparedStatement.java:50)
	at com.alibaba.polardbx.server.ServerConnection.innerExecute(ServerConnection.java:1131)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:883)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:850)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:844)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:82)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:31)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeSql(ServerQueryHandler.java:155)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeStatement(ServerQueryHandler.java:133)
	at com.alibaba.polardbx.server.ServerQueryHandler.queryRaw(ServerQueryHandler.java:118)
	at com.alibaba.polardbx.net.FrontendConnection.query(FrontendConnection.java:460)
	at com.alibaba.polardbx.net.handler.FrontendCommandHandler.handle(FrontendCommandHandler.java:49)
	at com.alibaba.polardbx.net.FrontendConnection.lambda$handleData$0(FrontendConnection.java:753)
	at com.alibaba.polardbx.common.utils.thread.RunnableWithCpuCollector.run(RunnableWithCpuCollector.java:36)
	at com.alibaba.polardbx.common.utils.thread.ServerThreadPool$RunnableAdapter.run(ServerThreadPool.java:793)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:874)
	at com.alibaba.wisp.engine.WispTask.runOutsideWisp(WispTask.java:277)
	at com.alibaba.wisp.engine.WispTask.runCommand(WispTask.java:252)
	at com.alibaba.wisp.engine.WispTask.access$100(WispTask.java:33)
	at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
2022-06-01 12:10:00.179 [ServerExecutor-bucket-2-19-thread-181] WARN  com.alibaba.polardbx.executor.ExecutorHelper - [user=polardbx_root,host=10.101.32.6,port=43947,schema=bank]  [TDDL] PhyQuery(node="BANK_000000_GROUP", sql="SELECT SLEEP(?) AS `sleep(236)`")
, tddl version: 5.4.13-16522656
2022-06-01 12:10:00.180 [ServerExecutor-bucket-2-19-thread-181] WARN  com.alibaba.polardbx.server.ServerConnection - [user=polardbx_root,host=10.101.32.6,port=43947,schema=bank]  [TDDL] [ERROR-CODE: 3009][1461cdf8b2809000] SQL:  /*+TDDL:node(0)  and SOCKET_TIMEOUT=2000 */ select sleep(236), tddl version: 5.4.13-16522656
com.alibaba.polardbx.common.exception.TddlRuntimeException: ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL] Error occurs when execute on GROUP 'BANK_000000_GROUP' ATOM 'dskey_bank_000000_group#pxc-xdb-s-pxcunrcbmk4g9lcpk0f24#172.16.40.215-3008#bank_000000': Communications link failure
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.handleException(MyJdbcHandler.java:1935)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.generalHandlerException(MyJdbcHandler.java:1911)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQueryInner(MyJdbcHandler.java:1168)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQuery(MyJdbcHandler.java:990)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.doInit(MyPhyQueryCursor.java:83)
	at com.alibaba.polardbx.executor.cursor.AbstractCursor.init(AbstractCursor.java:53)
	at com.alibaba.polardbx.repo.mysql.spi.MyPhyQueryCursor.<init>(MyPhyQueryCursor.java:67)
	at com.alibaba.polardbx.repo.mysql.spi.CursorFactoryMyImpl.repoCursor(CursorFactoryMyImpl.java:42)
	at com.alibaba.polardbx.repo.mysql.handler.MyPhyQueryHandler.handle(MyPhyQueryHandler.java:24)
	at com.alibaba.polardbx.executor.handler.HandlerCommon.handlePlan(HandlerCommon.java:102)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.executeInner(AbstractGroupExecutor.java:58)
	at com.alibaba.polardbx.executor.AbstractGroupExecutor.execByExecPlanNode(AbstractGroupExecutor.java:36)
	at com.alibaba.polardbx.executor.TopologyExecutor.execByExecPlanNode(TopologyExecutor.java:34)
	at com.alibaba.polardbx.transaction.TransactionExecutor.execByExecPlanNode(TransactionExecutor.java:120)
	at com.alibaba.polardbx.executor.ExecutorHelper.executeByCursor(ExecutorHelper.java:155)
	at com.alibaba.polardbx.executor.ExecutorHelper.execute(ExecutorHelper.java:70)
	at com.alibaba.polardbx.executor.PlanExecutor.execByExecPlanNodeByOne(PlanExecutor.java:130)
	at com.alibaba.polardbx.executor.PlanExecutor.execute(PlanExecutor.java:75)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeQuery(TConnection.java:682)
	at com.alibaba.polardbx.matrix.jdbc.TConnection.executeSQL(TConnection.java:457)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.executeSQL(TPreparedStatement.java:65)
	at com.alibaba.polardbx.matrix.jdbc.TStatement.executeInternal(TStatement.java:133)
	at com.alibaba.polardbx.matrix.jdbc.TPreparedStatement.execute(TPreparedStatement.java:50)
	at com.alibaba.polardbx.server.ServerConnection.innerExecute(ServerConnection.java:1131)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:883)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:850)
	at com.alibaba.polardbx.server.ServerConnection.execute(ServerConnection.java:844)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:82)
	at com.alibaba.polardbx.server.handler.SelectHandler.handle(SelectHandler.java:31)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeSql(ServerQueryHandler.java:155)
	at com.alibaba.polardbx.server.ServerQueryHandler.executeStatement(ServerQueryHandler.java:133)
	at com.alibaba.polardbx.server.ServerQueryHandler.queryRaw(ServerQueryHandler.java:118)
	at com.alibaba.polardbx.net.FrontendConnection.query(FrontendConnection.java:460)
	at com.alibaba.polardbx.net.handler.FrontendCommandHandler.handle(FrontendCommandHandler.java:49)
	at com.alibaba.polardbx.net.FrontendConnection.lambda$handleData$0(FrontendConnection.java:753)
	at com.alibaba.polardbx.common.utils.thread.RunnableWithCpuCollector.run(RunnableWithCpuCollector.java:36)
	at com.alibaba.polardbx.common.utils.thread.ServerThreadPool$RunnableAdapter.run(ServerThreadPool.java:793)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:874)
	at com.alibaba.wisp.engine.WispTask.runOutsideWisp(WispTask.java:277)
	at com.alibaba.wisp.engine.WispTask.runCommand(WispTask.java:252)
	at com.alibaba.wisp.engine.WispTask.access$100(WispTask.java:33)
	at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
	at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3749)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3649)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4090)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2658)
	at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1281)
	at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:782)
	at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1367)
	at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:497)
	at com.alibaba.polardbx.group.jdbc.TGroupDirectPreparedStatement.execute(TGroupDirectPreparedStatement.java:84)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQueryInner(MyJdbcHandler.java:1133)
	... 44 common frames omitted
Caused by: java.net.SocketTimeoutException: time out
	at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:244)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 53 common frames omitted

应用和 DB 间丢包导致 keepalive 心跳失败

应用使用了 Druid 连接池来维护到 DB 间的所有长连接

应用和 DB 间丢包导致 keepalive 心跳失败，进而 OS会断开这个连接

image-20230322171621838

一个连接归还给Druid连接池都要做清理动作，就是第一个红框的rollback/autocommit=1

归还后OS 层面会探活TCP 连接，DB(4381端口)多次后多次不响应keepalive 后，OS 触发reset tcp断开连接，此时上层应用(比如Druid连接池、比如Tomcat)还不知道此连接在OS 层面已经断开

1
2
3
4
#sysctl -a |grep -i keepalive
net.ipv4.tcp_keepalive_intvl = 3
net.ipv4.tcp_keepalive_probes = 60
net.ipv4.tcp_keepalive_time = 20

继续过来一个新连接，业务取到这个连接执行查询就会报如下错误：

1
2
3
4
5
6
7
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 162,776 milliseconds ago.  The last packet sent successfully to the server was 162,776 milliseconds ago.

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

The last packet successfully received from the server was 162,776 milliseconds ago.  The last packet sent successfully to the server was 162,776 milliseconds ago.

这个错误就是因为OS层面连接断开了，并且断开了162秒(和截图时间戳能对应上)

对应的错误堆栈：

1
2
3
4
5
6
7
8
Caused by: java.net.SocketException: Connection timed out (Write failed)
        at java.net.SocketOutputStream.socketWrite0(Native Method)
        at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
        at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
        at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
        at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
        at com.mysql.jdbc.MysqlIO.send(MysqlIO.java:3725)
        ... 46 common frames omitted

kill 案例

kill mysql client

mysql client连cn执行一个很慢的SQL，然后kill掉mysql client

cn报错：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
2022-06-01 11:45:59.063 [ServerExecutor-bucket-0-17-thread-158] ERROR com.alibaba.druid.pool.DruidPooledStatement - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] CommunicationsException, druid version 1.1.24, jdbcUrl : jdbc:mysql://172.16.40.215:3008/bank_000000?maintainTimeStats=false&rewriteBatchedStatements=false&failOverReadOnly=false&cacheResultSetMetadata=true&allowMultiQueries=true&clobberStreamingResults=true&autoReconnect=false&usePsMemOptimize=true&useServerPrepStmts=true&netTimeoutForStreamingResults=0&useSSL=false&metadataCacheSize=256&readOnlyPropagatesToServer=false&prepStmtCacheSqlLimit=4096&connectTimeout=5000&socketTimeout=9000000&cachePrepStmts=true&characterEncoding=utf8&prepStmtCacheSize=256, testWhileIdle true, idle millis 72028, minIdle 5, poolingCount 4, timeBetweenEvictionRunsMillis 60000, lastValidIdleMillis 345734, driver com.mysql.jdbc.Driver, exceptionSorter com.alibaba.polardbx.common.jdbc.sorter.MySQLExceptionSorter
2022-06-01 11:45:59.064 [ServerExecutor-bucket-0-17-thread-158] ERROR com.alibaba.druid.pool.DruidDataSource - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank] discard connection
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
	at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	…………
	at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
Caused by: java.net.SocketException: Socket is closed
	at java.net.Socket.getSoTimeout(Socket.java:1291)
	at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:249)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 53 common frames omitted
2022-06-01 11:45:59.065 [ServerExecutor-bucket-0-17-thread-158] WARN  com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank]  [TDDL] [1461c86bbe809001]Execute ERROR on GROUP: BANK_000000_GROUP, ATOM: dskey_bank_000000_group#pxc-xdb-s-pxcunrcbmk4g9lcpk0f24#172.16.40.215-3008#bank_000000, MERGE_UNION_SIZE:1, SQL: /*DRDS /10.101.32.6/1461c86bbe809001/0// */SELECT SLEEP(?) AS `sleep(236)`, PARAM: [236], ERROR: Communications link failure, tddl version: 5.4.13-16522656
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
	at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
…………
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
Caused by: java.net.SocketException: Socket is closed
	at java.net.Socket.getSoTimeout(Socket.java:1291)
	at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:249)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 53 common frames omitted
2022-06-01 11:45:59.065 [ServerExecutor-bucket-0-17-thread-158] WARN  com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank]  [TDDL] Reset conn socketTimeout failed, lastSocketTimeout is 9000000, tddl version: 5.4.13-16522656
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed.
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:80)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
…………
	at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
2022-06-01 11:45:59.065 [ServerExecutor-bucket-0-17-thread-158] WARN  com.alibaba.polardbx.executor.ExecutorHelper - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank]  [TDDL] PhyQuery(node="BANK_000000_GROUP", sql="SELECT SLEEP(?) AS `sleep(236)`")
, tddl version: 5.4.13-16522656
2022-06-01 11:45:59.066 [ServerExecutor-bucket-0-17-thread-158] ERROR com.alibaba.polardbx.server.ServerConnection - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank]  [TDDL] Interrupted unexpectedly for 1461c86bbe809001, tddl version: 5.4.13-16522656
java.lang.InterruptedException: null
	at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1310)
	at com.alibaba.polardbx.common.utils.BooleanMutex$Sync.innerGet(BooleanMutex.java:136)
	at com.alibaba.polardbx.common.utils.BooleanMutex.get(BooleanMutex.java:53)
	at com.alibaba.polardbx.common.utils.thread.ServerThreadPool.waitByTraceId(ServerThreadPool.java:445)
	at com.alibaba.polardbx.server.ServerConnection.innerExecute(ServerConnection.java:1291)
	……
	at com.alibaba.wisp.engine.WispTask.access$100(WispTask.java:33)
	at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
2022-06-01 11:45:59.066 [ServerExecutor-bucket-0-17-thread-158] WARN  com.alibaba.polardbx.server.ServerConnection - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank]  [TDDL] [ERROR-CODE: 3009][1461c86bbe809001] SQL:  /*+TDDL:node(0)  and SOCKET_TIMEOUT=40000 */ select sleep(236), tddl version: 5.4.13-16522656
com.alibaba.polardbx.common.exception.TddlRuntimeException: ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL] Error occurs when execute on GROUP 'BANK_000000_GROUP' ATOM 'dskey_bank_000000_group#pxc-xdb-s-pxcunrcbmk4g9lcpk0f24#172.16.40.215-3008#bank_000000': Communications link failure
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.handleException(MyJdbcHandler.java:1935)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.generalHandlerException(MyJdbcHandler.java:1911)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQueryInner(MyJdbcHandler.java:1168)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQuery(MyJdbcHandler.java:990)
	…………
		at com.alibaba.wisp.engine.WispTask$CacheableCoroutine.run(WispTask.java:223)
	at java.dyn.CoroutineBase.startInternal(CoroutineBase.java:60)
Caused by: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
	at sun.reflect.GeneratedConstructorAccessor72.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:425)
	at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:989)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3749)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3649)
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4090)
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2658)
	at com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1281)
	at com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:782)
	at com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1367)
	at com.alibaba.druid.pool.DruidPooledPreparedStatement.execute(DruidPooledPreparedStatement.java:497)
	at com.alibaba.polardbx.group.jdbc.TGroupDirectPreparedStatement.execute(TGroupDirectPreparedStatement.java:84)
	at com.alibaba.polardbx.repo.mysql.spi.MyJdbcHandler.executeQueryInner(MyJdbcHandler.java:1133)
	... 44 common frames omitted
Caused by: java.net.SocketException: Socket is closed
	at java.net.Socket.getSoTimeout(Socket.java:1291)
	at sun.nio.ch.WispSocketImpl$1$1.read0(WispSocketImpl.java:249)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:208)
	at sun.nio.ch.WispSocketImpl$1$1.read(WispSocketImpl.java:201)
	at com.mysql.jdbc.util.ReadAheadInputStream.fill(ReadAheadInputStream.java:101)
	at com.mysql.jdbc.util.ReadAheadInputStream.readFromUnderlyingStreamIfNecessary(ReadAheadInputStream.java:144)
	at com.mysql.jdbc.util.ReadAheadInputStream.read(ReadAheadInputStream.java:174)
	at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3183)
	at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3659)
	... 53 common frames omitted
2022-06-01 11:45:59.071 [KillExecutor-15-thread-49] WARN  com.alibaba.polardbx.server.ServerConnection - [user=polardbx_root,host=10.101.32.6,port=50684,schema=bank]  [TDDL] Connection Killed, tddl version: 5.4.13-16522656

mysqld报错：

1
2022-06-01T11:45:58.915371+08:00 8218735 [Note] Aborted connection 8218735 to db: 'bank_000000' user: 'rds_polardb_x' host: '172.16.40.214' (Got an error reading communication packets)

172.16.40.214是客户端IP

抓包看到CN收到mysql client发过来的fin，CN回复fin断开连接

CN会给DN在新的连接上发Kill Query（stream 1596），同时会在原来的连接(stream 583)上发fin，然后原来的连接收到DN的response（被kill），然后CN发reset给DN

image-20220601120626629

下图是sleep 连接的收发包

image-20220601120417026

Kill jdbc client

Java jdbc client被kill后没有错误堆栈，kill后触发socket.close(对应client发送fin断开连接），kill后server端SQL也被立即中断

抓包：

image-20220601143200253

server端报错信息：

1
2022-06-01T14:33:52.204848+08:00 8288839 [Note] Aborted connection 8288839 to db: 'bank_000000' user: 'user' host: '172.16.40.214' (Got an error reading communication packets)

Statement timeout

1
2
3
4
# java -cp /home/admin/drds-server/lib/*:. Test "jdbc:mysql://172.16.40.215:3008/bank_000000?socketTimeout=5459" "user" "pass" "select sleep(180)" "1" 3
com.mysql.jdbc.exceptions.MySQLTimeoutException: Statement cancelled due to timeout or client request
	at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1419)
	at Test.main(Test.java:31)

statement会设置一个timer，到时间还没有返回结果就创建一个新连接发送kill query

server 端收到kill后终止SQL执行，抓包看到Server端主动提前返回了错误

image-20220601152401387

参考资料

MySQL JDBC StreamResult通信原理浅析

TCP

如何创建一个自己连自己的TCP连接

如何创建一个自己连自己的TCP连接

能不能建立一个tcp连接， src-ip:src-port 等于dest-ip:dest-port 呢？

最近有同时找我，说是发现了一个奇怪的问题，他的 MySQLD listen 28350 端口， Sysbench 和 MySQLD 部署在同一台机器上，然后压 MySQL，只要 MySQL 一挂掉就再也起不来，起不来是因为 28350 端口被 Sysbench 抢走了，如下图，对 Sysbench 来说他已经连上 28350 的 MySQL 了（注意 ESTABLISHED 状态）：

img

所以问题就是能不能建立一个自己连自己的连接呢？建立后有什么现象和后果？

测试

执行

1
# nc 192.168.0.79 18082 -p 18082

然后就能看到

1
2
# netstat -ant |grep 18082
tcp        0      0 192.168.0.79:18082      192.168.0.79:18082      ESTABLISHED

比较神奇，这个连接的srcport等于destport，并且完全可以工作，也能收发数据。这有点颠覆大家的理解，端口能重复使用？

port range

我们都知道linux下本地端口范围由参数控制

1
2
# cat /proc/sys/net/ipv4/ip_local_port_range 
10000	65535

所以也经常看到一个误解：一台机器上最多能创建65535个TCP连接

到底一台机器上最多能创建多少个TCP连接

在内存、文件句柄足够的话可以创建的连接是没有限制的，那么/proc/sys/net/ipv4/ip_local_port_range指定的端口范围到底是什么意思呢？

一个TCP连接只要保证四元组(src-ip src-port dest-ip dest-port)唯一就可以了，而不是要求src port唯一，比如：

1
2
3
4
5
6
# netstat -ant |grep 18089
tcp        0      0 192.168.1.79:18089      192.168.1.79:22         ESTABLISHED
tcp        0      0 192.168.1.79:18089      192.168.1.79:18080      ESTABLISHED
tcp        0      0 192.168.0.79:18089      192.168.0.79:22         TIME_WAIT 
tcp        0      0 192.168.1.79:22         192.168.1.79:18089      ESTABLISHED
tcp        0      0 192.168.1.79:18080      192.168.1.79:18089      ESTABLISHED

从前三行可以清楚地看到18089被用了三次，第一第二行src-ip、dest-ip也是重复的，但是dest port不一样，第三行的src-port还是18089，但是src-ip变了。

所以一台机器能创建的TCP连接是没有限制的，而ip_local_port_range是指没有bind的时候OS随机分配端口的范围，但是分配到的端口要同时满足五元组唯一，这样 ip_local_port_range 限制的是连同一个目标（dest-ip和dest-port一样）的port的数量（请忽略本地多网卡的情况，因为dest-ip为以后route只会选用一个本地ip）。

但是如果程序调用的是bind函数(bind(ip,port=0))这个时候是让系统绑定到某个网卡和自动分配的端口，此时系统没有办法确定接下来这个socket是要去connect还是listen. 如果是listen的话，那么肯定是不能出现端口冲突的，如果是connect的话，只要满足4元组唯一即可。在这种情况下，系统只能尽可能满足更强的要求，就是先要求端口不能冲突，即使之后去connect的时候4元组是唯一的。

bind()的时候内核是还不知道四元组的，只知道src_ip、src_port，所以这个时候单网卡下src_port是没法重复的，但是connect()的时候已经知道了四元组的全部信息，所以只要保证四元组唯一就可以了，那么这里的src_port完全是可以重复使用的。

自己连自己的连接

我们来看自己连自己发生了什么

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# strace nc 192.168.0.79 18084 -p 18084
execve("/usr/bin/nc", ["nc", "192.168.0.79", "18084", "-p", "18084"], [/* 31 vars */]) = 0
brk(NULL)                               = 0x23d4000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f213f394000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=23295, ...}) = 0
mmap(NULL, 23295, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f213f38e000
close(3)                                = 0
open("/lib64/libssl.so.10", O_RDONLY|O_CLOEXEC) = 3
………………
munmap(0x7f213f393000, 4096)            = 0
open("/usr/share/ncat/ca-bundle.crt", O_RDONLY) = -1 ENOENT (No such file or directory)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(18084), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
//注意这里bind后直接就是connect，没有listen
connect(3, {sa_family=AF_INET, sin_port=htons(18084), sin_addr=inet_addr("192.168.0.79")}, 16) = -1 EINPROGRESS (Operation now in progress)
select(4, [3], [3], [3], {10, 0})       = 1 (out [3], left {9, 999998})
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
select(4, [0 3], [], [], NULL

抓包看看，正常三次握手，但是syn的seq和syn+ack的seq是一样的

image.png

这个连接算是常说的TCP simultaneous open，simultaneous open指的是两个不同port同时发syn建连接。而这里是先创建了一个socket，然后socket bind到18084端口上（作为local port，因为nc指定了local port），然后执行 connect, 连接到的目标也是192.168.0.79:18084，而这个目标正好是刚刚创建的socket，也就是自己连自己（连接双方总共只有一个socket）。因为一个socket充当了两个角色（client、server），握手的时候发syn，自己收到自己发的syn，就相当于两个角色simultaneous open了。

正常一个连接一定需要两个socket参与（这两个socket不一定要在两台机器上），而这个连接只用了一个socket就创建了，还能正常传输数据。但是仔细观察发数据的时候发放的seq增加（注意tcp_len 11那里的seq），收方的seq也增加了11，这是因为本来这就是用的同一个socket。正常两个socket通讯不是这样的。

那么这种情况为什么没有当做bug被处理呢？

TCP simultanous open

在tcp连接的定义中，通常都是一方先发起连接，假如两边同时发起连接，也就是两个socket同时给对方发 syn 呢？ 这在内核中是支持的，就叫同时打开（simultaneous open）。

image.png

​ 摘自《tcp/ip卷1》

可以清楚地看到这个连接建立用了四次握手，然后连接建立了，当然也有 simultanous close(3次挥手成功关闭连接)。如下内核代码 net/ipv4/tcp_input.c 的5924行中就说明了允许这种自己连自己的连接（当然也允许simultanous open). 也就是允许一个socket本来应该收到 syn+ack(发出syn后), 结果收到了syn的情况，而一个socket自己连自己又是这种情况的特例。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
	static int tcp_rcv_synsent_state_process(struct sock *sk, struct sk_buff *skb,
                     const struct tcphdr *th)
	{
5916         /* PAWS check. */
						 //PAWS机制全称Protect Againest Wrapped Sequence numbers，
						 //目的是为了解决在高带宽下，TCP序号可能被重复使用而带来的问题。
5917         if (tp->rx_opt.ts_recent_stamp && tp->rx_opt.saw_tstamp &&
5918             tcp_paws_reject(&tp->rx_opt, 0))
5919                 goto discard_and_undo;
5920         //在socket发送syn后收到了一个syn(正常应该收到syn+ack),这里是允许的。
5921         if (th->syn) {
5922                 /* We see SYN without ACK. It is attempt of
5923                  * simultaneous connect with crossed SYNs.
5924                  * Particularly, it can be connect to self.  //自己连自己
5925                  */
5926                 tcp_set_state(sk, TCP_SYN_RECV);
5927 
5928                 if (tp->rx_opt.saw_tstamp) {
5929                         tp->rx_opt.tstamp_ok = 1;
5930                         tcp_store_ts_recent(tp);
5931                         tp->tcp_header_len =
5932                                 sizeof(struct tcphdr) + TCPOLEN_TSTAMP_ALIGNED;
5933                 } else {
5934                         tp->tcp_header_len = sizeof(struct tcphdr);
5935                 }
5936 
5937                 tp->rcv_nxt = TCP_SKB_CB(skb)->seq + 1;
5938                 tp->copied_seq = tp->rcv_nxt;
5939                 tp->rcv_wup = TCP_SKB_CB(skb)->seq + 1;
5940 
5941                 /* RFC1323: The window in SYN & SYN/ACK segments is
5942                  * never scaled.
5943                  */

也就是在发送syn进入SYN_SENT状态之后，收到对端发来的syn包后不会RST，而是处理流程如下，调用tcp_set_state(sk, TCP_SYN_RECV)进入SYN_RECV状态，以及调用tcp_send_synack(sk)向对端发送syn+ack。

自己连自己的原理解释

第一我们要理解Kernel是支持simultaneous open（同时打开）的，也就是说socket发走syn后，本来应该收到一个syn+ack的，但是实际收到了一个syn（没有ack），这是允许的。这叫TCP连接同时打开（同时给对方发syn），四次握手然后建立连接成功。

自己连自己又是simultaneous open的一个特例，特别在这个连接只有一个socket参与，发送、接收都是同一个socket，自然也会是发syn后收到了自己的syn（自己发给自己），然后依照simultaneous open连接也能创建成功。

这个bind到18084 local port的socket又要连接到 18084 port上，而这个18084 socket已经bind到了socket（也就是自己），就形成了两个socket 的simultaneous open一样，内核又允许这种simultaneous open，所以就形成了自己连自己，也就是一个socket在自己给自己收发数据，所以看到收方和发放的seq是一样的。

可以用python来重现这个连接连自己的过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import socket
import time

connected=False
while (not connected):
        try:
          sock = socket.socket(socket.AF_INET,socket.SOCK_STREAM)
          sock.setsockopt(socket.IPPROTO_TCP,socket.TCP_NODELAY,1)
          sock.bind(('', 18084))               //sock 先bind到18084
          sock.connect(('127.0.0.1',18084))    //然后同一个socket连自己
          connected=True
        except socket.error,(value,message):
        	print message

        if not connected:
        	print "reconnect"
               
print "tcp self connection occurs!"
print "netstat -an|grep 18084"
time.sleep(1800)

这里connect前如果没有bind那么系统就会从 local port range 分配一个可用port。

bind成功后会将ip+port放入hash表来判重，这就是我们常看到的 Bind to *** failed (IOD #1): Address already in use 异常。所以一台机器上，如果有多个ip，是可以将同一个port bind多次的，但是bind的时候如果不指定ip，也就是bind(‘0’, port) 还是会冲突。

connect成功后会将四元组放入ehash来判定连接的重复性。如果connect四元组冲突了就会报如下错误

1
2
# nc 192.168.0.82 8080 -p 29798 -s 192.168.0.79
Ncat: Cannot assign requested address.

问题解决

知道原因就好解决了，有如下两个方案

  1. 正常应该通过 port_range 限制随机端口的使用范围(就是给 Sysbench 这些客户端使用的)，而 Listen 使用的端口在 port_range 之外，这样就不会出现自己连自己的连接了
  2. 将 listen 端口添加到 /proc/sys/net/ipv4/ip_local_reserved_ports 中

方案2示例(推荐该方案)如下：

1
2
3
4
# echo 3306,32768,1024-3000,32769-65535 >/proc/sys/net/ipv4/ip_local_reserved_ports
//合并连续的区间
# cat /proc/sys/net/ipv4/ip_local_reserved_ports
1024-3000,3306,32768-65535

以上两个方法都可以解决这个问题，方案2 简直是为这种情况量身打造的

bind 和 connect、listen

当对一个TCP socket调用connect函数时，如果这个socket没有bind指定的端口号，操作系统会为它选择一个当前未被使用的端口号，这个端口号被称为ephemeral port, 范围可以在/proc/sys/net/ipv4/ip_local_port_range里查看。假设30000这个端口被选为ephemeral port。

如果这个socket指定了local port那么socket创建后会执行bind将这个socket bind到这个port。比如：

1
2
3
4
5
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(18084), sin_addr=inet_addr("0.0.0.0")}, 16) = 0

image.png

listen

image-20200702131215819

参考资料

https://segmentfault.com/a/1190000002396411

linux中TCP的socket、bind、listen、connect和accept的实现

How Linux allows TCP introspection The inner workings of bind and listen on Linux.

https://idea.popcount.org/2014-04-03-bind-before-connect/

network

程序员如何学习和构建网络知识体系

程序员如何学习和构建网络知识体系

大家学习网络知识的过程中经常发现当时看懂了，很快又忘了，最典型的比如TCP三次握手、为什么要握手，大家基本都看过，但是种感觉还差那么一点点。都要看是因为面试官总要问，所以不能不知道啊。

我们来看一个典型的面试问题：

问：为什么TCP是可靠的？
答：因为TCP有连接（或者回答因为TCP有握手）

追问：为什么有连接就可靠了？（面试的人估计心里在骂，你这不是傻逼么，有连接就可靠啊）

追问：这个TCP连接的本质是什么？网络上给你保留了一个带宽所以能可靠？
答：……懵了（或者因为TCP有ack，所以可靠）

追问：握手的本质是什么？为什么握手就可靠了
答：因为握手需要ack
追问：那这个ack也只是保证握手可靠，握手是怎么保证后面可靠的？握手本质做了什么事情？

追问：有了ack可靠后还会带来什么问题（比如发一个包ack一下，肯定是可行的，但是效率不行，面试官想知道的是这里TCP怎么传输的，从而引出各个buffer、拥塞窗口的概念）

基本上我发现99%的程序员会回答TCP相对UDP是可靠的，70%以上的程序员会告诉你可靠是因为有ack（其他的会告诉你可靠是因为握手或者有连接），再追问下次就开始王顾左右而言他、胡言乱语。

我的理解：

物理上没有一个连接的东西在这里，udp也类似会占用端口、ip，但是大家都没说过udp的连接。而本质上我们说tcp的握手是指tcp是协商和维护一些状态信息的，这个状态信息就包含seq、ack、窗口/buffer，tcp握手就是协商出来这些初始值。这些状态才是我们平时所说的tcp连接的本质。

这说明大部分程序员对问题的本质的理解上出了问题，或者教科书描述的过于教条不够接地气所以看完书本质没get到。

想想 费曼学习方法 中对事物本质的理解的重要性。

## 重点掌握如下两篇文章

一个网络包是如何到达目的地的 – 这篇可以帮你掌握网络如何运转，在本机上从端口、ip、mac地址如何一层层封上去，链路上每一个点拆开mac看看，拆看ip看看，然后替换mac地址继续扔到链路的下一跳，这样一跳跳到达目的。

对BDP、Buffer、各种窗口、rt的理解和运用 这一篇可以让你入门TCP

以上两篇都是站在程序员的角度来剖析关于网络我们应该掌握哪些，也许第一篇有点像网工要掌握的，实际我不这么认为，目前很流行的微服务化、云原生对网络的要求更高了，大多时候需要程序员去掌握这些，也就是在网络包从你的网卡离开你才有资格呼叫网工，否则成本很高！

我本周还碰到了网络不通的问题

我的测试机器不能连外网(公司安全策略)

走流程申请开通，开通后会在测试机器安装客户端以及安全配置文件

但仍然不通，客户端自检都能通

我的排查就是第一篇文章：ping 公网ip；ip route get 公网-ip；ping 网关；

很快就发现是路由的问题，公网ip正好命中了docker 容器添加的某个路由，以及默认路由缺失

如果我自己不会那就开工单、描述问题、call各种人、申请权限……

我碰到的程序员一看到网络连接异常就吓尿了，不关我的事，网络不通，但是在call人前你至少可以做：

  1. ping ip 通不通(也有个别禁掉了icmp)
  2. telnet ip port通不通
  3. 网络包发出去没有(抓包)
  4. 是不是都不通还是只有你的机器不通

来看一个案例

我第一次看RFC1180的时候是震惊的，觉得讲述的太好了，2000字就把一本教科书的知识阐述的无比清晰、透彻。但是实际上我发现很快就忘了，而且大部分程序员基本都是这样

RFC1180写的确实很好，清晰简洁，图文并茂，结构逻辑合理，但是对于95%的程序员没有什么用，当时看的时候很爽、也觉得自己理解了、学会了，实际上看完几周后就忘得差不多了。问题出在这种RFC偏理论多一点看起来完全没有体感无法感同身受，所以即使似乎当时看懂了，但是忘得也快，需要一篇结合实践的文章来帮助理解

在这个问题上，让我深刻地理解到：

一流的人看RFC就够了，差一些的人看《TCP/IP卷1》，再差些的人要看一个个案例带出来的具体知识的书籍了，比如《wireshark抓包艺术》，人和人的学习能力有差别必须要承认。

也就是我们要认识到每个个人的学习能力的差异，我超级认同这篇文章中的一个评论

看完深有感触，尤其是后面的知识效率和工程效率型的区别。以前总是很中二的觉得自己看一遍就理解记住了，结果一次次失败又怀疑自己的智商是不是有问题，其实就是把自己当作知识效率型来用了。一个不太恰当的形容就是，有颗公主心却没公主命！

嗯，大部分时候我们都觉得自己看一遍就理解了记住了能实用解决问题了，实际上了是马上忘了，停下来想想自己是不是这样的？在网络的相关知识上大部分看RFC、TCP卷1等东西是很难实际理解的，还是要靠实践来建立对知识的具体的理解，而网络相关的东西基本离大家有点远（大家不回去读tcp、ip源码，纯粹是靠对书本的理解），所以很难建立具体的概念，所以这里有个必杀技就是学会抓包和用wireshark看包，同时针对实际碰到的文题来抓包、看包分析。

比如这篇《从计算机知识到落地能力，你欠缺了什么？》就对上述问题最好的阐述，程序员最常碰到的网络问题就是网络为啥不通？

这是最好建立对网络知识具体理解和实践的机会，你把《从计算机知识到落地能力，你欠缺了什么？》实践完再去看RFC1180 就明白了。通过案例把RFC1180抽象的描述给它具体化、场景化了，理解起来就很轻松不容易忘记了。

经验一: 通过具体的东西(案例、抓包)来建立对网络基础的理解

image-20220221151815993

不要追求知识的广度

学习网络知识过程中，不建议每个知识点都去看，因为很快会忘记，我的方法是只看经常碰到的问题点，碰到一个点把他学透理解明白。

比如我曾经碰到过 nslookup OK but ping fail–看看老司机是如何解决问题的，解决问题的方法肯定比知识点重要多了，同时透过一个问题怎么样通篇来理解一大块知识，让这块原理真正在你的知识体系中扎根下来 , 这个问题Google上很多人在搜索，说明很普遍，但是没找到有资料能把这个问题说清楚，所以借着这个机会就把 Linux下的 NSS（name service switch）的原理搞懂了。要不然碰到问题老司机告诉你改下 /etc/hosts 或者 /etc/nsswitch 或者 /etc/resolv.conf 之类的问题就能解决，但是你一直不知道这三个文件怎么起作用的，也就是你碰到过这种问题也解决过但是下次碰到类似的问题你不一定能解决。

当然对我来说为了解决这个问题最后写了4篇跟域名解析相关的文章，从windows到linux，涉及到vpn、glibc、docker等各种场景，我把他叫做场景驱动。后来换来工作环境从windows换到mac后又补了一篇mac下的路由、dns文章。

关于场景驱动学习的方法可以看这篇总结

TCP是最复杂的，要从实用出发

比如拥塞算法基本大家不会用到，了解下就行，你想想你有碰到过因为拥塞算法导致的问题吗？极少是吧。还有拥塞窗口、慢启动，这个实际中碰到的概率不高，面试要问你基本上是属于炫技类型。

实际碰到更多的是传输效率（对BDP、Buffer、各种窗口、rt的理解和运用），还有为什么连不通、连接建立不起来、为什么收到包不回复、为什么要reset、为什么丢包了之类的问题。

关于为什么连不通，我碰到了这个问题，随后在这个问题的基础上进行了总结，得到客户端建连接的时候抛异常，可能的原因（握手失败，建不上连接）：

  • 网络不通，诊断：ping ip
  • 端口不通, 诊断：telnet ip port
  • rp_filter 命中(rp_filter=1, 多网卡环境）， 诊断: netstat -s | grep -i filter
  • 防火墙、命中iptables 被扔掉了，可以试试22端口起sshd 能否正常访问，能的话说明是端口被干了
  • snat/dnat的时候宿主机port冲突，内核会扔掉 syn包。诊断: sudo conntrack -S | grep insert_failed //有不为0的
  • Firewalld 或者 iptables
  • 全连接队列满的情况，诊断： netstat -s | egrep “listen|LISTEN”
  • syn flood攻击, 诊断：同上
  • 服务端的内核参数 net.ipv4.tcp_tw_recycle(4.12内核删除这个参数了) 和 net.ipv4.tcp_timestamps 的值都为 1时，服务器会检查每一个 SYN报文中的时间戳（Timestamp，跟同一ip下最近一次 FIN包时间对比），若 Timestamp 不是递增的关系，就扔掉这个SYN包（诊断：netstat -s | grep “ passive connections rejected because of time stamp”），常见触发时间戳非递增场景：
    1. 4.10 内核，一直必现大概率性丢包。4.11 改成了 per-destination host的算法
    2. tcpping 这种时间戳按连接随机的，必现大概率持续丢包
    3. 同一个客户端通过直连或者 DNAT 后两条链路到同一个服务端，客户端生成时间戳是 by dst ip，导致大概率持续丢包
    4. 经过NAT/LVS 后多个客户端被当成一个客户端，小概率偶尔出现
    5. 网路链路复杂/链路长容易导致包乱序，进而出发丢包，取决于网络会小概率出现——通过 tc qdisc 可以来构造丢包重现该场景
    6. 客户端修改 net.ipv4.tcp_timestamps
      • 1->0，触发持续60秒大概率必现的丢包，60秒后恢复
      • 0->1 持续大概率一直丢包60秒; 60秒过后如果网络延时略高且客户端并发大一直有上一次 FIN 时间戳大于后续SYN 会一直概率性丢包持续下去；如果停掉所有流量，重启客户端流量，恢复正常
      • 2->1 丢包，情况同2
      • 1->2 不触发丢包
  • 若服务器所用端口是 time_wait 状态，这时新连接刚好和 time_wait 5元组重复，一般服务器不会回复syn+ack 而是回复time_wait 前的ack
  • NAT 哈希表满导致 ECS 实例丢包 nf_conntrack full， 诊断: dmesg |grep conntrack

为什么 drop SYN 包时不去看四元组？因为tiem_wait 状态是 per-host

0->1 60秒后仍然持续丢包：

image-20240803095126448

2->1 60秒后持续丢包：(非常神奇：在310客户端改不影响自己，导致510客户端（网络延时大）一直丢包，直到510 客户端重启流量才能恢复)

image-20240803093817441

tcp_reuse 参数只对客户端有效(客户端是指主动发起 fin 的一方)，启用后会回收超过 1 秒的 time_wait 状态端口重复使用：参考：https://ata.atatech.org/articles/11020082442

如果服务端是Time_wait 状态时收到 SYN 包怎么办？

https://developer.aliyun.com/article/1262180

tcp connect 的流程是这样的：

1、tcp发出SYN建链报文后，报文到ip层需要进行路由查询

2、路由查询完成后，报文到arp层查询下一跳mac地址

3、如果本地没有对应网关的arp缓存，就需要缓存住这个报文，发起arp请求

4、arp层收到arp回应报文之后，从缓存中取出SYN报文，完成mac头填写并发送给驱动。

问题在于，arp层报文缓存队列长度默认为3。如果你运气不好，刚好赶上缓存已满，这个报文就会被丢弃。

TCP层发现SYN报文发出去3s（1s+2s）还没有回应，就会重发一个SYN。这就是为什么少数连接会3s后才能建链。

幸运的是，arp层缓存队列长度是可配置的，用 sysctl -a | grep unres_qlen 就能看到，默认值为3

Time_Wait

socket.close 默认是四次挥手，但如果tw bucket 满了就直接走 reset，比如很多机器设置的是 5000 net.ipv4.tcp_max_tw_buckets = 5000

bucket 溢出对应的监控指标：TCPTimeWaitOverflow

1
2
3
4
5
6
7
#netstat -s | grep -i overflow
    439 times the listen queue of a socket overflowed
    TCPTimeWaitOverflow: 377310115

#netstat -s | grep -i overflow
    439 times the listen queue of a socket overflowed
    TCPTimeWaitOverflow: 377314175

总结

  • 一定要会用tcpdump和wireshark（纯工具，没有任何门槛，用不好只有一个原因: 懒）
  • 多实践（因为网络知识离我们有点远、有点抽象）,用好各种工具，工具能帮我们看到、摸到
  • 不要追求知识面的广度，深抠几个具体的知识点然后让这些点建立体系
  • 不要为那些基本用不到的偏门知识花太多精力，天天用的都学不过来对吧。

参考资料

per-connection random offset：https://lwn.net/Articles/708021/

TCP

就是要你懂TCP--半连接队列和全连接队列

关于TCP 半连接队列和全连接队列

最近碰到一个client端连接服务器总是抛异常的问题，然后定位分析并查阅各种资料文章，对TCP连接队列有个深入的理解

查资料过程中发现没有文章把这两个队列以及怎么观察他们的指标说清楚，希望通过这篇文章能把他们说清楚

问题描述

场景：JAVA的client和server，使用socket通信。server使用NIO。

1.间歇性的出现client向server建立连接三次握手已经完成，但server的selector没有响应到这连接。
2.出问题的时间点，会同时有很多连接出现这个问题。
3.selector没有销毁重建，一直用的都是一个。
4.程序刚启动的时候必会出现一些，之后会间歇性出现。

分析问题

正常TCP建连接三次握手过程：

image.png

  • 第一步：client 发送 syn 到server 发起握手；
  • 第二步：server 收到 syn后回复syn+ack给client；
  • 第三步：client 收到syn+ack后，回复server一个ack表示收到了server的syn+ack（此时client的56911端口的连接已经是established）

从问题的描述来看，有点像TCP建连接的时候全连接队列（accept队列，后面具体讲）满了，尤其是症状2、4. 为了证明是这个原因，马上通过 netstat -s | egrep “listen” 去看队列的溢出统计数据：

667399 times the listen queue of a socket overflowed

反复看了几次之后发现这个overflowed 一直在增加，那么可以明确的是server上全连接队列一定溢出了

接着查看溢出后，OS怎么处理：

# cat /proc/sys/net/ipv4/tcp_abort_on_overflow
0

tcp_abort_on_overflow 为0表示如果三次握手第三步的时候全连接队列满了那么server扔掉client 发过来的ack（在server端认为连接还没建立起来）

为了证明客户端应用代码的异常跟全连接队列满有关系，我先把tcp_abort_on_overflow修改成 1，1表示第三步的时候如果全连接队列满了，server发送一个reset包给client，表示废掉这个握手过程和这个连接（本来在server端这个连接就还没建立起来）。

接着测试，这时在客户端异常中可以看到很多connection reset by peer的错误，到此证明客户端错误是这个原因导致的（逻辑严谨、快速证明问题的关键点所在）。

于是开发同学翻看java 源代码发现socket 默认的backlog（这个值控制全连接队列的大小，后面再详述）是50，于是改大重新跑，经过12个小时以上的压测，这个错误一次都没出现了，同时观察到 overflowed 也不再增加了。

到此问题解决，简单来说TCP三次握手后有个accept队列，进到这个队列才能从Listen变成accept，默认backlog 值是50，很容易就满了。满了之后握手第三步的时候server就忽略了client发过来的ack包（隔一段时间server重发握手第二步的syn+ack包给client），如果这个连接一直排不上队就异常了。

但是不能只是满足问题的解决，而是要去复盘解决过程，中间涉及到了哪些知识点是我所缺失或者理解不到位的；这个问题除了上面的异常信息表现出来之外，还有没有更明确地指征来查看和确认这个问题。

深入理解TCP握手过程中建连接的流程和队列

image.png
（图片来源：http://www.cnxct.com/something-about-phpfpm-s-backlog/）

如上图所示，这里有两个队列：syns queue(半连接队列）；accept queue（全连接队列）

三次握手中，在第一步server收到client的syn后，把这个连接信息放到半连接队列中，同时回复syn+ack给client（第二步）；

题外话，比如syn floods 攻击就是针对半连接队列的，攻击方不停地建连接，但是建连接的时候只做第一步，第二步中攻击方收到server的syn+ack后故意扔掉什么也不做，导致server上这个队列满其它正常请求无法进来

第三步的时候server收到client的ack，如果这时全连接队列没满，那么从半连接队列拿出这个连接的信息放入到全连接队列中，否则按tcp_abort_on_overflow指示的执行。

这时如果全连接队列满了并且tcp_abort_on_overflow是0的话，server过一段时间再次发送syn+ack给client（也就是重新走握手的第二步），如果client超时等待比较短，client就很容易异常了。

在我们的os中retry 第二步的默认次数是2（centos默认是5次）：

net.ipv4.tcp_synack_retries = 2

如果TCP连接队列溢出，有哪些指标可以看呢？

上述解决过程有点绕，听起来蒙逼，那么下次再出现类似问题有什么更快更明确的手段来确认这个问题呢？

（通过具体的、感性的东西来强化我们对知识点的理解和吸收）

netstat -s

[root@server ~]#  netstat -s | egrep "listen|LISTEN" 
667399 times the listen queue of a socket overflowed
667399 SYNs to LISTEN sockets ignored

比如上面看到的 667399 times ，表示全连接队列溢出的次数，隔几秒钟执行下，如果这个数字一直在增加的话肯定全连接队列偶尔满了。

ss 命令

[root@server ~]# ss -lnt
Recv-Q Send-Q Local Address:Port  Peer Address:Port 
0        50               *:3306             *:*

上面看到的第二列Send-Q 值是50，表示第三列的listen端口上的全连接队列最大为50，第一列Recv-Q为全连接队列当前使用了多少

全连接队列的大小取决于：min(backlog, somaxconn) . backlog是在socket创建的时候传入的，somaxconn是一个os级别的系统参数

这个时候可以跟我们的代码建立联系了，比如Java创建ServerSocket的时候会让你传入backlog的值：

ServerSocket()
	Creates an unbound server socket.
ServerSocket(int port)
	Creates a server socket, bound to the specified port.
ServerSocket(int port, int backlog)
	Creates a server socket and binds it to the specified local port number, with the specified backlog.
ServerSocket(int port, int backlog, InetAddress bindAddr)
	Create a server with the specified port, listen backlog, and local IP address to bind to.

（来自JDK帮助文档：https://docs.oracle.com/javase/7/docs/api/java/net/ServerSocket.html）

半连接队列的大小取决于：max(64, /proc/sys/net/ipv4/tcp_max_syn_backlog)。 不同版本的os会有些差异

我们写代码的时候从来没有想过这个backlog或者说大多时候就没给他值（那么默认就是50），直接忽视了他，首先这是一个知识点的忙点；其次也许哪天你在哪篇文章中看到了这个参数，当时有点印象，但是过一阵子就忘了，这是知识之间没有建立连接，不是体系化的。但是如果你跟我一样首先经历了这个问题的痛苦，然后在压力和痛苦的驱动自己去找为什么，同时能够把为什么从代码层推理理解到OS层，那么这个知识点你才算是比较好地掌握了，也会成为你的知识体系在TCP或者性能方面成长自我生长的一个有力抓手

netstat 命令

netstat跟ss命令一样也能看到Send-Q、Recv-Q这些状态信息，不过如果这个连接不是Listen状态的话，Recv-Q就是指收到的数据还在缓存中，还没被进程读取，这个值就是还没被进程读取的 bytes；而 Send 则是发送队列中没有被远程主机确认的 bytes 数

$netstat -tn  
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State  
tcp0  0 server:8182  client-1:15260 SYN_RECV   
tcp0 28 server:22    client-1:51708  ESTABLISHED
tcp0  0 server:2376  client-1:60269 ESTABLISHED

**netstat -tn 看到的 Recv-Q 跟全连接半连接没有关系，这里特意拿出来说一下是因为容易跟 ss -lnt 的 Recv-Q 搞混淆，顺便建立知识体系，巩固相关知识点 **

Recv-Q 和 Send-Q 的说明
1
2
3
4
5
6
7
Recv-Q
Established: The count of bytes not copied by the user program connected to this socket.
Listening: Since Kernel 2.6.18 this column contains the current syn backlog.

Send-Q
Established: The count of bytes not acknowledged by the remote host.
Listening: Since Kernel 2.6.18 this column contains the maximum size of the syn backlog.
通过 netstat 发现问题的案例

自身太慢，比如如下netstat -t 看到的Recv-Q有大量数据堆积，那么一般是CPU处理不过来导致的：

image.png

下面的case是接收方太慢，从应用机器的netstat统计来看，也是压力端回复太慢（本机listen 9108端口)

image.png

send-q表示回复从9108发走了，没收到对方的ack，基本可以推断PTS到9108之间有瓶颈

上面是通过一些具体的工具、指标来认识全连接队列（工程效率的手段）

实践验证一下上面的理解

把java中backlog改成10（越小越容易溢出），继续跑压力，这个时候client又开始报异常了，然后在server上通过 ss 命令观察到：

Fri May  5 13:50:23 CST 2017
Recv-Q Send-QLocal Address:Port  Peer Address:Port
11         10         *:3306               *:*

按照前面的理解，这个时候我们能看到3306这个端口上的服务全连接队列最大是10，但是现在有11个在队列中和等待进队列的，肯定有一个连接进不去队列要overflow掉，同时也确实能看到overflow的值在不断地增大。

Tomcat和Nginx中的Accept队列参数

Tomcat默认短连接，backlog（Tomcat里面的术语是Accept count）Ali-tomcat默认是200, Apache Tomcat默认100. 

#ss -lnt
Recv-Q Send-Q   Local Address:Port Peer Address:Port
0       100                 *:8080            *:*

Nginx默认是511

$sudo ss -lnt
State  Recv-Q Send-Q Local Address:PortPeer Address:Port
LISTEN    0     511              *:8085           *:*
LISTEN    0     511              *:8085           *:*

因为Nginx是多进程模式，所以看到了多个8085，也就是多个进程都监听同一个端口以尽量避免上下文切换来提升性能

总结

全连接队列、半连接队列溢出这种问题很容易被忽视，但是又很关键，特别是对于一些短连接应用（比如Nginx、PHP，当然他们也是支持长连接的）更容易爆发。 一旦溢出，从cpu、线程状态看起来都比较正常，但是压力上不去，在client看来rt也比较高（rt=网络+排队+真正服务时间），但是从server日志记录的真正服务时间来看rt又很短。

jdk、netty等一些框架默认backlog比较小，可能有些情况下导致性能上不去，比如这个 《netty新建连接并发数很小的case》
都是类似原因

希望通过本文能够帮大家理解TCP连接过程中的半连接队列和全连接队列的概念、原理和作用，更关键的是有哪些指标可以明确看到这些问题（工程效率帮助强化对理论的理解）。

另外每个具体问题都是最好学习的机会，光看书理解肯定是不够深刻的，请珍惜每个具体问题，碰到后能够把来龙去脉弄清楚，每个问题都是你对具体知识点通关的好机会。

最后提出相关问题给大家思考

  1. 全连接队列满了会影响半连接队列吗？
  2. netstat -s看到的overflowed和ignored的数值有什么联系吗？
  3. 如果client走完了TCP握手的第三步，在client看来连接已经建立好了，但是server上的对应连接实际没有准备好，这个时候如果client发数据给server，server会怎么处理呢？（有同学说会reset，你觉得呢？）

提出这些问题就是以这个知识点为抓手，让你的知识体系开始自我生长

参考文章：

http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html

http://www.cnblogs.com/zengkefu/p/5606696.html

http://www.cnxct.com/something-about-phpfpm-s-backlog/

http://jaseywang.me/2014/07/20/tcp-queue-%E7%9A%84%E4%B8%80%E4%BA%9B%E9%97%AE%E9%A2%98/

http://jin-yang.github.io/blog/network-synack-queue.html#

http://blog.chinaunix.net/uid-20662820-id-4154399.html

https://www.atatech.org/articles/12919

https://www.cnblogs.com/xiaolincoding/p/12995358.html

其它

分析与思考——黄奇帆的复旦经济课笔记

分析与思考——黄奇帆的复旦经济课笔记

这是一次奇特的读书经历，因为黄奇帆这本书的内容主要是17-19年的一些报告内容，里面给出了他的一些看法以及各种数据，所以在3年后的2021年来读的话，我能够搜索当前的数据来印证他的判断，这种穿越的感觉很好。

黄比较厉害的是思路、逻辑清晰，然后各种数据比较丰富，所以他对问题的判断和看法比较准确。另外一个准确的是任大炮。相较另外一些教授、专家就混乱无比了，比如易宪容

比如，去杠杆比他预估的要差多了，杠杆这几年不但没去成反而加大了；政府债务占比也没有按他的预期减少，稳中有增；房地产开工面积也在增加，当然增速很慢了，占GDP比重也在缓慢增加。

以下引用内容都是从网络搜索所得，其它内容为黄书中直接复制出来的，附录内容没有读。

去杠杆

  • 国家M2。2017年中国M2已经达到170万亿元，这几个月下来到5月底已经是176万亿元，我们的GDP 2017年是82万亿元，M2与GDP之比已经是2.1∶1。美国的M2跟它的GDP之比是0.9∶1，美国GDP是20万亿美元，他们M2统统加起来，尽管已经有了三次（Q1、Q2、Q3）的宽松，现在的M2其实也就18万亿美元，所以我们这个指标就显然是非常非常的高。
  • 我们国家金融业的增加值。2017年年底占GDP总量的7.9%，2016年年底是8.4%，2017年五六月份到了8.8%，下半年开始努力地约束金融业夸张性的发展或者说太高速的发展，把这个约束了一下，所以到2017年年底是7.9%，2018年1—5月份还是在7.8%左右。这个指标也是世界最高，全世界金融增加值跟全世界GDP来比的话，平均是在4%左右。像日本尽管有泡沫危机，从20世纪80年代一直到现在，基本上在百分之五点几。美国从1980年到2000年也是百分之五点几，2000年以来，一直到次贷危机才逐渐增加。2008年崩盘之前占GDP的百分之八点几。这几年约束了以后，现在是在7%左右。它是世界金融的中心，全世界的金融资源集聚在华尔街，集聚在美国，产生的金融增加值也就是7%，我们并没有把世界的金融资源增加值、效益利润集聚到中国来，中国的金融业为何能够占中国80多万亿元GDP的百分之八点几？中国在十余年前，也就是2005年的时候，金融增加值占当时GDP的5%不到，百分之四点几，快速增长恰恰是这些年异常扩张、高速发展的结果。这说明我们金融发达吗？不对，其实是脱实就虚，许多金融GDP把实体经济的利润转移过来，使得实体经济异常辛苦，从这个意义上说，这个指标是泡沫化的表现。
  • 我们国家宏观经济的杠杆率。非银行非金融的企业负债，政府部门的负债(40%多)，加上居民部门的负债(50%)，三方面加起来是GDP的2.5倍，250%，在世界100多个国家里我们是前5位，是偏高的，我们跟美国相当，美国也是250%，日本是最高的，现在是440%，英国也比较高，当然欧洲一些国家，比如意大利或者西班牙，以及像希腊等一些债务财政出问题的小的国家，他们也异常的高。即使这样，我们的债务杠杆率排在世界前5位，也是异常的高。
  • 每年全社会新增的融资。我们的企业每年都要融资，除了存量借新还旧，存量之外，有个增量，我们在十年前每年全社会新增融资量是五六万亿元，五年前新增的量在10万亿—12万亿元，2017年新增融资18万亿元。每年新增的融资里面，股权资本金性质的融资只占总的融资量的10%不到一点，也就是说91%是债权，要么是银行贷款，要么是信托，要么是小贷公司，或者直接是金融的债券。大家可以想象，如果每年新增的融资总是90%以上是债权，10%是股权的话，这个数学模型推它十年，十年以后中国的债务不会缩小，只会越来越高。

2021年4月末，广义货币(M2)余额226.21万亿元,同比增长8.1%，增速分别比上月末和上年同期低1.3个和3个百分点；狭义货币(M1)余额60.54万亿元,同比增长6.2%，增速比上月末低0.9个百分点，比上年同期高0.7个百分点；流通中货币(M0)余额8.58万亿元,同比增长5.3%。当月净回笼现金740亿元。

杠杆率是250%，在全世界来说是排在前面，是比较高的。这个指标里面又分成三个方面，其中政府的债务占GDP不到50%，国家统计公布的数据是40%多，但是有些隐性债务没算进去，就算算进去也不到50%。第二个方面是老百姓的债务，十年前还只占10%，五年前到了20%，我印象中有一年中国人民银行也说了，中国居民部门的债务还可以放一点杠杆，这两年按揭贷款异常发展起来，居民债务两年就上升到50%。老百姓这一块的债务，主要是房产的债务，也包括信用卡和其他投资，总的也占GDP50%左右。两个方面加起来就等于GDP，剩下的160%是企业债务，美国企业负债是美国GDP的60%，而中国企业的负债是GDP的160%，这个指标是有问题的

中国政府的40多万亿元债务是中央政府的债务有十几万亿元，地方政府的债务有20多万亿元，加在一起40多万亿元，占GDP 50%左右，我们是把区县、地市、省级政府到国家级统算在一起的。所以，我们中国政府的债务算得是比较充分的。

人民网北京2021年4月7日电 （记者王震）国务院新闻办公室4月7日就贯彻落实“十四五”规划纲要，加快建立现代财税体制有关情况举行发布会。财政部部长助理欧文汉介绍，截至2020年末，地方政府债务余额25.66万亿元，控制在全国人大批准的限额28.81万亿元之内，加上纳入预算管理的中央政府债务余额20.89万亿元，全国政府债务余额46.55万亿元，政府债务余额与GDP的比重为45.8%，低于国际普遍认同的60%警戒线，风险总体可控。

image.png

去企业负债杠杆方法：第一是坚定不移地把没有任何前途的、过剩的企业，破产关闭，伤筋动骨、壮士断腕，该割肿瘤就要割掉一块(5%)。第二是通过收购兼并，资产重组去掉一部分坏账，去掉一部分债务，同时又保护生产力(5%)。第三是优势的企业融资，股权融资从新增融资的10%增加到30%、40%、50%，这应该是一个要通过五年、十年实现的中长期目标。第四是柔性地、柔和地通货膨胀，稀释债务，一年2个点，五年就是10个点，也很可观。第五是在基本面上保持M2增长率和GDP增长率与物价指数增长率之和大体相当。我相信通过这五方面措施，假以时日，务实推进，那么有个三五年、近十年，我们去杠杆四五十个百分点的宏观目标就会实现。

怎么把股市融资和私募投资从10%上升到40%、50%，这就是我们中国投融资体制，金融体制要发生一个坐标转换。这里最重要的，实际上是两件事。第一件事，要把证券市场、资本市场搞好。十几年前上证指数两三千点，现在还是两三千点。美国股市指数翻了两番，香港股市指数也翻了两番。我国国民经济总量翻了两番，为什么股市指数不增长？这里面要害是什么呢？可以说有散户的结构问题，有长期资本缺乏的问题，有违规运作处罚不力的问题，有注册制不到位的问题，各种问题都可以说。归根到底最重要的一个问题是什么呢？就是退市制度没搞好。

供应侧结构化改革三去一降一补

供应侧结构化改革三去一降一补：去产能、去库存、去杠杆、降成本、补短板

中国所有的货物运输量占GDP的比重是15%，美国、欧洲都在7%，日本只有百分之五点几。我们占15%就比其他国家额外多了几万亿元的运输成本。中国交通运输的物流成本高，除了基础设施很大一部分是新建投资、折旧成本较高以外，相当大的部分是管理体制造成的。由于我们的管理、软件、系统协调性、无缝对接等方面存在很多问题，造成了各种物流成本抬高。在这个问题上，各个地方，各个系统，各个行业都把这方面问题重视一下、协调一下，人家7%，我们哪怕降不到7%的GDP占比，能够降3%—4%的占比，就省了3万亿—4万亿元

按国际惯例，个人所得税率一般低于企业所得税率，我国的个人所得税采取超额累进税率与比例税率相结合的方式征收，工资薪金类为超额累进税率5%—45%。最高边际税率45%，是在1950年定的，当时我国企业所得税率是55%，个人所得税率定在45%有它的理由。现在企业所得税率已经降到25%，个人所得税率还保持在45%，明显高于前者，也高于大多数国家25%左右的水平。

到2018年底，中国个人住房贷款余额25.75万亿元，而公积金个人住房贷款余额为4.98万亿元，在整个贷款余额中不到20%，其为人们购房提供低息贷款的功能完全可以交由商业银行按揭贷款来解决。可以考虑公积金合并为年金

互联网金融平台、物联网金融平台、物联网+金融形成的平台会在这里起颠覆性的、全息性的、五个全方位信息（全产业链的信息、全流程的信息、全空间布局的信息、全场景的信息、全价值链的信息）的配置作用

“三元悖论”，即安全、廉价、便捷三者不可能同时存在

鉴于互联网商业平台公司的商业模式已经远远超出传统商业规模所能达成的社会影响力，所以，互联网商业平台公司与其说是在从事商业经营，不如说是在从事网络社会的经营和管理。正因如此，国家有必要通过立法，构建一种由网络安全、金融安全、社会安全、财政安全等相关部门参加的“互联网技术研发信息日常跟踪制度”。

货币

“二战”后建立的“布雷顿森林体系”，即“美元与黄金挂钩，其他国家货币与美元挂钩”的“双挂钩”制度，其实质也是一种“金本位”制度，而1971年美国总统尼克松宣布美元与黄金脱钩也正式标志着美元放弃了以黄金为本位的货币制度，随之采取的是“主权信用货币制”

近十余年来，美国为了摆脱金融危机，政府债务总量从2007年的9万亿美元上升到2019年的22万亿美元，已经超过美国GDP

从1970年开始，欧美、日本等大部分世界发达国家逐步采用了“主权信用货币制”，在实践中总体表现较好，货币的发行量与经济增量相匹配，保持了经济的健康增长和物价的稳定。这种货币制度通常以M3、经济增长率、通胀率、失业率等作为“间接锚”，并不是完全的无锚制货币。

从1970年到2008年，美国政府在应用主权信用货币制度的过程中基本遵守货币发行纪律，货币的增长与GDP增长、政府债务始终保持适度的比例。1970年，美国基础货币约为700亿美元，2007年底约为8200亿美元，大约增长了12倍。与此同时，美国GDP从1970年的1.1万亿美元增长到2007年的14.5万亿美元，大概增长了13倍。美元在全世界外汇储备中的占比稳定在65%以上

从2008年年底至2014年10月，美联储先后出台三轮量化宽松政策，总共购买资产约3.9万亿美元。美联储持有的资产规模占国内生产总值的比例从2007年年底的6.1%大幅升至2014年年底的25.3%，资产负债表扩张到前所未有的水平。

从2008年到2019年，美国基础货币供应量从8200亿美元飙升到4万亿美元，整体约增长了5倍，与此同时，美国GDP仅增长了1.5倍，基础货币的发行增速几乎是同期GDP增速的3倍以上。在这种货币政策的驱动下，美国股市开启了十年长牛之路，股市从6000点涨到28000点。各类资产价格开始重新走上上涨之路，美国经济沉浸在一片欣欣向荣之中。

1913年美国《联邦储备法案》规定，美元的发行权归美联储所有。美国政府没有发行货币的权力，只有发行国债的权力。但实际上，美国政府可以通过发行国债间接发行货币。美国国会批准国债发行规模，财政部将设计好的不同种类的国债债券拿到市场上进行拍卖，最后拍卖交易中没有卖出去的由美联储照单全收，并将相应的美元现金交给财政部。这个过程中，财政部把国债卖给美联储取得现金，美联储通过买进国债获得利息，两全其美，皆大欢喜。

2008年前美国以国家信用为担保发行美债，美债余额始终控制在GDP的70%比例之内，国家信用良好。美债作为全世界交易规模最大的政府债券，长久以来保持稳定的收益，成为黄金以外另一种可靠的无风险资产。美国的货币供给总体上与世界经济的需求也保持着适当的比例，进一步加强了美元的信用。

美国GDP占全球GDP的比重已经从50%下降到24%，但美元仍然是主要的国际交易结算货币。尽管近年来美元在国际储备货币中的占比逐渐从70%左右滑落到62%，但美元的地位短时间内仍然看不到动摇的迹象

布雷顿森林体系解体后，各国以美元为货币“名义锚”的强制性随之弱化，但在自由选择条件下，绝大多数发展中国家仍然选择美元为“名义锚”，实行了锚定美元，允许一定浮动的货币调控制度。另有一些发展中国家选择锚定原来的宗主国，以德国马克、法国法郎和英镑等货币为“名义锚”。而主要的发达国家在货币寻锚的过程中，经历了一些波折之后，大多选择以“利率、货币发行量、通货膨胀率”等指标作为货币发行中间目标，实际上锚定的是国内资产。总之，从当前来看，世界的货币大致形成了两类发行制度：以“其他货币”为名义锚的货币发行体制和以“本国资产”为名义锚的货币发行体系，也称为主权信用货币制度。

香港采用的货币制度很独特，被称为“联系汇率”制度，又被称为“钞票局”制度，据说是19世纪一位英国爵士的发明。其基本内容是香港以某一种国际货币为锚（20世纪70年代以前以英镑为本位，80年代后改以美元为本位），即以该货币为储备发行港币，通过中央银行吞吐储备货币来达到稳定本币汇率的目标。在这种货币制度下，不仅需要储备相当规模的锚货币，其还有一个重大缺陷是必须放弃独立的货币政策，即本位货币加降息时，其也必须跟随。因此，这种货币制度只适用于小国或者小型经济体，对大国或大型经济体则不适用。

从新中国成立到如今，人民币发行制度经历了从“物资本位制”到“汇兑本位制”两个阶段，这两种不同时期实施的货币制度在当时都有效地促进了国民经济的发展。1995年以后，面对新的形势，中国人民银行探索通过改革实行了新的货币制度——“汇兑本位制”，即通过发行人民币对流入的外汇强制结汇，人民币汇率采取盯住美元的策略，从而保持人民币的汇率基本稳定。

在“汇兑本位制”下，我国主要有两种渠道完成人民币的发行。第一种，当外资到我国投资时，需要将其持有的外币兑换成人民币，这就是被结汇。结汇以后，在中国人民银行资产负债表上，一边增加了外汇资产，另一边增加了存款准备金的资产，这实际上就是基础货币发出的过程。中央银行的资产负债表中关于金融资产分为两部分，一部分是外币资产，另一部分是基础货币。基础货币包括M0和存款准备金，而这部分的准备金就是因为外汇占款而出现的。

第二种则是贸易顺差。中国企业由于进出口业务产生贸易顺差，实际上是外汇结余。企业将多余的外汇卖给商业银行，再由央行通过发行基础货币来购买商业银行收到的外汇。商业银行收到央行用于购买外汇的基础货币，就会通过M0流入社会。长此以往，就会增加通货膨胀的风险。央行为规避通货膨胀的风险，就会通过提高准备金率将多出的基础货币回收。

在“汇兑本位制”下，外汇储备可以视作人民币发行的基础或储备，且由于实行强制结汇，外汇占款逐渐成为我国基础货币发行的主要途径，到2013年末达到83%的峰值，此后略有下降，截至2019年7月末，外汇占款占中国人民银行资产总规模达到59.35%，说明有近六成人民币仍然通过外汇占款的方式发行。

现代货币理论（缩写MMT）是一种非主流[1]宏观经济学理论，认为现代货币体系实际上是一种政府信用货币体系。[2] 现代货币理论即主权国家的货币并不与任何商品和其他外币挂钩，只与未来税收与公债相对应。[3]因为主权货币具有无限法偿性质，没有名义预算约束，只存在通货膨胀的实际约束。–基本上就是：主权信用货币制度

“汇兑本位制”的实质：锚定美元

我国的人民币汇率制度基于两个环节。第一，人民币的汇率是人民币和外币之间的交换比率，是人民币与一篮子货币形成的一个比价。我国在同其他国家进行投资、贸易时，人民币按照汇率进行兑换。由于美元是目前世界上最主要的货币，所以虽然人民币与一篮子货币形成相对均衡的比价，但由于美元在一篮子货币中占有较大的比重，人民币最重要的比价货币是美元。第二，我国实行结汇制，即我国的商业银行、企业，基本上不能保存外汇，必须将收到的外汇卖给央行。因此，由于我国的货币发行的基础是外汇，而美元在我国的外汇占款、一篮子货币中占比较高，因此可以说人民币是间接锚定美元发行的。

截至2018年12月底，中国人民银行资产总规模为37.25万亿元，其中外汇占款达21.25万亿元。外汇占款在货币发行中的份额已经从2013年的83%降低至2008年初的57%左右。与此同时，央行对其他存款性公司债权迅速扩张，从2014年到2016年底扩张了2.4倍，占总资产份额从7.4%升至24.7%。这说明了随着外汇占款成为基础货币回笼而非投放的主渠道，央行主要通过公开市场操作和各类再贷款便利操作购买国内资产来投放货币，不失为在外汇占款不足的情况下供给货币的明智选择。同时，央行连续降低法定存款准备金率，提高了货币乘数，一定程度上也缓解了国内流动性不足的问题。

外汇占款在货币发行存量中的比重仍然接近60%，只是通过一些货币政策工具缓解了原来“汇兑本位制”的问题。一旦日后出现大量贸易顺差导致外汇储备增加，货币发行制度就会又回到老路上。

实施“主权信用货币制度”是大国崛起的必然选择

从根本上来说，税收是货币的信用，财政可以是货币发行的手段，而且是最高效公平的手段，央行买国债是能够自主收放的货币政策手段。一旦货币超发后，央行只需要提高利率、提高存款准备金率回收基础货币，而财政部门也可以通过增加税收、注销政府债券的方式来消除多余的货币、避免通货膨胀。

实际上，信用货币制度最大的问题在于锚的不清晰、不稳定，缺乏刚性。

特别提款权（Special Drawing Right，SDR），亦称“纸黄金”（Paper Gold），最早发行于1969年，是国际货币基金组织根据会员国认缴的份额分配的，可用于偿还国际货币基金组织债务、弥补会员国政府之间国际收支逆差的一种账面资产。 其价值由美元、欧元、人民币、日元和英镑组成的一篮子储备货币决定。

主权信用货币背景下，人民币是由国债做锚的。中央银行为了发行基础货币，需要购买财政部发行的国债，但中央银行不能购买财政部为了弥补财政亏空发行的国债。《中华人民共和国中国人民银行法》规定，中国人民银行不得直接认购、包销国债和其他政府债券。这意味着中国人民银行不能以政府的债权作为抵押发行货币，只能参与国债二级市场的交易而不能参与国债一级市场的发行，央行直接购买国债来发行基础货币的方式就被法律禁止了。因此，建立以国债为基础的人民币发行制度，必须对相关法律法规进行修改。

2017年5月 房地产

中国房地产和实体经济存在“十大失衡”——土地供求失衡、土地价格失衡、房地产投资失衡、房地产融资比例失衡、房地产税费占地方财力比重失衡、房屋销售租赁比失衡、房价收入比失衡、房地产内部结构失衡、房地产市场秩序失衡、政府房地产调控失衡

土地调控得当、法律制度到位、土地金融规范、税制结构改革和公租房制度保障，并特别强调了“地票制度”对盘活土地存量，提高耕地增量的重要意义

为国家粮食战略安全计，我国土地供应应逐步收紧，2015年供地770万亩，2016年700万亩，今年计划供应600万亩

国家每年批准供地中，约有三分之一用于农村建设性用地，比如水利基础设施、高速公路等，真正用于城市的只占三分之二，这部分又一分为三：55%左右用于各种基础设施和公共设施，30%左右给了工业，实际给房地产开发的建设用地只有15%。这是三分之二城市建设用地中的15%，摊到全部建设用地中只占到10%左右，这个比例是不平衡的

对于供过于求的商品，哪怕货币泛滥，也可能价格跌掉一半。货币膨胀只是房价上涨的必要条件而非充分条件，只是外部因素而非内部因素。内因只能是供需关系

住房作为附着在土地上的不动产，地价高房价必然会高，地价低房价自然会低，地价是决定房价的根本性因素。如果只有货币这个外因存在，地价这个内因不配合，房价想涨也是涨不起来的。控制房价的关键就是要控制地价。

拍卖机制，加上新供土地短缺，旧城改造循环，这三个因素相互叠加，地价就会不断上升—核心加大供地可解地价过高

按经济学的经验逻辑，一个城市的固定资产投资中房地产投资每年不应超过25%

正常情况下，一个家庭用于租房的支出最好不要超过月收入的六分之一，超过了就会影响正常生活。买房也如此，不能超过职工全部工作年限收入的六分之一，按每个人一生工作40年左右时间算，“6—7年的家庭年收入买一套房”是合理的。—-中国每个人体制外算20年工作时间，体制内可算35年

从均价看，一线城市北京、上海、广州、深圳、杭州等，房价收入比往往已到40年左右。这个比例在世界已经处于很高的水平了。考虑房价与居民收入比，必须高收入对高房价，低收入对低房价，均价对均价。有人说，纽约房子比上海还贵，伦敦海德公园的房价也比上海高。但伦敦城市居民的人均收入要高出上海几倍。就均价而言，伦敦房价收入比还是在10年以内。

每年固定资产投资不应超过GDP的60%。如果GDP有1万亿元，固定资产投资达到1.3万亿元甚至1.5万亿元，一年两年可以，长远就会不可持续。固定资产投资不超过GDP的60%，再按“房地产投资不超过固定资产投资的25%”，也符合“房地产投资不超过GDP六分之一”这一基本逻辑。

大陆31个省会城市和直辖市中，房地产投资连续多年占GDP 60%以上的有5个，占40%以上的有16个，显然偏高

房地产17-18w亿,大概8.5w亿是直接留给卖地的地方政府
之后3-4w亿是各种建筑商供应商的辛苦钱
还有1w亿+流向的银行贷款的利息
1w亿+是各种非银金融机构,如信托和平安保险等
之后又是一轮税收,然后才是房地产商和房地产人
搞死房地产也许容易,但是你得指条明路,让这些人找到新地方做业务活着啊..

上海易居房地产研究院3月9日发布《2019年区域房地产依赖度》。该报告显示:房地产开发投资占GDP比重可以用来衡量当地经济对房地产的依赖程度，占比越高，说明经济对房地产的依赖度越高。2019年，房地产开发投资占GDP比重排名前三位的省市分别是海南、天津和重庆，占比分别为25.2%、19.3%和18.8%。

2020年杭州市GDP总量达到16106亿元，比2019年增长3.9%

有15个城市去年房地产开发投资额超过1000亿元，其中超过2000亿元的共8个，分别是杭州、郑州、广州、武汉、成都、南京、西安和昆明，杭州、郑州、广州三城更是超过了3000亿元。杭州以3397.27亿元在26城中位居榜首

2019年，除了杭州土地出让金继续领跑外，数据显示南京的卖地收入达到了1696.8亿元，同比增长77.32%，福州增幅为63.37%，昆明为59.85%，武汉为27.89%。去年土地出让金额没有超过1000亿元的城市中，合肥土地出让收入增长了33.32%，长沙增长了33.75%，贵阳增长了52%。

2020年，GDP前10强的城市依次为：上海、北京、深圳、广州、重庆、苏州、成都、杭州、武汉、南京。

image.png

2011年，全国人民币贷款余额54.8万亿元，其中房地产贷款余额10.7万亿元，占比不到20%。这一比例逐年走高，2016年全国106万亿元的贷款余额中，房地产贷款余额26.9万亿元，占比超过25%。也就是说，房地产占用了全部金融资金量的25%，而房地产贡献的GDP只有7%左右。2016年全国贷款增量的45%来自房地产，一些国有大型银行甚至70%—80%的增量是房地产。从这个意义上讲，房地产绑架了太多的金融资源，导致众多金融“活水”没有进入到实体经济，就是“脱实就虚”的具体表现。

这些年，中央加地方的全部财政收入中，房地产税费差不多占了35%，乍一看来，这一比例感觉还不高。但考虑到房地产税费属地方税、地方费，和中央财力无关，把房地产税费与地方财力相比较，则显得比重太高。全国10万亿元地方税中，有40%也就是4万亿是与房地产关联的，再加上土地出让金3.7万亿元，全部13万亿元左右的地方财政预算收入中就有近8万亿元与房地产有关（60%）。政府的活动太依赖房地产，地方政府财力离了房地产是会断粮的，这也是失衡的。

一般中等城市每2万元GDP造1平方米就够了，再多必过剩。对大城市而言，每平方米写字楼成本高一些，其资源利用率也会高一些，大体按每平方米4万元GDP来规划。

一个城市的土地供应总量一般可按每人100平方米来控制，这应该成为一个法制化原则。100万城市人口就供应100平方千米。爬行钉住，后发制人。

人均100平方米的城市建设用地，该怎么分配呢？不能都拿来搞基础设施、公共设施，也不能都拿来搞商业住宅。大体上，应该有55平方米用于交通、市政、绿地等基础设施和学校、医院、文化等公共设施，这是城市环境塑造的基本需要。对工业用地，应该控制在20平方米以内，每平方千米要做到100亿元产值。剩下的25平用于房地产开发

房产税应包括五个要点：（1）对各种房子存量、增量一网打尽，增量、存量一起收；（2）根据房屋升值额度计税，如果1%的税率，价值100万元的房屋就征收1万元，升值到500万元税额就涨到5万元；（3）越高档的房屋持有成本越高，税率也要相对提高；（4）低端的、中端的房屋要有抵扣项，使得全社会70%—80%的中低端房屋的交税压力不大；（5）房产税实施后，已批租土地70年到期后可不再二次缴纳土地出让金，实现制度的有序接替。这五条是房产税应考虑的基本原则。

房地产调控的长效机制：一是金融；二是土地；三是财税；四是投资；五是立法。

在1990年之前，中国是没有商品房交易的，那时候一年就是1000多万平方米。在1998年和1999年的时候，中国房地产一年新建房的交易销售量实际上刚刚达到1亿平方米。从1998年到2008年，这十年里平均涨了6倍，有的城市实际上涨到8倍以上，十年翻三番。2007年，销售量本来已经到了差不多7亿平方米，2008年全球金融危机发生了，在这个冲击下，中国的房产交易量也下降了，萎缩到6亿平方米。后来又过了5年，到了2012年前后，房地产的交易量翻了一番，从6亿平方米增长到12亿平方米。从2012年到2018年，又增加了5亿平方米。总之在过去的20年，中国房地产每年的新房销售交易量差不多从1亿平方米增长到17亿平方米，翻了四番多。

今后十几年，中国每年的房地产新房的交易量不仅不会继续增长翻番，还会每年小比例地有所萎缩，或者零增长，或者负增长。十几年以后，每年房地产的新房销售交易量可能下降到10亿平方米以内，大体上减少40%的总量。

今后十几年的房地产业发展趋势，不会是17亿平方米、18亿平方米、20亿平方米、30亿平方米，而是逐渐萎缩，当然这个萎缩不会在一年里面大规模萎缩20%、30%，大体上有十几年的过程，每年往下降。十几年后产生的销售量下降到10亿平方米以下

http://www.ce.cn/cysc/fdc/fc/202101/18/t20210118_36234860.shtml#:~:text=%E5%BD%93%E6%97%A5%E5%8F%91%E5%B8%83%E7%9A%84%E6%95%B0%E6%8D%AE%E6%98%BE%E7%A4%BA,%E7%9A%8415.97%E4%B8%87%E4%BA%BF%E5%85%83%E3%80%82: 2020年,中国商品房销售面积176086万平方米,比上年增长2.6%,2019年为下降0.1%。 商品房销售额173613亿元,增长8.7%,增速比上年提高2.2个百分点。 此前,中国商品房销售面积和销售额的最高纪录分为2018年的近17.17亿平方米和2019年的15.97万亿元。

image.png

1990年，中国人均住房面积只有6平方米；到2000年，城市人均住房面积也仅十几平方米，现在城市人均住房面积已近50平方米。人均住房面积偏小，也会产生改善性的购房需求。

根据国家统计局公布的数据，1982年至2019年，我国常住人口城镇化率从21.1%上升至60.6%，上升超过39个百分点；同期，户籍人口城镇化率仅从17.6%上升至44.4%，上升不到27个百分点。

经济日报-中国经济网北京2月28日讯国家统计局网站2月28日发布我国2020年国民经济和社会发展统计公报。 公报显示，2020年末，我国常住人口城镇化率超过60%。Feb 28, 2021

image.png

官方数据显示，2020年，我国的城镇化率高达63.89%，比发达国家80%的平均水平低了16.11%，与美国82.7%的城镇化水平还有18.81%的距离。

image.png

image.png

当前我国人均住房面积已经达到近50平方米

2012年，住建部下发了一个关于住宅和写字楼等各种商品性房屋的建筑质量标准，把原来中国住宅商品房30年左右的安全标准提升到了至少70年，甚至100年。这意味着从2010年以后，新建造的各种城市商品房，理论上符合质量要求的话，可以使用70年到100年，这也就是说老城市的折旧改造量会大量减少。

实际据说12年后因为利润率的原因房子质量在下降？！待证

中国各个省的省会城市大体上发展规律都会遵循“一二三四”的逻辑。所谓“一二三四”，就是这个省会城市往往占有这个省土地面积的10%不到，一般是5%—10%；但是它的人口一般会等于这个省总人口的20%；它的GDP有可能达到这个省总GDP的30%；它的服务业，不论是学校、医院、文化等政府主导的公共服务，还是金融、商业、旅游等市场化的服务业，一般会占到这个省总量的40%。

河南省有1亿人口，郑州目前只有1000万人口。作为省会城市，应承担全省20%的人口，所以十几年、20年以后郑州发展成2000万人口一点不用惊讶。同样的道理，郑州的GDP现在到了1万亿元，整个河南5万亿元，它贡献了20%，如果要30%的话应该是1.5万亿元，还相差甚远。对于服务业，一个地方每100万人应该有一个三甲医院，如果河南省1亿人口要有100个的话，郑州就应该有40个，它现在才9个三甲医院，每造一个三甲医院投资20多亿元，产生的营业额也是20多亿元，作为服务业，营业额对增加值贡献比率在80%以上。

大家可以关注现在近十个人口超过1000万的国家级超级大城市，根据这些省总的经济人口规模去算一下，它们都有十几年以后人口增长500万以上的可能。只要人口增长了，城市住宅房地产就会跟上去。所以我刚才说的大都市、超级大城市，人口在1000万—2000万之间的有一批城市还会扩张，过了2000万的，可能上面要封顶，但是在1000万—2000万之间的不会封顶，会形成它的趋势。

在今后的十几年，房地产开发不再是四处开花，而会相对集聚在省会城市及同等级区域性中心城市、都市圈中的中小城市和城市群中的大中型城市三个热点地区。

根据住房和城乡建设部于2020年底最新公布的《2019年城市建设统计年鉴》，符合中国“超大城市”标准的共有上海、北京、重庆、广州、深圳、天津。

东莞、武汉、成都、杭州、南京、郑州、西安、济南、沈阳和青岛这10个城市的城区人口处于500万到1000万之间，属于特大城市。Jan 12, 2021

根据住建部最新数据，2019年底，长沙城区人口384.75万人，建成区面积377.95平方公里。 与2018年的374.43万人相比，2019年底长沙城区人口增加约10万人。 注意，这个城区的统计范围包括雨花、岳麓、芙蓉、天心、开福、望城六区，应该不包括长沙县，因为长沙县目前不是设区市，也不是县级市。Jan 26, 2021

长沙市总人口810万

image.png

image.png

从通货膨胀看，我国M2已经到了190万亿元，会不会今后十年M2再翻两番？不可能，这两年国家去杠杆、稳金融已经做到了让M2的增长率大体上等于GDP的增长率加物价指数，这几年的GDP增长率百分之六点几，物价指数加两个点，所以M2在2017年、2018年都是八点几，2019年1—6月份是8.5%，基本上是这样。M2如果是八点几的话，今后十几年，基本上是GDP增长率加物价指数，保持均衡的增长。如果中国的GDP今后十几年平均增长率大体在5%—6%，房地产价格的增长大体上不会超过M2的增长率，也不会超过GDP的增长率，一般会小于老百姓家庭收入的增长率。

9万多个房产企业中，排名在前的15%大开发商在去年的开发，实际的施工、竣工、销售的面积，在17亿平方米里面它们可能占了85%。意思是什么呢？15%的企业解决了17亿平方米的85%，就是14亿多平方米，剩下的企业只干了那么2亿多平方米，有大量的空壳公司。

中国的房地产企业，我刚才说9万多个，9万多个房产商的总负债率2018年是84%。中国前十位的销售规模在1万亿元左右的房产商，它们的负债率也是在81%。

REITs: Real Estate Investment Trusts，译为房地产投资信托基金

地王的产生都是因为房产商背后有银行，所以政府的土地部门，只要资格审查的时候查定金从哪儿来，拍卖的时候资金从哪儿来，只要审查管住这个，就一定能管住地王现象的出现

2000年，中国房地产增加值仅为4141亿元，在当年GDP中占比4.1%。二十年后，2020年中国房地产增加值跃升至74553亿元，GDP占比7.3%。在20年时间里，房地产增加值大涨70412亿元，增长率达78%。

房地产增加值从1万亿元增加到2万亿元用了5年，从2万亿元到3万亿元用了3年，从5万亿元到7万亿年只用了4年。房地产新创造价值的增长速度越来越快。

image.png

香港公租房面积：現時公屋單位的人均室內面積不得小於七平方米，惟房委會近年興建單位時，面積均僅停留在合格線，供一至二人入住的甲類單位，面積只及14平方米，二至三人的乙類單位也只有21平方米。 尤有甚者，有報章整理房委會資料，2020至2024年度的甲、乙類單位佔52%，總數3.44萬個，較跟2015至2019年度落成單位高11個百分點。Jan 19, 2021

对外开放

近40年以来世界贸易的格局，国际贸易的产品结构、企业组织和管理的方式，国家和国家之间贸易有关的政策均发生了重要的变化。货物贸易中的中间品的比重上升到70%以上，在总贸易量中服务贸易的比重从百分之几变成了30%。

产品交易和贸易格局的变化，导致跨国公司的组织管理方式发生变化，谁控制着产业链的集群、供应链的纽带、价值链的枢纽，谁就是龙头老大。由于世界贸易格局特征的变化，由于跨国公司管理世界级的产品的管理模式的变化，也就是“三链”这种特征性的发展，引出了世界贸易新格局中的一个新的国际贸易规则制度的变化，就是零关税、零壁垒和零补助“三零”原则的提出，并将是大势所趋。中国自贸试验区的核心，也就是“三零”原则在自己这个区域里先行先试，等到国家签订FTA的时候，自贸试验区就为国家签订FTA提供托底的经验。

现在一个产品，涉及几千个零部件，由上千个企业在几百个城市、几十个国家，形成一个游走的逻辑链，那么谁牵头、谁在管理、谁把众多的几百个上千个中小企业产业链中的企业组织在一起，谁就是这个世界制造业的大头、领袖、集群的灵魂。

能提出行业标准、产品标准的企业往往是产品技术最大的发明者。谁控制供应链，谁其实就是供应链的纽带。你在组织整个供应链体系，几百个、上千个企业，都跟着你的指挥棒，什么时间、什么地点、到哪儿，一天的间隙都不差，在几乎没有零部件库存的背景下，几百个工厂，非常有组织、非常高效地在世界各地形成一个组合。在这个意义上讲，供应链的纽带也十分重要。

50年前关税平均是50%—60%。到了20世纪八九十年代，关税一般都降到了WTO要求的关税水平，降到了10%以下。WTO要求中国的关税也要下降。以前我们汽车进口关税最高达到170%。后来降到50%。现在我们汽车进口关税还在20%的水平。但我们整个中国的加权平均的关税率，20世纪八九十年代是在40%—50%，到了90年代末加入WTO的时候到了百分之十几。WTO给我们一个过渡期，要求我们15年内降到10%以内。我们到2015年的确降到9.5%，到去年已经降到7.5%。现在整个世界的贸易平均关税已经降到了5%以内，美国现在是2.5%。

目前对于进口汽车收取的关税税率是25%，还有对进口车收取17%的增值税，而根据汽车的排量收取不同的消费税税率。 排量在在1.5升(含)以下3%，1.5升至2.0升(含) 5%，2.0升至2.5升(含) 9%，2.5升至3.0升(含)12%，3.0升至4.0升(含) 15%，4.0升以上20%。Jun 26, 2020

进口货物的增值税则在2018年5月1日进行了下调，由17%降为16%。

假定这辆到岸价24万的进口车为中规进口车（原厂授权，4S店销售），排气量为4.0以上，且到岸时间为5月1日前，套入相关计算公式，则其所要缴纳税费为：

　　关税：24万×25% =6万

　　消费税：（24万+6万）÷（1-40%）×40% =20万

　　增值税：（24万+6万+20万）×17% =8.5万

　　税费合计34.5万，加上24万的到岸价，总共58.5万，即这辆进口汽车的抵岸价。

　　常规而言，这个价格与90万指导价间的31.5万价差，即为运输等成本费用和国内经销商的利润。

24万的进口车为何国内要卖90万？

在这七八年，FTA，双边贸易体的讨论，或者是一个地区，五六个国家、七八个国家形成一个贸易体的讨论就不断增加，成为趋势。给人感觉好像发达国家都在进行双边谈判，把WTO边缘化了

所谓自由贸易协定（Free Trade Agrement:FTA）是指两个或两个以上的国家（包括独立关税地区）根据WTO相关规则，为实现相互之间的贸易自由化所进行的地区性贸易安排。 由自由贸易协定的缔约方所形成的区域称为自由贸易区。 FTA的传统含义是缔约国之间相互取消货物贸易关税和非关税贸易壁垒。

2019年10月8日，日本驻美国大使杉山晋辅与美国贸易谈判代表莱特希泽在白宫正式签署新日美贸易协定。美国总统特朗普不仅亲自出席见证签字，还邀请多位西北部农业州农民代表参加，声称自己为美国农民赢得了巨大市场，巧妙地将国际贸易协定变成了国内拉票筹码。

中国已经形成了世界产业链里面最大的产业链集群，但是这个集群里面，我们掌控纽带的，掌控标准的，掌控结算枢纽的，掌控价值链枢纽的企业并不多。比如华为，华为的零部件，由3600多家大大小小供应链上的企业生产。这全球的3000多家企业每年都来开供应链大会。华为就是掌控标准。它的供应链企业比苹果多两倍。为什么？苹果主要做手机，华为既做手机又做服务器、通信设备。通信设备里面的零部件原材料更多。所以，它掌控产业链上中下游的集群，掌控标准，也掌控价值链中的牵制中枢。

零关税第一个好处：对进口中间品实行零关税，将降低企业成本，提高产品的国际竞争力。

当中国制造业实施零关税的时候，事实上对于整个制造业产业链的完整化、集群化和纽带、控制能力有好处，对于中国制造业的产业链、供应链、价值链在中国形成枢纽、形成纽带、形成集团的龙头等各方面会有提升作用，这是第二个好处。

关税下降，会促进中国的生产力结构的提升，促进我们企业的竞争能力的加强，使得我们工商企业的成本下降。

我们现在差不多有6.6亿吨农作物粮食是在中国的土地上生产出来的，但是我们现在每年要进口农产品1亿吨。加在一起，也就是中国14亿人，一年要吃7.6亿吨农作物。这1亿吨里面，有个基本的分类。我们现在进口的1亿吨里面，有8000多万吨进口的是大豆、300多万吨小麦、300多万吨玉米、300多万吨糖，另外就是进口的猪肉、牛肉和其他的肉类，也有几百万吨。

从2010年起步，当年人民币只有近千亿元的结算量，从这些年发展来看，2018年已经到7万亿元了。也就是说，中国进出口贸易里面有7万亿元人民币是人家收了人民币而不去收美元

自贸区

在过去的40年，我们国家的开放有五个基本特点：

第一个就是以出口导向为基础，利用国内的资源优势和劳动力的比较优势，推动出口发展，带动中国经济更好地发展；

第二个就是以引进外资为主，弥补我们中国当时还十分贫困的经济和财力；

第三个就是以沿海开放为主，各种开发区或者各种特区，包括新区、保税区，都以沿海地区先行，中西部内陆逐步跟进；

第四个就是开放的领域主要是工业、制造业、房地产业、建筑业等先行开放，至于服务业、服务贸易、金融保险业务开放的程度比较低，即以制造业、建筑业等第二产业开放为主；

第五个就是我们国家最初几十年的开放以适应国际经济规则为主，用国际经济规则、国际惯例倒逼国内营商环境改革、改善，倒逼国内的各种机制体制变化，是用开放倒逼改革的这样一个过程。

2012年以后我们每年退休的人员平均在1500万人左右，但每年能够上岗的劳动力，不管农村的、城市的，新生的劳动力是1200万左右。实际最近五年，我们每年少了300万劳动力补充。

本来GDP应该每掉1个点退出200万就业人口。为什么几年下来没有感觉到有500万、1000万下岗工人出现呢？就是因为人口出现了对冲性均衡，正好这边下降，要退出人员，跟那边补充的人员不足，形成了平衡，所以实际上我们基础性劳动力条件发生了变化，人口红利逐步退出。

如果一个国家在五到十年里，连续都是世界第一、第二、第三的进口大国，那一定成为世界经济的强国。要知道进口大国是和经济强国连在一起的，美国是世界第一大进口国，它也理所当然是世界最大的经济强国。

中美贸易战

关于中国加入WTO，莱特希泽有五个观点：一是中国入世美国吃亏论；二是中国没有兑现入世承诺；三是中国强制美国企业转让技术；四是中国的巨额外汇顺差造成了美国2008年的金融危机；五是中国买了大量美国国债，操纵了汇率。

2008年美国金融危机原因是2001年科技互联网危机后，当时股市一年里跌了50%以上，再加上“9·11”事件，美国政府一是降息，从6%降到1%，二是采取零按揭刺激房地产，三是将房地产次贷在资本市场1∶20加杠杆搞CDS，最终导致泡沫经济崩盘。2007年，美国房地产总市值24.3万亿美元、占GDP比重达到173%；股市总市值达到了20万亿美元、占GDP比重达到135%。2008年金融危机后，美国股市缩水50%，剩下10万亿美元左右；房地产总市值缩水40%，从2008年的25万亿美元下降到2009年的15万亿美元。

一个成熟的经济体，政府每年总有占GDP　20%—30%的财政收入要支出使用，通常会生成15%左右的GDP，这部分国有经济产生的GDP是通过政府的投资和消费产生的，美国和欧洲各国都是如此。比如2017年，美国的GDP中有13.5%是美国政府财力支出形成的GDP。中国政府除了财政税收以外，还有土地批租等预算外收入，所以，中国政府财力支出占GDP的比重相对高一点，占17%左右

自1971年布雷顿森林体系解体，美元脱离了金本位，形成“无锚货币”，美元的货币发行体制转化为政府发债，美联储购买发行基础货币之后，全球的基础货币总量如脱缰野马，快速增长。从1970年不到1000亿美元，到1980年的3500亿美元，到1990年的7000亿美元，到2000年的1.5万亿美元，到2008年的4万亿美元，到2017年的21万亿美元。其中，美元的基础货币也从20世纪70年代的几百亿美元发展到今天的6万亿美元。

报告还预计，截至2021财年底，美国联邦公共债务将达23万亿美元，约占美国GDP的103%；到2031财年，美国联邦公共债务占GDP的比重将进一步升至106%。Jul 2, 2021

image-20210729172410379

以下资料来源：https://pdf.dfcfw.com/pdf/H3_AP202106171498408427_1.pdf?1623944100000.pdf

image-20210729172820145

image-20210729173011549

image-20210729173116617

2020-01

上市公司几千家，几十家金融企业每年利润几乎占了几千家实体经济企业利润的50%，这个比重太高，造成我们脱实向虚。三是金融企业占GDP的比重是百分之八点几，是全世界最高的。世界平均金融业GDP占全球GDP的5%左右，欧洲也好、美国也好、日本也好，只要一到7%、8%，就会冒出一场金融危机，自己消除坏账后萎缩到5%、6%，过了几年，又扩张达到7%、8%，又崩盘。

SWIFT 是 Society for Worldwide Interbank Financial Telecommunications 的缩写，翻译成中文叫做「环球银行金融电讯协会」。看名字就知道，他是个搞通讯的，还冠冕堂皇的是一个非盈利性组织。

另外，SWIFT 官网上是这么用中文介绍自己的：SWIFT 为社群提供报文传送平台和通信标准，并在连接、集成、身份识别、数据分析和合规等领域的产品和服务（我一字未改，这多语言做的……语句都不通顺，好在不影响理解）；用英文则是这么介绍的：SWIFT is a global member-owned cooperative and the world’s leading provider of secure financial messaging services。

TCP

TCP相关参数解释

TCP相关参数解释

读懂TCP参数前得先搞清楚内核中出现的HZ、Tick、Jiffies三个值是什么意思

HZ

它可以理解为1s，所以120*HZ就是120秒，HZ/5就是200ms。

HZ表示CPU一秒种发出多少次时间中断–IRQ-0，Linux中通常用HZ来做时间片的计算（参考）。

这个值在内核编译的时候可设定100、250、300或1000，一般设置的是1000

1
2
3
#cat /boot/config-`uname -r` |grep 'CONFIG_HZ='
CONFIG_HZ=1000 //一般默认1000, Linux核心每隔固定周期会发出timer interrupt (IRQ 0)，HZ是用来定义
每一秒有几次timer interrupts。举例来说，HZ为1000，代表每秒有1000次timer interrupts

HZ的设定：
#make menuconfig
processor type and features—>Timer frequency (250 HZ)—>

HZ的不同值会影响timer （节拍）中断的频率

Tick

Tick是HZ的倒数，意即timer interrupt每发生一次中断的间隔时间。如HZ为250时，tick为4毫秒(millisecond)。

Jiffies

Jiffies为Linux核心变数(32位元变数，unsigned long)，它被用来记录系统自开机以来，已经过多少的tick。每发生一次timer interrupt，Jiffies变数会被加一。值得注意的是，Jiffies于系统开机时，并非初始化成零，而是被设为-300*HZ (arch/i386/kernel/time.c)，即代表系统于开机五分钟后，jiffies便会溢位。那溢出怎么办?事实上，Linux核心定义几个macro(timer_after、time_after_eq、time_before与time_before_eq)，即便是溢位，也能藉由这几个macro正确地取得jiffies的内容。

另外，80x86架构定义一个与jiffies相关的变数jiffies_64 ，此变数64位元，要等到此变数溢位可能要好几百万年。因此要等到溢位这刻发生应该很难吧。那如何经由jiffies_64取得jiffies呢?事实上，jiffies被对应至jiffies_64最低的32位元。因此，经由jiffies_64可以完全不理会溢位的问题便能取得jiffies。

数据取自于4.19内核代码中的 include/net/tcp.h

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
//rto的定义，不让修改，到每个ip的rt都不一样，必须通过rtt计算所得, HZ 一般是1000
#define TCP_RTO_MAX     ((unsigned)(120*HZ))
#define TCP_RTO_MIN     ((unsigned)(HZ/5)) //在rt很小的环境中计算下来RTO基本等于TCP_RTO_MIN

/* Maximal number of ACKs sent quickly to accelerate slow-start. */
#define TCP_MAX_QUICKACKS       16U //默认前16个ack必须quick ack来加速慢启动

//默认delay ack不能超过200ms
#define TCP_DELACK_MAX  ((unsigned)(HZ/5))  /* maximal time to delay before sending an ACK */
#if HZ >= 100
//默认 delay ack 40ms，不能修改和关闭
#define TCP_DELACK_MIN  ((unsigned)(HZ/25))     /* minimal time to delay before sending an ACK */
#define TCP_ATO_MIN     ((unsigned)(HZ/25))
#else
#define TCP_DELACK_MIN  4U
#define TCP_ATO_MIN     4U
#endif

#define TCP_SYNQ_INTERVAL       (HZ/5)  /* Period of SYNACK timer */
#define TCP_KEEPALIVE_TIME      (120*60*HZ)     /* two hours */
#define TCP_KEEPALIVE_PROBES    9               /* Max of 9 keepalive probes    */
#define TCP_KEEPALIVE_INTVL     (75*HZ)

/* cwnd init 默认大小是10个拥塞窗口，也可以通过sysctl_tcp_init_cwnd来设置，要求内核编译的时候支持*/
#if IS_ENABLED(CONFIG_TCP_INIT_CWND_PROC)
extern u32 sysctl_tcp_init_cwnd;
/* TCP_INIT_CWND is rvalue */
#define TCP_INIT_CWND           (sysctl_tcp_init_cwnd + 0)
#else
/* TCP initial congestion window as per rfc6928 */
#define TCP_INIT_CWND           10
#endif

/* Flags in tp->nonagle 默认nagle算法关闭的*/
#define TCP_NAGLE_OFF           1       /* Nagle's algo is disabled */
#define TCP_NAGLE_CORK          2       /* Socket is corked         */
#define TCP_NAGLE_PUSH          4       /* Cork is overridden for already queued data */

//对应time_wait, alios 增加了tcp_tw_timeout 参数可以来设置这个值，当前网络质量更好了这个值可以减小一些
#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
                                  * state, about 60 seconds     */
                                  
#define TCP_SYN_RETRIES  6      /* This is how many retries are done
                                 * when active opening a connection.
                                 * RFC1122 says the minimum retry MUST
                                 * be at least 180secs.  Nevertheless
                                 * this value is corresponding to
                                 * 63secs of retransmission with the
                                 * current initial RTO.
                                 */

#define TCP_SYNACK_RETRIES 5    /* This is how may retries are done
                                 * when passive opening a connection.
                                 * This is corresponding to 31secs of
                                 * retransmission with the current
                                 * initial RTO.
                                 */

rto 不能设置，而是根据到不同server的rtt计算得到，即使RTT很小（比如0.8ms），但是因为RTO有下限，最小必须是200ms，所以这是RTT再小也白搭；RTO最小值是内核编译是决定的，socket程序中无法修改，Linux TCP也没有任何参数可以改变这个值。

delay ack

正常情况下ack可以quick ack也可以delay ack，redhat在sysctl中可以设置这两个值

/proc/sys/net/ipv4/tcp_ato_min

默认都是推荐delay ack的，一定要修改成quick ack的话（3.10.0-327之后的内核版本）：

1
2
3
4
5
6
7
8
9
10
11
$sudo ip route show
default via 10.0.207.253 dev eth0 proto dhcp src 10.0.200.23 metric 1024
10.0.192.0/20 dev eth0 proto kernel scope link src 10.0.200.23
10.0.207.253 dev eth0 proto dhcp scope link src 10.0.200.23 metric 1024

$sudo ip route change default via 10.0.207.253  dev eth0 proto dhcp src 10.0.200.23 metric 1024 quickack 1

$sudo ip route show
default via 10.0.207.253 dev eth0 proto dhcp src 10.0.200.23 metric 1024 quickack 1
10.0.192.0/20 dev eth0 proto kernel scope link src 10.0.200.23
10.0.207.253 dev eth0 proto dhcp scope link src 10.0.200.23 metric 1024

默认开启delay ack的抓包情况如下，可以清晰地看到有几个40ms的ack

image.png

第一个40ms 的ack对应的包， 3306收到 update请求后没有ack，而是等了40ms update也没结束，就ack了

image.png

同样的机器，执行quick ack后的抓包

sudo ip route change default via 10.0.207.253 dev eth0 proto dhcp src 10.0.200.23 metric 1024 quickack 1

image.png

同样场景下，改成quick ack后基本所有的ack都在0.02ms内发出去了。

比较奇怪的是在delay ack情况下不是每个空ack都等了40ms，这么多包只看到4个delay了40ms，其它的基本都在1ms内就以空包就行ack了。

将 quick ack去掉后再次抓包仍然抓到了很多的40ms的ack。

Java中setNoDelay是指关掉nagle算法，但是delay ack还是存在的。

C代码中关闭的话：At the application level with the TCP_QUICKACK socket option. See man 7 tcp for further details. This option needs to be set with setsockopt() after each operation of TCP on a given socket

连接刚建立前16个包一定是quick ack的，目的是加快慢启动

一旦后面进入延迟ACK模式后，如果接收的还没有回复ACK确认的报文总大小超过88bytes的时候就会立即回复ACK报文。

参考资料

https://access.redhat.com/solutions/407743

https://www.cnblogs.com/lshs/p/6038635.html

performance

存储原理

存储原理

本文记录各种存储、接口等原理性东西

img

img

磁盘信息

Here are some common ones:

  • hdX — ATA hard disk, pre-libata. You’ll only see this with old distros (probably based on Linux 2.4.x or older)
  • sdX — “SCSI” hard disk. Also includes SATA and SAS. And IDE disks using libata (on any recent distro).
  • hdXY, sdXY — Partition on the hard disk hdX or sdX.
  • loopX — Loopback device, used for mounting disk images, etc.
  • loopXpY — Partitions on the loopback device loopX; used when mounting an image of a complete hard drive, etc.
  • scdX, srX — “SCSI” CD, using same weird definition of “SCSI”. Also includes DVD, Blu-ray, etc.
  • mdX — Linux MDraid
  • dm-X — Device Mapper. Use -N to see what these are, or ls -l /dev/mapper. Device Mapper underlies LVM2 and dm-crypt. If you’re using either LVM or encrypted volumes, you’ll see dm-X devices.

回顾串行磁盘技术的发展历史，从光纤通道，到SATA，再到SAS，几种技术各有所长。光纤通道最早出现的串行化存储技术，可以满足高性能、高可靠和高扩展性的存储需要，但是价格居高不下；SATA硬盘成本倒是降下来了，但主要是用于近线存储和非关键性应用，毕竟在性能等方面差强人意；SAS应该算是个全才，可以支持SAS和SATA磁盘，很方便地满足不同性价比的存储需求，是具有高性能、高可靠和高扩展性的解决方案。

SSD中，SATA、m2、PCIE和NVME各有什么意义

高速信号协议

SAS，SATA，PCIe 这三个是同一个层面上的，模拟串行高速接口。

  • SAS 对扩容比较友好，也支持双控双活。接上SAS RAID 卡，一般在阵列上用的比较多。
  • SATA 对热插拔很友好，早先台式机装机市场的 SSD基本上都是SATA的，现在的 机械硬盘也是SATA接口居多。但速率上最高只能到 6Gb/s，上限 768MB/s左右，现在已经慢慢被pcie取代。
  • PCIe 支持速率更高，也离CPU最近。很多设备 如 网卡，显卡也都走pcie接口，当然也有SSD。现在比较主流的是PCIe 3.0,8Gb/s 看起来好像也没比 SATA 高多少，但是 PCIe 支持多个LANE，每个LANE都是 8Gb/s，这样性能就倍数增加了。目前，SSD主流的是 PCIe 3.0x4 lane，性能可以做到 3500MB/s 左右。

传输层协议

SCSI，ATA，NVMe 都属于这一层。主要是定义命令集，数字逻辑层。

  • SCSI 命令集 历史悠久，应用也很广泛。U盘，SAS 盘，还有手机上 UFS 之类很多设备都走的这个命令集。
  • ATA 则只是跑在SATA 协议上
  • NVMe 协议是有特意为 NAND 进行优化。相比于上面两者，效率更高。主要是跑在 PCIe 上的。当然，也有NVMe-MI，NVMe-of之类的。是个很好的传输层协议。

NVMe（Non-Volatile Memory Express）

NVMe其实与AHCI一样都是逻辑设备接口标准（是接口标准，并不是接口），NVMe全称Non-Volatile Memory Express，非易失性存储器标准，是使用PCI-E通道的SSD一种规范，NVMe的设计之初就有充分利用到PCI-E SSD的低延时以及并行性，还有当代处理器、平台与应用的并行性。SSD的并行性可以充分被主机的硬件与软件充分利用，相比与现在的AHCI标准，NVMe标准可以带来多方面的性能提升。

NVMe标准是面向PCI-E SSD的，使用原生PCI-E通道与CPU直连可以免去SATA与SAS接口的外置控制器（PCH）与CPU通信所带来的延时。而在软件层方面，NVMe标准的延时只有AHCI的一半不到，NVMe精简了调用方式，执行命令时不需要读取寄存器；而AHCI每条命令则需要读取4次寄存器，一共会消耗8000次CPU循环，从而造成大概2.5微秒的延迟。

NVMe标准和传统的SATA/SAS相比，一个重大的差别是引入了多队列机制。

主机与SSD进行数据交互采用“生产者-消费者”模型进行数据交互。在原有AHCI规范中，只定义了一个交互队列，主机与HDD之间的数据交互只能通过一个队列通信，多核处理器也只能通过一个队列与HDD进行数据交互。在传统磁盘存储时代，单队列在一个IO调度器，可以很好的保证提交请求的IO顺序最优化。

而NAND存储介质具有很高的性能，AHCI原有的规范不再适用，NVMe规范替代了原有的AHCI规范，在软件层面的处理命令也进行了重新定义，不再采用SCSI／ATA命令规范集。相比以前AHCI、SAS等协议规范，NVMe规范是一种非常简化，面向新型存储介质的协议规范。该规范将存储外设拉到了处理器局部总线上，性能大为提升。并且主机和SSD处理器之间采用多队列的设计，适应了多核的发展趋势，每个处理器核与SSD之间可以采用独立的硬件Queue Pair进行数据交互。

img

如上图从软件的角度来看，每个CPU Core都可以创建一对Queue Pair和SSD进行数据交互。Queue Pair由Submission Queue与Completion Queue构成，通过Submission queue发送数据；通过Completion queue接受完成事件。SSD硬件和主机驱动软件控制queue的Head与Tail指针完成双方的数据交互。

nvme多队列

img

img

物理接口

M.2 , U.2 , AIC, NGFF 这些属于物理接口

像 M.2 可以是 SATA SSD 也可以是 NVMe（PCIe） SSD。金手指上有一个 SATA/PCIe 的选择信号，来区分两者。很多笔记本的M.2 接口也是同时支持两种类型的盘的。

  • M.2 , 主要用在 笔记本上，优点是体积小，缺点是散热不好。
  • U.2,主要用在 数据中心或者一些企业级用户，对热插拔需求高的地方。优点热插拔，散热也不错。一般主要是pcie ssd(也有sas ssd)，受限于接口，最多只能是 pcie 4lane
  • AIC，企业，行业用户用的比较多。通常会支持pcie 4lane/8lane，带宽上限更高

SSD 的性能特性和机制

SSD 的内部工作方式和 HDD 大相径庭，我们先了解几个概念。

单元（Cell）、页面（Page）、块（Block）。

当今的主流 SSD 是基于 NAND 的，它将数字位存储在单元中。每个 SSD 单元可以存储一位或多位。对单元的每次擦除都会降低单元的寿命，所以单元只能承受一定数量的擦除。单元存储的位数越多，制造成本就越低，SSD 的容量也就越大，但是耐久性（擦除次数）也会降低。

一个页面包括很多单元，典型的页面大小是 4KB，页面也是要读写的最小存储单元。SSD 上没有“重写”操作，不像 HDD 可以直接对任何字节重写覆盖。一个页面一旦写入内容后就不能进行部分重写，必须和其它相邻页面一起被整体擦除重置。

多个页面组合成块。一个块(Block)的典型大小为 512KB 或 1MB，也就是大约 128 或 256 (Page–16KB)页。块是擦除的基本单位，每次擦除都是整个块内的所有页面都被重置。

image-20210915090731401

擦除速度相对很慢，通常为几毫秒。所以对同步的 IO，发出 IO 的应用程序可能会因为块的擦除，而经历很大的写入延迟。为了尽量地减少这样的场景，保持空闲块的阈值对于快速的写响应是很有必要的。SSD 的垃圾回收（GC）的目的就在于此。GC 可以回收用过的块，这样可以确保以后的页写入可以快速分配到一个全新的页。

SSD的基本结构：

image-20210915090459823

比如Intel P4510 SSD控制器内部集成了两个Cotex A15 ARM core，这两个CPU core各自处理50%物理地址空间的读写命令（不同CPU负责不同的Die，以提高并发度）。在处理IO命令的过程中，为了充分发挥两个cpu的并行处理效率，每个cpu core单次处理的最大数据块是128kB。所以P4510对于128k对齐（4k，8k，16k，32k，64k，128k）或者128k整数倍（256k，512k，1024k）的数据块的处理效率最高。因为这些数据块都能够在SSD内部被组装或者拆分为完整的128k数据块。但是，对于非128k对齐的数据块（68k，132k，260k，516k，1028k），由于每个提交给SSD的写命令都有一个非128k对齐的“尾巴”需要跨CPU来处理，这样便会导致SSD处理单个命令的效率下降，写带宽随之也下降。

imgimg

SSD内部使用写缓存。写缓存主要用来降低写延迟。当写请求发送给SSD时，写数据会被先保存在写缓存，此时SSD会直接发送确认消息通知主机端写请求已完成，实现最低的写延迟。SSD固件在后台会异步的定期把写缓存中的数据通过写操作命令刷回给NAND颗粒。为了满足写操作的持久化语义，SSD内有大容量电容保证写缓存中数据的安全。当紧急断电情况发生时，固件会及时把写缓存中的数据写回NAND颗粒. 也就是紧急断电后还能通过大电容供电来维持最后的落盘。

SSD内嵌内存容量的问题也限制了大容量NVMe SSD的发展，为了解决内存问题，目前一种可行的方法是增大sector size。标准NVMe SSD的sector size为4KB，为了进一步增大NVMe SSD的容量，有些厂商已经开始采用16KB的sector size。16KB Sector size的普及应用，会加速大容量NVMe SSD的推广。

以海康威视E200P为例，PCB上的硬件PLP掉电保护电路从D200Pro的10个钽电容+6个电感，简化为6个钽电容+6个电感。钽电容来自Panasonic，单颗47uF，6个钽电容并联可以为SSD提供几十毫秒的放电时间，让SSD把处理中的数据写入NAND中并更新映射表。这样的硬件PLP电路对比普通的家用产品要强悍很多。

img

SSD存储持久化原理

记录一个比特很容易理解。给电容里面充上电有电压的时候就是 1，给电容放电里面没有电就是 0。采用这样方式存储数据的 SSD 硬盘，我们一般称之为使用了 SLC 的颗粒，全称是 Single-Level Cell，也就是一个存储单元中只有一位数据。

但是，这样的方式会遇到和 CPU Cache 类似的问题，那就是，同样的面积下，能够存放下的元器件是有限的。如果只用 SLC，我们就会遇到，存储容量上不去，并且价格下不来的问题。于是呢，硬件工程师们就陆续发明了 MLC（Multi-Level Cell）、TLC（Triple-Level Cell）以及 QLC（Quad-Level Cell），也就是能在一个电容里面存下 2 个、3 个乃至 4 个比特。

只有一个电容，我们怎么能够表示更多的比特呢？别忘了，这里我们还有一个电压计。4 个比特一共可以从 0000-1111 表示 16 个不同的数。那么，如果我们能往电容里面充电的时候，充上 15 个不同的电压，并且我们电压计能够区分出这 15 个不同的电压。加上电容被放空代表的 0，就能够代表从 0000-1111 这样 4 个比特了。

不过，要想表示 15 个不同的电压，充电和读取的时候，对于精度的要求就会更高。这会导致充电和读取的时候都更慢，所以 QLC 的 SSD 的读写速度，要比 SLC 的慢上好几倍。

SSD对碎片很敏感，类似JVM的内存碎片需要整理，碎片整理就带来了写入放大。也就是写入空间不够的时候需要先进行碎片整理、搬运，这样写入的数据更大了。

SSD寿命：以Intel 335为例再来算一下，BT用户可以用600TB × 1024 / 843 = 728天，普通用户可以用600TB/2 = 300年！情况十分乐观

两种逻辑门

NAND(NOT-AND) gate

NOR(NOT-OR) gate

如上两种门实现的介质都是非易失存储介质，在写入前都需要擦除。实际上NOR Flash的一个bit可以从1变成0，而要从0变1就要擦除整块。NAND flash都需要擦除。

NAND Flash NOR Flash
芯片容量 <32GBit <1GBit
访问方式 块读写（顺序读写） 随机读写
接口方式 任意I/O口 特定完整存储器接口
读写性能 读取快（顺序读） 写入快 擦除快（可按块擦除） 读取快（RAM方式） 写入慢 檫除很慢
使用寿命 百万次 十万次
价格 低廉 高昂

NAND Flash更适合在各类需要大数据的设备中使用，如U盘、SSD、各种存储卡、MP3播放器等，而NOR Flash更适合用在高性能的工业产品中。

高端SSD会选取MLC（Multi-Level Cell）甚至SLC（Single-Level Cell），低端SSD则选取 TLC（Triple-Level Cell）。SD卡一般选取 TLC（Triple-Level Cell）

image-20210603161822079

image-20220105201724752

slc-mlc-tlc-buckets

umlc

image-20220105201749003

NOR FLash主要用于：Bios、机顶盒，大小一般是1-32MB

对于TLC NAND （每个NAND cell存储3 bits的信息），下面列出了每种操作的典型耗时的范围：

​ 读操作（Tread） ： 50-100us，

​ 写操作（Tprog） ： 500us-5ms，

​ 擦除操作（Terase） ： 2-10ms。

为什么断电后SSD不丢数据

SSD的存储硬件都是NAND Flash。实现原理和通过改变电压，让电子进入绝缘层的浮栅(Floating Gate)内。断电之后，电子仍然在FG里面。但是如果长时间不通电，比如几年，仍然可能会丢数据。所以换句话说，SSD的确也不适合作为冷数据备份。比如标准要求SSD：温度在30度的情况下，数据要能保持52周。

写入放大（Write Amplification, or WA)

这是 SSD 相对于 HDD 的一个缺点，即实际写入 SSD 的物理数据量，有可能是应用层写入数据量的多倍。一方面，页级别的写入需要移动已有的数据来腾空页面。另一方面，GC 的操作也会移动用户数据来进行块级别的擦除。所以对 SSD 真正的写操作的数据可能比实际写的数据量大，这就是写入放大。一块 SSD 只能进行有限的擦除次数，也称为编程 / 擦除（P/E）周期，所以写入放大效用会缩短 SSD 的寿命。

SSD 的读取和写入的基本单位，不是一个比特（bit）或者一个字节（byte），而是一个页（Page）。SSD 的擦除单位就更夸张了，我们不仅不能按照比特或者字节来擦除，连按照页来擦除都不行，我们必须按照块来擦除。

SLC 的芯片，可以擦除的次数大概在 10 万次，MLC 就在 1 万次左右，而 TLC 和 QLC 就只在几千次了。这也是为什么，你去购买 SSD 硬盘，会看到同样的容量的价格差别很大，因为它们的芯片颗粒和寿命完全不一样。

从本质上讲，NAND Flash是一种不可靠介质，非常容易出现Bit翻转问题。SSD通过控制器和固件程序将这种不可靠的NAND Flash变成了可靠的数据存储介质。

为了在这种不可靠介质上构建可靠存储，SSD内部做了大量工作。在硬件层面，需要通过ECC单元解决经常出现的比特翻转问题。每次数据存储的时候，硬件单元需要为存储的数据计算ECC校验码；在数据读取的时候，硬件单元会根据校验码恢复被破坏的bit数据。ECC硬件单元集成在SSD控制器内部，代表了SSD控制器的能力。在MLC存储时代，BCH编解码技术可以解决问题，4KB数据中存在100bit翻转时可以纠正错误；在TLC存储时代，bit错误率大为提升，需要采用更高纠错能力的LDPC编解码技术，在4KB出现550bit翻转时，LDPC硬解码仍然可以恢复数据。对比LDPC硬解码、BCH以及LDPC软解码之间的能力，可以看出LDPC软解码具有更强的纠错能力，通常使用在硬解码失效的情况下。LDPC软解码的不足之处在于增加了IO的延迟。

在软件层面，SSD内部设计了FTL（Flash Translation Layer），该软件层的设计思想和Log-Structured File System设计思想类似。采用log追加写的方式记录数据，采用LBA至PBA的地址映射表记录数据组织方式。Log-structured系统最大的一个问题就是垃圾回收(GC)。因此，虽然NAND Flash本身具有很高的IO性能，但受限于GC的影响，SSD层面的性能会大受影响，并且存在十分严重的IO QoS问题，这也是目前标准NVMe SSD一个很重要的问题。

耗损平衡 (Wear Leveling)

对每一个块而言，一旦达到最大数量，该块就会死亡。对于 SLC 块，P/E 周期的典型数目是十万次；对于 MLC 块，P/E 周期的数目是一万；而对于 TLC 块，则可能是几千。为了确保 SSD 的容量和性能，我们需要在擦除次数上保持平衡，SSD 控制器具有这种“耗损平衡”机制可以实现这一目标。在损耗平衡期间，数据在各个块之间移动，以实现均衡的损耗，这种机制也会对前面讲的写入放大推波助澜。

non-volatile memory (NVM)

NVM是一种新型的硬件存储介质，同时具备磁盘和DRAM的一些特性。突出的NVM技术产品有：PC-RAM、STT-RAM和R-RAM。因为NVM具有设备层次上的持久性，所以不需要向DRAM一样的刷新周期以维持数据状态。因此NVM和DRAM相比，每bit耗费的能量更少。另外，NVM比硬盘有更小的延迟，读延迟甚至和DRAM相当；字节寻址；比DRAM密度更大。

1、NVM特性

数据访问延迟：NVM的读延迟比磁盘小很多。由于NVM仍处于开发阶段，来源不同延迟不同。STT-RAM的延迟1-20ns。尽管如此，他的延迟也已经非常接近DRAM了。

PC_RAM 和R-RAM的写延迟比DRAM高。但是写延迟不是很重要，因为可以通过buffer来缓解。

密度：NVM的密度比DRAM高，可以作为主存的替代品，尤其是在嵌入式系统中。例如，相对于DRAM，PC-RAM提供2到4倍的容量，便于扩展。

耐久性：即每个内存单元写的最大次数。最具竞争性的是PC-RAM和STT-RAM，提供接近DRAM的耐久性。更精确的说，NVM的耐久性是1015而DRAM是1016。另外，NVM比闪存技术的耐久性更大。

能量消耗：NVM不需要像DRAM一样周期性刷写以维护内存中数据，所以消耗的能量更少。PC-RAM比DRAM消耗能量显著的少，其他比较接近。

此外，还有字节寻址、持久性。Interl和Micron已经发起了3D XPoint技术，同时Interl开发了新的指令以支持持久内存的使用。

磁盘类型查看

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
$cat /sys/block/vda/queue/rotational
1  //1表示旋转，非ssd，0表示ssd
or
lsblk -d -o name,rota,size,label,uuid

SATA SSD测试数据
# cat /sys/block/sda/queue/rotational 
0
# lsblk -d -o name,rota
NAME     ROTA
sda         0
sfdv0n1     0

ESSD磁盘测试用一块虚拟的阿里云网络盘，不能算完整意义的SSD（承诺IOPS 4200），数据仅供参考，磁盘概况：
$df -lh
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        99G   30G   65G  32% /

$cat /sys/block/vda/queue/rotational
1

fio 结果解读

slat，异步场景下才有

其中slat指的是发起IO的时间，在异步IO模式下，发起IO以后，IO会异步完成。例如调用一个异步的write，虽然write返回成功了，但是IO还未完成，slat约等于发起write的耗时；

slat (usec): min=4, max=6154, avg=48.82, stdev=56.38： The first latency metric you’ll see is the ‘slat’ or submission latency. It is pretty much what it sounds like, meaning “how long did it take to submit this IO to the kernel for processing?”

clat

clat指的是完成时间，从发起IO后到完成IO的时间，在同步IO模式下，clat是指整个写动作完成时间

lat

lat是总延迟时间，指的是IO单元创建到完成的总时间，通常这项数据关注较多。同步场景几乎等于clat，异步场景等于clat+slat
这项数据需要关注的是max，看看有没有极端的高延迟IO；另外还需要关注stdev，这项数据越大说明，IO响应时间波动越大，反之越小，波动越小

clat percentiles (usec)：处于某个百分位的io操作时延

cpu : usr=9.11%, sys=57.07%, ctx=762410, majf=0, minf=1769 //用户和系统的CPU占用时间百分比，线程切换次数，major以及minor页面错误的数量。

SSD的direct和buffered似乎很奇怪，应该是direct=0性能更好，实际不是这样，这里还需要找资料求证下

  • direct``=bool

    If value is true, use non-buffered I/O. This is usually O_DIRECT. Note that OpenBSD and ZFS on Solaris don’t support direct I/O. On Windows the synchronous ioengines don’t support direct I/O. Default: false.

  • buffered``=bool

    If value is true, use buffered I/O. This is the opposite of the direct option. Defaults to true.

iostat 结果解读

Dm-0就是lvm

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.32    0.00    3.34    0.13    0.00   96.21

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00    11.40   66.00    7.20  1227.20    74.40    35.56     0.03    0.43    0.47    0.08   0.12   0.88
nvme0n1           0.00  8612.00    0.00 51749.60     0.00 241463.20     9.33     4.51    0.09    0.00    0.09   0.02  78.56
dm-0              0.00     0.00    0.00 60361.80     0.00 241463.20     8.00   152.52    2.53    0.00    2.53   0.01  78.26

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.36    0.00    3.46    0.17    0.00   96.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     8.80    9.20    5.20  1047.20    67.20   154.78     0.01    0.36    0.46    0.19   0.33   0.48
nvme0n1           0.00 11354.20    0.00 50876.80     0.00 248944.00     9.79     5.25    0.10    0.00    0.10   0.02  80.06
dm-0              0.00     0.00    0.00 62231.00     0.00 248944.80     8.00   199.49    3.21    0.00    3.21   0.01  78.86

avgqu_sz，是iostat的一项比较重要的数据。如果队列过长，则表示有大量IO在处理或等待，但是这还不足以说明后端的存储系统达到了处理极限。例如后端存储的并发能力是4096，客户端并发发送了256个IO下去，那么队列长度就是256。即使长时间队列长度是256，也不能说明什么，仅仅表明队列长度是256，有256个IO在处理或者排队。

那么怎么判断IO是在调度队列排队等待，还是在设备上处理呢？iostat有两项数据可以给出一个大致的判断。svctime，这项数据的指的是IO在设备处理中耗费的时间。另外一项数据await，指的是IO从排队到完成的时间，包括了svctime和排队等待的时间。那么通过对比这两项数据，如果两项数据差不多，则说明IO基本没有排队等待，耗费的时间都是设备处理。如果await远大于svctime，则说明有大量的IO在排队，并没有发送给设备处理。

rq_affinity

参考aliyun测试文档 , rq_affinity增加2的commit： git show 5757a6d76c

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
function RunFio
{
 numjobs=$1   # 实例中的测试线程数，例如示例中的10
 iodepth=$2   # 同时发出I/O数的上限，例如示例中的64
 bs=$3        # 单次I/O的块文件大小，例如示例中的4k
 rw=$4        # 测试时的读写策略，例如示例中的randwrite
 filename=$5  # 指定测试文件的名称，例如示例中的/dev/your_device
 nr_cpus=`cat /proc/cpuinfo |grep "processor" |wc -l`
 if [ $nr_cpus -lt $numjobs ];then
     echo “Numjobs is more than cpu cores, exit!”
     exit -1
 fi
 let nu=$numjobs+1
 cpulist=""
 for ((i=1;i<10;i++))
 do
     list=`cat /sys/block/your_device/mq/*/cpu_list | awk '{if(i<=NF) print $i;}' i="$i" | tr -d ',' | tr '\n' ','`
     if [ -z $list ];then
         break
     fi
     cpulist=${cpulist}${list}
 done
 spincpu=`echo $cpulist | cut -d ',' -f 2-${nu}`
 echo $spincpu
 fio --ioengine=libaio --runtime=30s --numjobs=${numjobs} --iodepth=${iodepth} --bs=${bs} --rw=${rw} --filename=${filename} --time_based=1 --direct=1 --name=test --group_reporting --cpus_allowed=$spincpu --cpus_allowed_policy=split
}
echo 2 > /sys/block/your_device/queue/rq_affinity
sleep 5
RunFio 10 64 4k randwrite filename

对NVME SSD进行测试，左边rq_affinity是2，右边rq_affinity为1，在这个测试参数下rq_affinity为1的性能要好(后许多次测试两者性能差不多)

image-20210607113709945

参考资料

http://cizixs.com/2017/01/03/how-slow-is-disk-and-network

https://tobert.github.io/post/2014-04-17-fio-output-explained.html

https://zhuanlan.zhihu.com/p/40497397

块存储NVMe云盘原型实践

机械硬盘随机IO慢的超乎你的想象

搭载固态硬盘的服务器究竟比搭机械硬盘快多少？

SSD基本工作原理

SSD原理解读

Backblaze 的 2021 年硬盘死亡報告

performance

ssd/san/sas 磁盘 光纤性能比较

ssd/san/sas 磁盘 光纤性能比较

正好有机会用到一个san存储设备，跑了一把性能数据，记录一下

image.png

所使用的测试命令：

1
fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/data/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60

ssd（Solid State Drive）和san的比较是在同一台物理机上，所以排除了其他因素的干扰。

简要的结论：

  • 本地ssd性能最好、sas机械盘(RAID10)性能最差

  • san存储走特定的光纤网络，不是走tcp的san（至少从网卡看不到san的流量），性能居中

  • 从rt来看 ssd:san:sas 大概是 1:3:15

  • san比本地sas机械盘性能要好，这也许取决于san的网络传输性能和san存储中的设备（比如用的ssd而不是机械盘）

NVMe SSD 和 HDD的性能比较

image.png

表中性能差异比上面测试还要大，SSD 的随机 IO 延迟比传统硬盘快百倍以上，一般在微妙级别；IO 带宽也高很多倍，可以达到每秒几个 GB；随机 IOPS 更是快了上千倍，可以达到几十万。

HDD只有一个磁头，并发没有意义，但是SSD支持高并发写入读取。SSD没有磁头、不需要旋转，所以随机读取和顺序读取基本没有差别。

SSD 的性能特性和机制

SSD 的内部工作方式和 HDD 大相径庭，我们先了解几个概念。

单元（Cell）、页面（Page）、块（Block）。当今的主流 SSD 是基于 NAND 的，它将数字位存储在单元中。每个 SSD 单元可以存储一位或多位。对单元的每次擦除都会降低单元的寿命，所以单元只能承受一定数量的擦除。单元存储的位数越多，制造成本就越少，SSD 的容量也就越大，但是耐久性（擦除次数）也会降低。

一个页面包括很多单元，典型的页面大小是 4KB，页面也是要读写的最小存储单元。SSD 上没有“重写”操作，不像 HDD 可以直接对任何字节重写覆盖。一个页面一旦写入内容后就不能进行部分重写，必须和其它相邻页面一起被整体擦除重置。

多个页面组合成块。一个块的典型大小为 512KB 或 1MB，也就是大约 128 或 256 页。块是擦除的基本单位，每次擦除都是整个块内的所有页面都被重置。

擦除速度相对很慢，通常为几毫秒。所以对同步的 IO，发出 IO 的应用程序可能会因为块的擦除，而经历很大的写入延迟。为了尽量地减少这样的场景，保持空闲块的阈值对于快速的写响应是很有必要的。SSD 的垃圾回收（GC）的目的就在于此。GC 可以回收用过的块，这样可以确保以后的页写入可以快速分配到一个全新的页。

SSD原理

对于 SSD 硬盘，类似SRAM（CPU cache）它是由一个电容加上一个电压计组合在一起，记录了一个或者多个比特。能够记录一个比特很容易理解。给电容里面充上电有电压的时候就是 1，给电容放电里面没有电就是 0。采用这样方式存储数据的 SSD 硬盘，我们一般称之为使用了 SLC 的颗粒，全称是 Single-Level Cell，也就是一个存储单元中只有一位数据。

但是，这样的方式会遇到和 CPU Cache 类似的问题，那就是，同样的面积下，能够存放下的元器件是有限的。如果只用 SLC，我们就会遇到，存储容量上不去，并且价格下不来的问题。于是呢，硬件工程师们就陆续发明了 MLC（Multi-Level Cell）、TLC（Triple-Level Cell）以及 QLC（Quad-Level Cell），也就是能在一个电容里面存下 2 个、3 个乃至 4 个比特。

只有一个电容，我们怎么能够表示更多的比特呢？别忘了，这里我们还有一个电压计。4 个比特一共可以从 0000-1111 表示 16 个不同的数。那么，如果我们能往电容里面充电的时候，充上 15 个不同的电压，并且我们电压计能够区分出这 15 个不同的电压。加上电容被放空代表的 0，就能够代表从 0000-1111 这样 4 个比特了。

不过，要想表示 15 个不同的电压，充电和读取的时候，对于精度的要求就会更高。这会导致充电和读取的时候都更慢，所以 QLC 的 SSD 的读写速度，要比 SLC 的慢上好几倍。

SSD对碎片很敏感，类似JVM的内存碎片需要整理，碎片整理就带来了写入放大。也就是写入空间不够的时候需要先进行碎片整理、搬运，这样写入的数据更大了。

SSD寿命：以Intel 335为例再来算一下，BT用户可以用600TB × 1024 / 843 = 728天，普通用户可以用600TB/2 = 300年！情况十分乐观

两种逻辑门

NAND(NOT-AND) gate

NOR(NOT-OR) gate

如上两种门实现的介质都是非易失存储介质，在写入前都需要擦除。实际上NOR Flash的一个bit可以从1变成0，而要从0变1就要擦除整块。NAND flash都需要擦除。

NAND Flash NOR Flash
芯片容量 <32GBit <1GBit
访问方式 块读写（顺序读写） 随机读写
接口方式 任意I/O口 特定完整存储器接口
读写性能 读取快（顺序读） 写入快 擦除快（可按块擦除） 读取快（RAM方式） 写入慢 檫除很慢
使用寿命 百万次 十万次
价格 低廉 高昂

NAND Flash更适合在各类需要大数据的设备中使用，如U盘、SSD、各种存储卡、MP3播放器等，而NOR Flash更适合用在高性能的工业产品中。

高端SSD会选取MLC（Multi-Level Cell）甚至SLC（Single-Level Cell），低端SSD则选取 TLC（Triple-Level Cell）。SD卡一般选取 TLC（Triple-Level Cell）

image-20210603161822079

slc-mlc-tlc-buckets

NOR FLash主要用于：Bios、机顶盒，大小一般是1-32MB

为什么断电后SSD不丢数据

SSD的存储硬件都是NAND Flash。实现原理和通过改变电压，让电子进入绝缘层的浮栅(Floating Gate)内。断电之后，电子仍然在FG里面。但是如果长时间不通电，比如几年，仍然可能会丢数据。所以换句话说，SSD的确也不适合作为冷数据备份。

比如标准要求SSD：温度在30度的情况下，数据要能保持52周。

写入放大（Write Amplification, or WA)

这是 SSD 相对于 HDD 的一个缺点，即实际写入 SSD 的物理数据量，有可能是应用层写入数据量的多倍。一方面，页级别的写入需要移动已有的数据来腾空页面。另一方面，GC 的操作也会移动用户数据来进行块级别的擦除。所以对 SSD 真正的写操作的数据可能比实际写的数据量大，这就是写入放大。一块 SSD 只能进行有限的擦除次数，也称为编程 / 擦除（P/E）周期，所以写入放大效用会缩短 SSD 的寿命。

SSD 的读取和写入的基本单位，不是一个比特（bit）或者一个字节（byte），而是一个页（Page）。SSD 的擦除单位就更夸张了，我们不仅不能按照比特或者字节来擦除，连按照页来擦除都不行，我们必须按照块来擦除。

SLC 的芯片，可以擦除的次数大概在 10 万次，MLC 就在 1 万次左右，而 TLC 和 QLC 就只在几千次了。这也是为什么，你去购买 SSD 硬盘，会看到同样的容量的价格差别很大，因为它们的芯片颗粒和寿命完全不一样。

耗损平衡 (Wear Leveling)

对每一个块而言，一旦达到最大数量，该块就会死亡。对于 SLC 块，P/E 周期的典型数目是十万次；对于 MLC 块，P/E 周期的数目是一万；而对于 TLC 块，则可能是几千。为了确保 SSD 的容量和性能，我们需要在擦除次数上保持平衡，SSD 控制器具有这种“耗损平衡”机制可以实现这一目标。在损耗平衡期间，数据在各个块之间移动，以实现均衡的损耗，这种机制也会对前面讲的写入放大推波助澜。

磁盘类型查看

1
2
3
4
5
$cat /sys/block/vda/queue/rotational
1  //1表示旋转，非ssd，0表示ssd

或者
lsblk -d -o name,rota

fio测试

以下是两块测试的SSD磁盘测试前的基本情况

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
/dev/sda	240.06G  SSD_SATA  //sata
/dev/sfd0n1	3200G	 SSD_PCIE  //PCIE

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda3        49G   29G   18G  63% / 
/dev/sfdv0n1p1  2.0T  803G  1.3T  40% /data

# cat /sys/block/sda/queue/rotational 
0
# cat /sys/block/sfdv0n1/queue/rotational 
0

#测试前的iostat状态
# iostat -d sfdv0n1 sda3 1 -x
Linux 3.10.0-957.el7.x86_64 (nu4d01142.sqa.nu8) 	2021年02月23日 	_x86_64_	(104 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda3              0.00    10.67    1.24   18.78     7.82   220.69    22.83     0.03    1.64    1.39    1.66   0.08   0.17
sfdv0n1           0.00     0.21    9.91  841.42   128.15  8237.10    19.65     0.93    0.04    0.25    0.04   1.05  89.52

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda3              0.00    15.00    0.00   17.00     0.00   136.00    16.00     0.03    2.00    0.00    2.00   1.29   2.20
sfdv0n1           0.00     0.00    0.00 11158.00     0.00 54448.00     9.76     1.03    0.02    0.00    0.02   0.09 100.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda3              0.00     5.00    0.00   18.00     0.00   104.00    11.56     0.01    0.61    0.00    0.61   0.61   1.10
sfdv0n1           0.00     0.00    0.00 10970.00     0.00 53216.00     9.70     1.02    0.03    0.00    0.03   0.09 100.10

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda3              0.00     0.00    0.00   24.00     0.00   100.00     8.33     0.01    0.58    0.00    0.58   0.08   0.20
sfdv0n1           0.00     0.00    0.00 11206.00     0.00 54476.00     9.72     1.03    0.03    0.00    0.03   0.09  99.90

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda3              0.00    14.00    0.00   21.00     0.00   148.00    14.10     0.01    0.48    0.00    0.48   0.33   0.70
sfdv0n1           0.00     0.00    0.00 10071.00     0.00 49028.00     9.74     1.02    0.03    0.00    0.03   0.10  99.80

NVMe SSD测试数据

对一块ssd进行如下测试(挂载在/data 目录)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -rwmixread=70 -size=16G -filename=/data/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60
EBS 4K randwrite test: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 thread
EBS 4K randwrite test: Laying out IO file (1 file / 16384MiB)
Jobs: 1 (f=1): [w(1)][100.0%][r=0KiB/s,w=63.8MiB/s][r=0,w=16.3k IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=258871: Tue Feb 23 14:12:23 2021
  write: IOPS=18.9k, BW=74.0MiB/s (77.6MB/s)(4441MiB/60001msec)
    slat (usec): min=4, max=6154, avg=48.82, stdev=56.38
    clat (nsec): min=1049, max=12360k, avg=3326362.62, stdev=920683.43
     lat (usec): min=68, max=12414, avg=3375.52, stdev=928.97
    clat percentiles (usec):
     |  1.00th=[ 1483],  5.00th=[ 1811], 10.00th=[ 2114], 20.00th=[ 2376],
     | 30.00th=[ 2704], 40.00th=[ 3130], 50.00th=[ 3523], 60.00th=[ 3785],
     | 70.00th=[ 3949], 80.00th=[ 4080], 90.00th=[ 4293], 95.00th=[ 4490],
     | 99.00th=[ 5604], 99.50th=[ 5997], 99.90th=[ 7111], 99.95th=[ 7832],
     | 99.99th=[ 9634]
   bw (  KiB/s): min=61024, max=118256, per=99.98%, avg=75779.58, stdev=12747.95, samples=120
   iops        : min=15256, max=29564, avg=18944.88, stdev=3186.97, samples=120
  lat (usec)   : 2=0.01%, 100=0.01%, 250=0.01%, 500=0.01%, 750=0.02%
  lat (usec)   : 1000=0.06%
  lat (msec)   : 2=7.40%, 4=66.19%, 10=26.32%, 20=0.01%
  cpu          : usr=5.23%, sys=46.71%, ctx=846953, majf=0, minf=6
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=0,1136905,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
  WRITE: bw=74.0MiB/s (77.6MB/s), 74.0MiB/s-74.0MiB/s (77.6MB/s-77.6MB/s), io=4441MiB (4657MB), run=60001-60001msec

Disk stats (read/write):
  sfdv0n1: ios=0/1821771, merge=0/7335, ticks=0/39708, in_queue=78295, util=100.00%

slat (usec): min=4, max=6154, avg=48.82, stdev=56.38： The first latency metric you’ll see is the ‘slat’ or submission latency. It is pretty much what it sounds like, meaning “how long did it take to submit this IO to the kernel for processing?”

如上测试iops为：18944，测试期间的iostat，测试中一直有mysql在导入数据，所以测试开始前util就已经100%了，并且w/s到了13K左右

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# iostat -d sfdv0n1 3 -x
Linux 3.10.0-957.el7.x86_64 (nu4d01142.sqa.nu8) 	2021年02月23日 	_x86_64_	(104 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00     0.18    3.45  769.17   102.83  7885.16    20.68     0.93    0.04    0.26    0.04   1.16  89.46

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00     0.00    0.00 13168.67     0.00 66244.00    10.06     1.05    0.03    0.00    0.03   0.08 100.10

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00     0.00    0.00 12822.67     0.00 65542.67    10.22     1.04    0.02    0.00    0.02   0.08 100.07

//增加压力
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00     0.00    0.00 27348.33     0.00 214928.00    15.72     1.27    0.02    0.00    0.02   0.04 100.17

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00     1.00    0.00 32661.67     0.00 271660.00    16.63     1.32    0.02    0.00    0.02   0.03 100.37

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00     0.00    0.00 31645.00     0.00 265988.00    16.81     1.33    0.02    0.00    0.02   0.03 100.37

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00   574.00    0.00 31961.67     0.00 271094.67    16.96     1.36    0.02    0.00    0.02   0.03 100.13

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sfdv0n1           0.00     0.00    0.00 27656.33     0.00 224586.67    16.24     1.28    0.02    0.00    0.02   0.04 100.37

从iostat看出，测试开始前util已经100%（因为ssd，util失去参考意义），w/s 13K左右，压力跑起来后w/s能到30K，svctm、await均保持稳定

SSD的direct和buffered似乎很奇怪，应该是direct=0性能更好，实际不是这样，这里还需要找资料求证下

  • direct``=bool

    If value is true, use non-buffered I/O. This is usually O_DIRECT. Note that OpenBSD and ZFS on Solaris don’t support direct I/O. On Windows the synchronous ioengines don’t support direct I/O. Default: false.

  • buffered``=bool

    If value is true, use buffered I/O. This is the opposite of the direct option. Defaults to true.

如下测试中direct=1和direct=0的write avg iops分别为42K、16K

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
# fio -ioengine=libaio -bs=4k -direct=1 -buffered=0 -thread -rw=randrw -rwmixread=70 -size=16G -filename=/data/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60 
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [m(1)][100.0%][r=507MiB/s,w=216MiB/s][r=130k,w=55.2k IOPS][eta 00m:00s] 
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=415921: Tue Feb 23 14:34:33 2021
   read: IOPS=99.8k, BW=390MiB/s (409MB/s)(11.2GiB/29432msec)
    slat (nsec): min=1043, max=917837, avg=4273.86, stdev=3792.17
    clat (usec): min=2, max=4313, avg=459.80, stdev=239.61
     lat (usec): min=4, max=4328, avg=464.16, stdev=241.81
    clat percentiles (usec):
     |  1.00th=[  251],  5.00th=[  277], 10.00th=[  289], 20.00th=[  310],
     | 30.00th=[  326], 40.00th=[  343], 50.00th=[  363], 60.00th=[  400],
     | 70.00th=[  502], 80.00th=[  603], 90.00th=[  750], 95.00th=[  881],
     | 99.00th=[ 1172], 99.50th=[ 1401], 99.90th=[ 3032], 99.95th=[ 3359],
     | 99.99th=[ 3785]
   bw (  KiB/s): min=182520, max=574856, per=99.24%, avg=395975.64, stdev=119541.78, samples=58
   iops        : min=45630, max=143714, avg=98993.90, stdev=29885.42, samples=58
  write: IOPS=42.8k, BW=167MiB/s (175MB/s)(4915MiB/29432msec)
    slat (usec): min=3, max=263, avg= 9.34, stdev= 4.35
    clat (usec): min=14, max=2057, avg=402.26, stdev=140.67
     lat (usec): min=19, max=2070, avg=411.72, stdev=142.67
    clat percentiles (usec):
     |  1.00th=[  237],  5.00th=[  281], 10.00th=[  293], 20.00th=[  314],
     | 30.00th=[  330], 40.00th=[  343], 50.00th=[  359], 60.00th=[  379],
     | 70.00th=[  404], 80.00th=[  457], 90.00th=[  586], 95.00th=[  717],
     | 99.00th=[  930], 99.50th=[ 1004], 99.90th=[ 1254], 99.95th=[ 1385],
     | 99.99th=[ 1532]
   bw (  KiB/s): min=78104, max=244408, per=99.22%, avg=169671.52, stdev=51142.10, samples=58
   iops        : min=19526, max=61102, avg=42417.86, stdev=12785.51, samples=58
  lat (usec)   : 4=0.01%, 10=0.01%, 20=0.01%, 50=0.02%, 100=0.04%
  lat (usec)   : 250=1.02%, 500=73.32%, 750=17.28%, 1000=6.30%
  lat (msec)   : 2=1.83%, 4=0.19%, 10=0.01%
  cpu          : usr=15.84%, sys=83.31%, ctx=13765, majf=0, minf=7
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=2936000,1258304,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=390MiB/s (409MB/s), 390MiB/s-390MiB/s (409MB/s-409MB/s), io=11.2GiB (12.0GB), run=29432-29432msec
  WRITE: bw=167MiB/s (175MB/s), 167MiB/s-167MiB/s (175MB/s-175MB/s), io=4915MiB (5154MB), run=29432-29432msec

Disk stats (read/write):
  sfdv0n1: ios=795793/1618341, merge=0/11, ticks=218710/27721, in_queue=264935, util=100.00%
[root@nu4d01142 data]# 
[root@nu4d01142 data]# fio -ioengine=libaio -bs=4k -direct=0 -buffered=0 -thread -rw=randrw -rwmixread=70 -size=6G -filename=/data/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60 
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [m(1)][100.0%][r=124MiB/s,w=53.5MiB/s][r=31.7k,w=13.7k IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=437523: Tue Feb 23 14:37:54 2021
   read: IOPS=38.6k, BW=151MiB/s (158MB/s)(4300MiB/28550msec)
    slat (nsec): min=1205, max=1826.7k, avg=13253.36, stdev=17173.87
    clat (nsec): min=236, max=5816.8k, avg=1135969.25, stdev=337142.34
     lat (nsec): min=1977, max=5831.2k, avg=1149404.84, stdev=341232.87
    clat percentiles (usec):
     |  1.00th=[  461],  5.00th=[  627], 10.00th=[  717], 20.00th=[  840],
     | 30.00th=[  938], 40.00th=[ 1029], 50.00th=[ 1123], 60.00th=[ 1221],
     | 70.00th=[ 1319], 80.00th=[ 1434], 90.00th=[ 1565], 95.00th=[ 1680],
     | 99.00th=[ 1893], 99.50th=[ 1975], 99.90th=[ 2671], 99.95th=[ 3261],
     | 99.99th=[ 3851]
   bw (  KiB/s): min=119304, max=216648, per=100.00%, avg=154273.07, stdev=29925.10, samples=57
   iops        : min=29826, max=54162, avg=38568.25, stdev=7481.30, samples=57
  write: IOPS=16.5k, BW=64.6MiB/s (67.7MB/s)(1844MiB/28550msec)
    slat (usec): min=3, max=3565, avg=21.07, stdev=22.23
    clat (usec): min=14, max=9983, avg=1164.21, stdev=459.66
     lat (usec): min=21, max=10011, avg=1185.57, stdev=463.28
    clat percentiles (usec):
     |  1.00th=[  498],  5.00th=[  619], 10.00th=[  709], 20.00th=[  832],
     | 30.00th=[  930], 40.00th=[ 1020], 50.00th=[ 1123], 60.00th=[ 1237],
     | 70.00th=[ 1336], 80.00th=[ 1450], 90.00th=[ 1598], 95.00th=[ 1713],
     | 99.00th=[ 2311], 99.50th=[ 3851], 99.90th=[ 5932], 99.95th=[ 6456],
     | 99.99th=[ 7701]
   bw (  KiB/s): min=50800, max=92328, per=100.00%, avg=66128.47, stdev=12890.64, samples=57
   iops        : min=12700, max=23082, avg=16532.07, stdev=3222.66, samples=57
  lat (nsec)   : 250=0.01%, 500=0.01%, 750=0.01%, 1000=0.01%
  lat (usec)   : 2=0.01%, 4=0.01%, 10=0.01%, 20=0.02%, 50=0.03%
  lat (usec)   : 100=0.04%, 250=0.18%, 500=1.01%, 750=11.05%, 1000=25.02%
  lat (msec)   : 2=61.87%, 4=0.62%, 10=0.14%
  cpu          : usr=10.87%, sys=61.98%, ctx=218415, majf=0, minf=7
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=1100924,471940,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=151MiB/s (158MB/s), 151MiB/s-151MiB/s (158MB/s-158MB/s), io=4300MiB (4509MB), run=28550-28550msec
  WRITE: bw=64.6MiB/s (67.7MB/s), 64.6MiB/s-64.6MiB/s (67.7MB/s-67.7MB/s), io=1844MiB (1933MB), run=28550-28550msec

Disk stats (read/write):
  sfdv0n1: ios=536103/822037, merge=0/1442, ticks=66507/17141, in_queue=99429, util=100.00%

SATA SSD测试数据

1
2
3
4
5
6
# cat /sys/block/sda/queue/rotational 
0
# lsblk -d -o name,rota
NAME     ROTA
sda         0
sfdv0n1     0

-direct=0 -buffered=0读写iops分别为15.8K、6.8K 比ssd差了不少（都是direct=0），如果direct、buffered都是1的话，ESSD性能很差，读写iops分别为4312、1852

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
# fio -ioengine=libaio -bs=4k -direct=0 -buffered=0 -thread -rw=randrw -rwmixread=70 -size=2G -filename=/var/lib/docker/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60 
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 thread
EBS 4K randwrite test: Laying out IO file (1 file / 2048MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=68.7MiB/s,w=29.7MiB/s][r=17.6k,w=7594 IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=13261: Tue Feb 23 14:42:41 2021
   read: IOPS=15.8k, BW=61.8MiB/s (64.8MB/s)(1432MiB/23172msec)
    slat (nsec): min=1266, max=7261.0k, avg=7101.88, stdev=20655.54
    clat (usec): min=167, max=27670, avg=2832.68, stdev=1786.18
     lat (usec): min=175, max=27674, avg=2839.93, stdev=1784.42
    clat percentiles (usec):
     |  1.00th=[  437],  5.00th=[  668], 10.00th=[  873], 20.00th=[  988],
     | 30.00th=[ 1401], 40.00th=[ 2442], 50.00th=[ 2835], 60.00th=[ 3195],
     | 70.00th=[ 3523], 80.00th=[ 4047], 90.00th=[ 5014], 95.00th=[ 5866],
     | 99.00th=[ 8160], 99.50th=[ 9372], 99.90th=[13829], 99.95th=[15008],
     | 99.99th=[23725]
   bw (  KiB/s): min=44183, max=149440, per=99.28%, avg=62836.17, stdev=26590.84, samples=46
   iops        : min=11045, max=37360, avg=15709.02, stdev=6647.72, samples=46
  write: IOPS=6803, BW=26.6MiB/s (27.9MB/s)(616MiB/23172msec)
    slat (nsec): min=1566, max=11474k, avg=8460.17, stdev=38221.51
    clat (usec): min=77, max=24047, avg=2789.68, stdev=2042.55
     lat (usec): min=80, max=24054, avg=2798.29, stdev=2040.85
    clat percentiles (usec):
     |  1.00th=[  265],  5.00th=[  433], 10.00th=[  635], 20.00th=[  840],
     | 30.00th=[  979], 40.00th=[ 2212], 50.00th=[ 2671], 60.00th=[ 3130],
     | 70.00th=[ 3523], 80.00th=[ 4228], 90.00th=[ 5342], 95.00th=[ 6456],
     | 99.00th=[ 9241], 99.50th=[10421], 99.90th=[13960], 99.95th=[15533],
     | 99.99th=[23725]
   bw (  KiB/s): min=18435, max=63112, per=99.26%, avg=27012.57, stdev=11299.42, samples=46
   iops        : min= 4608, max=15778, avg=6753.11, stdev=2824.87, samples=46
  lat (usec)   : 100=0.01%, 250=0.23%, 500=3.14%, 750=5.46%, 1000=15.27%
  lat (msec)   : 2=11.47%, 4=43.09%, 10=20.88%, 20=0.44%, 50=0.01%
  cpu          : usr=3.53%, sys=18.08%, ctx=47448, majf=0, minf=6
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=366638,157650,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=61.8MiB/s (64.8MB/s), 61.8MiB/s-61.8MiB/s (64.8MB/s-64.8MB/s), io=1432MiB (1502MB), run=23172-23172msec
  WRITE: bw=26.6MiB/s (27.9MB/s), 26.6MiB/s-26.6MiB/s (27.9MB/s-27.9MB/s), io=616MiB (646MB), run=23172-23172msec

Disk stats (read/write):
  sda: ios=359202/155123, merge=299/377, ticks=946305/407820, in_queue=1354596, util=99.61%
  
# fio -ioengine=libaio -bs=4k -direct=1 -buffered=0 -thread -rw=randrw -rwmixread=70 -size=2G -filename=/var/lib/docker/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60 
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [m(1)][95.5%][r=57.8MiB/s,w=25.7MiB/s][r=14.8k,w=6568 IOPS][eta 00m:01s] 
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=26167: Tue Feb 23 14:44:40 2021
   read: IOPS=16.9k, BW=65.9MiB/s (69.1MB/s)(1432MiB/21730msec)
    slat (nsec): min=1312, max=4454.2k, avg=8489.99, stdev=15763.97
    clat (usec): min=201, max=18856, avg=2679.38, stdev=1720.02
     lat (usec): min=206, max=18860, avg=2688.03, stdev=1717.19
    clat percentiles (usec):
     |  1.00th=[  635],  5.00th=[  832], 10.00th=[  914], 20.00th=[  971],
     | 30.00th=[ 1090], 40.00th=[ 2114], 50.00th=[ 2704], 60.00th=[ 3064],
     | 70.00th=[ 3392], 80.00th=[ 3851], 90.00th=[ 4817], 95.00th=[ 5735],
     | 99.00th=[ 7767], 99.50th=[ 8979], 99.90th=[13698], 99.95th=[15139],
     | 99.99th=[16581]
   bw (  KiB/s): min=45168, max=127528, per=100.00%, avg=67625.19, stdev=26620.82, samples=43
   iops        : min=11292, max=31882, avg=16906.28, stdev=6655.20, samples=43
  write: IOPS=7254, BW=28.3MiB/s (29.7MB/s)(616MiB/21730msec)
    slat (nsec): min=1749, max=3412.2k, avg=9816.22, stdev=14501.05
    clat (usec): min=97, max=23473, avg=2556.02, stdev=1980.53
     lat (usec): min=107, max=23477, avg=2566.01, stdev=1977.65
    clat percentiles (usec):
     |  1.00th=[  277],  5.00th=[  486], 10.00th=[  693], 20.00th=[  824],
     | 30.00th=[  881], 40.00th=[ 1205], 50.00th=[ 2442], 60.00th=[ 2868],
     | 70.00th=[ 3326], 80.00th=[ 3949], 90.00th=[ 5080], 95.00th=[ 6128],
     | 99.00th=[ 8717], 99.50th=[10159], 99.90th=[14484], 99.95th=[15926],
     | 99.99th=[18744]
   bw (  KiB/s): min=19360, max=55040, per=100.00%, avg=29064.05, stdev=11373.59, samples=43
   iops        : min= 4840, max=13760, avg=7266.00, stdev=2843.41, samples=43
  lat (usec)   : 100=0.01%, 250=0.17%, 500=1.66%, 750=3.74%, 1000=22.57%
  lat (msec)   : 2=12.66%, 4=40.62%, 10=18.20%, 20=0.38%, 50=0.01%
  cpu          : usr=4.17%, sys=22.27%, ctx=14314, majf=0, minf=7
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=366638,157650,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=65.9MiB/s (69.1MB/s), 65.9MiB/s-65.9MiB/s (69.1MB/s-69.1MB/s), io=1432MiB (1502MB), run=21730-21730msec
  WRITE: bw=28.3MiB/s (29.7MB/s), 28.3MiB/s-28.3MiB/s (29.7MB/s-29.7MB/s), io=616MiB (646MB), run=21730-21730msec

Disk stats (read/write):
  sda: ios=364744/157621, merge=779/473, ticks=851759/352008, in_queue=1204024, util=99.61%

# fio -ioengine=libaio -bs=4k -direct=1 -buffered=1 -thread -rw=randrw -rwmixread=70 -size=2G -filename=/var/lib/docker/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60 
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [m(1)][100.0%][r=15.9MiB/s,w=7308KiB/s][r=4081,w=1827 IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=31560: Tue Feb 23 14:46:10 2021
   read: IOPS=4312, BW=16.8MiB/s (17.7MB/s)(1011MiB/60001msec)
    slat (usec): min=63, max=14320, avg=216.76, stdev=430.61
    clat (usec): min=5, max=778861, avg=10254.92, stdev=22345.40
     lat (usec): min=1900, max=782277, avg=10472.16, stdev=22657.06
    clat percentiles (msec):
     |  1.00th=[    6],  5.00th=[    6], 10.00th=[    6], 20.00th=[    7],
     | 30.00th=[    7], 40.00th=[    7], 50.00th=[    7], 60.00th=[    7],
     | 70.00th=[    8], 80.00th=[    8], 90.00th=[    8], 95.00th=[   11],
     | 99.00th=[  107], 99.50th=[  113], 99.90th=[  132], 99.95th=[  197],
     | 99.99th=[  760]
   bw (  KiB/s): min=  168, max=29784, per=100.00%, avg=17390.92, stdev=10932.90, samples=119
   iops        : min=   42, max= 7446, avg=4347.71, stdev=2733.21, samples=119
  write: IOPS=1852, BW=7410KiB/s (7588kB/s)(434MiB/60001msec)
    slat (usec): min=3, max=666432, avg=23.59, stdev=2745.39
    clat (msec): min=3, max=781, avg=10.14, stdev=20.50
     lat (msec): min=3, max=781, avg=10.16, stdev=20.72
    clat percentiles (msec):
     |  1.00th=[    6],  5.00th=[    6], 10.00th=[    6], 20.00th=[    7],
     | 30.00th=[    7], 40.00th=[    7], 50.00th=[    7], 60.00th=[    7],
     | 70.00th=[    7], 80.00th=[    8], 90.00th=[    8], 95.00th=[   11],
     | 99.00th=[  107], 99.50th=[  113], 99.90th=[  131], 99.95th=[  157],
     | 99.99th=[  760]
   bw (  KiB/s): min=   80, max=12328, per=100.00%, avg=7469.53, stdev=4696.69, samples=119
   iops        : min=   20, max= 3082, avg=1867.34, stdev=1174.19, samples=119
  lat (usec)   : 10=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=94.64%, 20=1.78%, 50=0.11%
  lat (msec)   : 100=1.80%, 250=1.63%, 500=0.01%, 750=0.02%, 1000=0.01%
  cpu          : usr=2.51%, sys=10.98%, ctx=260210, majf=0, minf=7
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=258768,111147,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=16.8MiB/s (17.7MB/s), 16.8MiB/s-16.8MiB/s (17.7MB/s-17.7MB/s), io=1011MiB (1060MB), run=60001-60001msec
  WRITE: bw=7410KiB/s (7588kB/s), 7410KiB/s-7410KiB/s (7588kB/s-7588kB/s), io=434MiB (455MB), run=60001-60001msec

Disk stats (read/write):
  sda: ios=258717/89376, merge=0/735, ticks=52540/564186, in_queue=616999, util=90.07%

ESSD磁盘测试数据

这是一块虚拟的阿里云网络盘，不能算完整意义的SSD（承诺IOPS 4200），数据仅供参考，磁盘概况：

1
2
3
4
5
6
$df -lh
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        99G   30G   65G  32% /

$cat /sys/block/vda/queue/rotational
1

测试数据：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
$fio -ioengine=libaio -bs=4k -direct=1 -buffered=1  -thread -rw=randrw  -size=4G -filename=/home/admin/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.1
Starting 1 thread
Jobs: 1 (f=1): [m(1)][100.0%][r=10.8MiB/s,w=11.2MiB/s][r=2757,w=2876 IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=25641: Tue Feb 23 16:35:19 2021
   read: IOPS=2136, BW=8545KiB/s (8750kB/s)(501MiB/60001msec)
    slat (usec): min=190, max=830992, avg=457.20, stdev=3088.80
    clat (nsec): min=1792, max=1721.3M, avg=14657528.60, stdev=63188988.75
     lat (usec): min=344, max=1751.1k, avg=15115.20, stdev=65165.80
    clat percentiles (msec):
     |  1.00th=[    8],  5.00th=[    9], 10.00th=[    9], 20.00th=[   10],
     | 30.00th=[   10], 40.00th=[   11], 50.00th=[   11], 60.00th=[   11],
     | 70.00th=[   12], 80.00th=[   12], 90.00th=[   13], 95.00th=[   14],
     | 99.00th=[   17], 99.50th=[   53], 99.90th=[ 1028], 99.95th=[ 1167],
     | 99.99th=[ 1653]
   bw (  KiB/s): min=   56, max=12648, per=100.00%, avg=8598.92, stdev=5289.40, samples=118
   iops        : min=   14, max= 3162, avg=2149.73, stdev=1322.35, samples=118
  write: IOPS=2137, BW=8548KiB/s (8753kB/s)(501MiB/60001msec)
    slat (usec): min=2, max=181, avg= 6.67, stdev= 7.22
    clat (usec): min=628, max=1721.1k, avg=14825.32, stdev=65017.66
     lat (usec): min=636, max=1721.1k, avg=14832.10, stdev=65018.10
    clat percentiles (msec):
     |  1.00th=[    8],  5.00th=[    9], 10.00th=[    9], 20.00th=[   10],
     | 30.00th=[   10], 40.00th=[   11], 50.00th=[   11], 60.00th=[   11],
     | 70.00th=[   12], 80.00th=[   12], 90.00th=[   13], 95.00th=[   14],
     | 99.00th=[   17], 99.50th=[   53], 99.90th=[ 1045], 99.95th=[ 1200],
     | 99.99th=[ 1687]
   bw (  KiB/s): min=   72, max=13304, per=100.00%, avg=8602.99, stdev=5296.31, samples=118
   iops        : min=   18, max= 3326, avg=2150.75, stdev=1324.08, samples=118
  lat (usec)   : 2=0.01%, 500=0.01%, 750=0.01%
  lat (msec)   : 2=0.01%, 4=0.01%, 10=37.85%, 20=61.53%, 50=0.10%
  lat (msec)   : 100=0.06%, 250=0.03%, 500=0.01%, 750=0.03%, 1000=0.25%
  lat (msec)   : 2000=0.14%
  cpu          : usr=0.70%, sys=4.01%, ctx=135029, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwt: total=128180,128223,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=8545KiB/s (8750kB/s), 8545KiB/s-8545KiB/s (8750kB/s-8750kB/s), io=501MiB (525MB), run=60001-60001msec
  WRITE: bw=8548KiB/s (8753kB/s), 8548KiB/s-8548KiB/s (8753kB/s-8753kB/s), io=501MiB (525MB), run=60001-60001msec

Disk stats (read/write):
  vda: ios=127922/87337, merge=0/237, ticks=55122/4269885, in_queue=2209125, util=94.29%

$fio -ioengine=libaio -bs=4k -direct=1 -buffered=0  -thread -rw=randrw  -size=4G -filename=/home/admin/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.1
Starting 1 thread
Jobs: 1 (f=1): [m(1)][100.0%][r=9680KiB/s,w=9712KiB/s][r=2420,w=2428 IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=25375: Tue Feb 23 16:33:03 2021
   read: IOPS=2462, BW=9849KiB/s (10.1MB/s)(577MiB/60011msec)
    slat (nsec): min=1558, max=10663k, avg=5900.28, stdev=46286.64
    clat (usec): min=290, max=93493, avg=13054.57, stdev=4301.89
     lat (usec): min=332, max=93497, avg=13060.60, stdev=4301.68
    clat percentiles (usec):
     |  1.00th=[ 1844],  5.00th=[10159], 10.00th=[10290], 20.00th=[10421],
     | 30.00th=[10552], 40.00th=[10552], 50.00th=[10683], 60.00th=[10814],
     | 70.00th=[18482], 80.00th=[19006], 90.00th=[19006], 95.00th=[19268],
     | 99.00th=[19530], 99.50th=[19792], 99.90th=[29492], 99.95th=[30278],
     | 99.99th=[43779]
   bw (  KiB/s): min= 9128, max=30392, per=100.00%, avg=9850.12, stdev=1902.00, samples=120
   iops        : min= 2282, max= 7598, avg=2462.52, stdev=475.50, samples=120
  write: IOPS=2465, BW=9864KiB/s (10.1MB/s)(578MiB/60011msec)
    slat (usec): min=2, max=10586, avg= 6.92, stdev=67.34
    clat (usec): min=240, max=69922, avg=12902.33, stdev=4307.92
     lat (usec): min=244, max=69927, avg=12909.37, stdev=4307.03
    clat percentiles (usec):
     |  1.00th=[ 1729],  5.00th=[10159], 10.00th=[10290], 20.00th=[10290],
     | 30.00th=[10421], 40.00th=[10421], 50.00th=[10552], 60.00th=[10683],
     | 70.00th=[18220], 80.00th=[18744], 90.00th=[19006], 95.00th=[19006],
     | 99.00th=[19268], 99.50th=[19530], 99.90th=[21103], 99.95th=[35390],
     | 99.99th=[50594]
   bw (  KiB/s): min= 8496, max=31352, per=100.00%, avg=9862.92, stdev=1991.48, samples=120
   iops        : min= 2124, max= 7838, avg=2465.72, stdev=497.87, samples=120
  lat (usec)   : 250=0.01%, 500=0.03%, 750=0.02%, 1000=0.02%
  lat (msec)   : 2=1.70%, 4=0.41%, 10=1.25%, 20=96.22%, 50=0.34%
  lat (msec)   : 100=0.01%
  cpu          : usr=0.89%, sys=4.09%, ctx=206337, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwt: total=147768,147981,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=9849KiB/s (10.1MB/s), 9849KiB/s-9849KiB/s (10.1MB/s-10.1MB/s), io=577MiB (605MB), run=60011-60011msec
  WRITE: bw=9864KiB/s (10.1MB/s), 9864KiB/s-9864KiB/s (10.1MB/s-10.1MB/s), io=578MiB (606MB), run=60011-60011msec

Disk stats (read/write):
  vda: ios=147515/148154, merge=0/231, ticks=1922378/1915751, in_queue=3780605, util=98.46%
  
$fio -ioengine=libaio -bs=4k -direct=0 -buffered=1  -thread -rw=randrw  -size=4G -filename=/home/admin/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.1
Starting 1 thread
Jobs: 1 (f=1): [m(1)][100.0%][r=132KiB/s,w=148KiB/s][r=33,w=37 IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=25892: Tue Feb 23 16:37:41 2021
   read: IOPS=1987, BW=7949KiB/s (8140kB/s)(467MiB/60150msec)
    slat (usec): min=192, max=599873, avg=479.26, stdev=2917.52
    clat (usec): min=15, max=1975.6k, avg=16004.22, stdev=76024.60
     lat (msec): min=5, max=2005, avg=16.48, stdev=78.00
    clat percentiles (msec):
     |  1.00th=[    8],  5.00th=[    9], 10.00th=[    9], 20.00th=[   10],
     | 30.00th=[   10], 40.00th=[   11], 50.00th=[   11], 60.00th=[   11],
     | 70.00th=[   12], 80.00th=[   12], 90.00th=[   13], 95.00th=[   14],
     | 99.00th=[   19], 99.50th=[  317], 99.90th=[ 1133], 99.95th=[ 1435],
     | 99.99th=[ 1871]
   bw (  KiB/s): min=   32, max=12672, per=100.00%, avg=8034.08, stdev=5399.63, samples=119
   iops        : min=    8, max= 3168, avg=2008.52, stdev=1349.91, samples=119
  write: IOPS=1984, BW=7937KiB/s (8127kB/s)(466MiB/60150msec)
    slat (usec): min=2, max=839634, avg=18.39, stdev=2747.10
    clat (msec): min=5, max=1975, avg=15.64, stdev=73.06
     lat (msec): min=5, max=1975, avg=15.66, stdev=73.28
    clat percentiles (msec):
     |  1.00th=[    8],  5.00th=[    9], 10.00th=[    9], 20.00th=[   10],
     | 30.00th=[   10], 40.00th=[   11], 50.00th=[   11], 60.00th=[   11],
     | 70.00th=[   12], 80.00th=[   12], 90.00th=[   13], 95.00th=[   14],
     | 99.00th=[   18], 99.50th=[  153], 99.90th=[ 1116], 99.95th=[ 1435],
     | 99.99th=[ 1921]
   bw (  KiB/s): min=   24, max=13160, per=100.00%, avg=8021.18, stdev=5405.12, samples=119
   iops        : min=    6, max= 3290, avg=2005.29, stdev=1351.28, samples=119
  lat (usec)   : 20=0.01%
  lat (msec)   : 10=36.51%, 20=62.63%, 50=0.21%, 100=0.12%, 250=0.05%
  lat (msec)   : 500=0.02%, 750=0.02%, 1000=0.19%, 2000=0.26%
  cpu          : usr=0.62%, sys=4.04%, ctx=125974, majf=0, minf=3
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwt: total=119533,119347,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=7949KiB/s (8140kB/s), 7949KiB/s-7949KiB/s (8140kB/s-8140kB/s), io=467MiB (490MB), run=60150-60150msec
  WRITE: bw=7937KiB/s (8127kB/s), 7937KiB/s-7937KiB/s (8127kB/s-8127kB/s), io=466MiB (489MB), run=60150-60150msec

Disk stats (read/write):
  vda: ios=119533/108186, merge=0/214, ticks=54093/4937255, in_queue=2525052, util=93.99%
  
$fio -ioengine=libaio -bs=4k -direct=0 -buffered=0  -thread -rw=randrw  -size=4G -filename=/home/admin/fio.test -name="EBS 4K randwrite test" -iodepth=64 -runtime=60
EBS 4K randwrite test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64
fio-3.1
Starting 1 thread
Jobs: 1 (f=1): [m(1)][100.0%][r=9644KiB/s,w=9792KiB/s][r=2411,w=2448 IOPS][eta 00m:00s]
EBS 4K randwrite test: (groupid=0, jobs=1): err= 0: pid=26139: Tue Feb 23 16:39:43 2021
   read: IOPS=2455, BW=9823KiB/s (10.1MB/s)(576MiB/60015msec)
    slat (nsec): min=1619, max=18282k, avg=5882.81, stdev=71214.52
    clat (usec): min=281, max=64630, avg=13055.68, stdev=4233.17
     lat (usec): min=323, max=64636, avg=13061.69, stdev=4232.79
    clat percentiles (usec):
     |  1.00th=[ 2040],  5.00th=[10290], 10.00th=[10421], 20.00th=[10421],
     | 30.00th=[10552], 40.00th=[10552], 50.00th=[10683], 60.00th=[10814],
     | 70.00th=[18220], 80.00th=[19006], 90.00th=[19006], 95.00th=[19268],
     | 99.00th=[19530], 99.50th=[20055], 99.90th=[28967], 99.95th=[29754],
     | 99.99th=[30540]
   bw (  KiB/s): min= 8776, max=27648, per=100.00%, avg=9824.29, stdev=1655.78, samples=120
   iops        : min= 2194, max= 6912, avg=2456.05, stdev=413.95, samples=120
  write: IOPS=2458, BW=9835KiB/s (10.1MB/s)(576MiB/60015msec)
    slat (usec): min=2, max=10681, avg= 6.79, stdev=71.30
    clat (usec): min=221, max=70411, avg=12909.50, stdev=4312.40
     lat (usec): min=225, max=70414, avg=12916.40, stdev=4312.05
    clat percentiles (usec):
     |  1.00th=[ 1909],  5.00th=[10159], 10.00th=[10290], 20.00th=[10290],
     | 30.00th=[10421], 40.00th=[10421], 50.00th=[10552], 60.00th=[10683],
     | 70.00th=[18220], 80.00th=[18744], 90.00th=[19006], 95.00th=[19006],
     | 99.00th=[19268], 99.50th=[19530], 99.90th=[28705], 99.95th=[40109],
     | 99.99th=[60031]
   bw (  KiB/s): min= 8568, max=28544, per=100.00%, avg=9836.03, stdev=1737.29, samples=120
   iops        : min= 2142, max= 7136, avg=2458.98, stdev=434.32, samples=120
  lat (usec)   : 250=0.01%, 500=0.03%, 750=0.02%, 1000=0.02%
  lat (msec)   : 2=1.03%, 4=1.10%, 10=0.98%, 20=96.43%, 50=0.38%
  lat (msec)   : 100=0.01%
  cpu          : usr=0.82%, sys=4.32%, ctx=212008, majf=0, minf=4
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwt: total=147386,147564,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Run status group 0 (all jobs):
   READ: bw=9823KiB/s (10.1MB/s), 9823KiB/s-9823KiB/s (10.1MB/s-10.1MB/s), io=576MiB (604MB), run=60015-60015msec
  WRITE: bw=9835KiB/s (10.1MB/s), 9835KiB/s-9835KiB/s (10.1MB/s-10.1MB/s), io=576MiB (604MB), run=60015-60015msec

Disk stats (read/write):
  vda: ios=147097/147865, merge=0/241, ticks=1916703/1915836, in_queue=3791443, util=98.68%

测试数据总结

-direct=1 -buffered=1 -direct=1 -buffered=0 -direct=0 -buffered=0 -direct=0 -buffered=1
NVMe SSD R=10.6k W=4544 R=99.8K W=42.8K R=38.6k W=16.5k R=10.8K W=4642
SATA SSD R=4312 W=1852 R=16.9k W=7254 R=15.8k W=6803 R=5389 W=2314
ESSD R=2149 W=2150 R=2462 W=2465 R=2455 W=2458 R=1987 W=1984

看起来，对于SSD如果buffered为1的话direct没啥用，如果buffered为0那么direct为1性能要好很多

SATA SSD的IOPS比NVMe性能差很多。

SATA SSD当-buffered=1参数下SATA SSD的latency在7-10us之间。

NVMe SSD以及SATA SSD当buffered=0的条件下latency均为2-3us, NVMe SSD latency参考文章第一个表格， 和本次NVMe测试结果一致.

ESSD的latency基本是13-16us。

以上NVMe SSD测试数据是在测试过程中还有mysql在全力导入数据的情况下，用fio测试所得。所以空闲情况下测试结果会更好。

HDD性能测试数据

img

从上图可以看到这个磁盘的IOPS 读 935 写 400，读rt 10731nsec 大约10us, 写 17us。如果IOPS是1000的话，rt应该是1ms，实际比1ms小两个数量级，应该是cache、磁盘阵列在起作用。

SATA硬盘，10K转

万转机械硬盘组成RAID5阵列，在顺序条件最好的情况下，带宽可以达到1GB/s以上，平均延时也非常低，最低只有20多us。但是在随机IO的情况下，机械硬盘的短板就充分暴露了，零点几兆的带宽，将近5ms的延迟，IOPS只有200左右。其原因是因为

  • 随机访问直接让RAID卡缓存成了个摆设
  • 磁盘不能并行工作，因为我的机器RAID宽度Strip Size为128 KB
  • 机械轴也得在各个磁道之间跳来跳去。

理解了磁盘顺序IO时候的几十M甚至一个GB的带宽，随机IO这个真的是太可怜了。

从上面的测试数据中我们看到了机械硬盘在顺序IO和随机IO下的巨大性能差异。在顺序IO情况下，磁盘是最擅长的顺序IO,再加上Raid卡缓存命中率也高。这时带宽表现有几十、几百M，最好条件下甚至能达到1GB。IOPS这时候能有2-3W左右。到了随机IO的情形下，机械轴也被逼的跳来跳去寻道，RAID卡缓存也失效了。带宽跌到了1MB以下，最低只有100K，IOPS也只有可怜巴巴的200左右。

网上测试数据参考

我们来一起看一下具体的数据。首先来看NVＭe如何减小了协议栈本身的时间消耗，我们用blktrace工具来分析一组传输在应用程序层、操作系统层、驱动层和硬件层消耗的时间和占比，来了解AHCI和NVMe协议的性能区别：

img

硬盘HDD作为一个参考基准，它的时延是非常大的，达到14ms，而AHCI SATA为125us，NVMe为111us。我们从图中可以看出，NVMe相对AHCI，协议栈及之下所占用的时间比重明显减小，应用程序层面等待的时间占比很高，这是因为SSD物理硬盘速度不够快，导致应用空转。NVMe也为将来Optane硬盘这种低延迟介质的速度提高留下了广阔的空间。

rq_affinity

参考aliyun测试文档 , rq_affinity增加2的commit： git show 5757a6d76c

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
function RunFio
{
 numjobs=$1   # 实例中的测试线程数，例如示例中的10
 iodepth=$2   # 同时发出I/O数的上限，例如示例中的64
 bs=$3        # 单次I/O的块文件大小，例如示例中的4k
 rw=$4        # 测试时的读写策略，例如示例中的randwrite
 filename=$5  # 指定测试文件的名称，例如示例中的/dev/your_device
 nr_cpus=`cat /proc/cpuinfo |grep "processor" |wc -l`
 if [ $nr_cpus -lt $numjobs ];then
     echo “Numjobs is more than cpu cores, exit!”
     exit -1
 fi
 let nu=$numjobs+1
 cpulist=""
 for ((i=1;i<10;i++))
 do
     list=`cat /sys/block/your_device/mq/*/cpu_list | awk '{if(i<=NF) print $i;}' i="$i" | tr -d ',' | tr '\n' ','`
     if [ -z $list ];then
         break
     fi
     cpulist=${cpulist}${list}
 done
 spincpu=`echo $cpulist | cut -d ',' -f 2-${nu}`
 echo $spincpu
 fio --ioengine=libaio --runtime=30s --numjobs=${numjobs} --iodepth=${iodepth} --bs=${bs} --rw=${rw} --filename=${filename} --time_based=1 --direct=1 --name=test --group_reporting --cpus_allowed=$spincpu --cpus_allowed_policy=split
}
echo 2 > /sys/block/your_device/queue/rq_affinity
sleep 5
RunFio 10 64 4k randwrite filename

对NVME SSD进行测试，左边rq_affinity是2，右边rq_affinity为1，在这个测试参数下rq_affinity为1的性能要好(后许多次测试两者性能差不多)

image-20210607113709945

LVM性能对比

磁盘信息

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#lsblk
NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda            8:0    0 223.6G  0 disk
├─sda1         8:1    0     3M  0 part
├─sda2         8:2    0     1G  0 part /boot
├─sda3         8:3    0    96G  0 part /
├─sda4         8:4    0    10G  0 part /tmp
└─sda5         8:5    0 116.6G  0 part /home
nvme0n1      259:4    0   2.7T  0 disk
└─nvme0n1p1  259:5    0   2.7T  0 part
  └─vg1-drds 252:0    0   5.4T  0 lvm  /drds
nvme1n1      259:0    0   2.7T  0 disk
└─nvme1n1p1  259:2    0   2.7T  0 part /u02
nvme2n1      259:1    0   2.7T  0 disk
└─nvme2n1p1  259:3    0   2.7T  0 part
  └─vg1-drds 252:0    0   5.4T  0 lvm  /drds

单块nvme SSD盘跑mysql server，运行sysbench导入测试数据

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
#iostat -x nvme1n1 1
Linux 3.10.0-327.ali2017.alios7.x86_64 (k28a11352.eu95sqa) 	05/13/2021 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.32    0.00    0.17    0.07    0.00   99.44

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme1n1           0.00    47.19    0.19  445.15     2.03 43110.89   193.62     0.31    0.70    0.03    0.70   0.06   2.85

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.16    0.00    0.36    0.17    0.00   98.31

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme1n1           0.00   122.00    0.00 3290.00     0.00 271052.00   164.77     1.65    0.50    0.00    0.50   0.05  17.00

#iostat 1
Linux 3.10.0-327.ali2017.alios7.x86_64 (k28a11352.eu95sqa) 	05/13/2021 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.14    0.00    0.13    0.05    0.00   99.67

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              49.21       554.51      2315.83    1416900    5917488
nvme1n1           5.65         2.34       844.73       5989    2158468
nvme2n1           0.06         1.13         0.00       2896          0
nvme0n1           0.06         1.13         0.00       2900          0
dm-0              0.02         0.41         0.00       1036          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.39    0.00    0.23    0.08    0.00   98.30

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               8.00         0.00        60.00          0         60
nvme1n1         868.00         0.00    132100.00          0     132100
nvme2n1           0.00         0.00         0.00          0          0
nvme0n1           0.00         0.00         0.00          0          0
dm-0              0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.44    0.00    0.14    0.09    0.00   98.33

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
nvme1n1         766.00         0.00    132780.00          0     132780
nvme2n1           0.00         0.00         0.00          0          0
nvme0n1           0.00         0.00         0.00          0          0
dm-0              0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.41    0.00    0.16    0.09    0.00   98.34

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             105.00         0.00       532.00          0        532
nvme1n1         760.00         0.00    122236.00          0     122236
nvme2n1           0.00         0.00         0.00          0          0
nvme0n1           0.00         0.00         0.00          0          0
dm-0              0.00         0.00         0.00          0          0

如果同样写lvm，由两块nvme组成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme2n1           0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
nvme0n1           0.00   137.00    0.00 5730.00     0.00 421112.00   146.98     2.95    0.52    0.00    0.52   0.05  27.30

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.17    0.00    0.34    0.19    0.00   98.30

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme2n1           0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
nvme0n1           0.00   109.00    0.00 2533.00     0.00 271236.00   214.16     1.08    0.43    0.00    0.43   0.06  15.90

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.38    0.00    0.42    0.20    0.00   98.00

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
nvme2n1           0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
nvme0n1           0.00   118.00    0.00 3336.00     0.00 320708.00   192.27     1.50    0.45    0.00    0.45   0.06  20.00

[root@k28a11352.eu95sqa /var/lib]
#iostat  1
Linux 3.10.0-327.ali2017.alios7.x86_64 (k28a11352.eu95sqa) 	05/13/2021 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.40    0.00    0.20    0.07    0.00   99.33

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              38.96       334.64      1449.68    1419236    6148304
nvme1n1         324.95         1.43     31201.30       6069  132329072
nvme2n1           0.07         0.90         0.00       3808          0
nvme0n1         256.24         1.60     22918.46       6801   97200388
dm-0            266.98         1.38     22918.46       5849   97200388

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.20    0.00    0.42    0.25    0.00   98.12

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda               0.00         0.00         0.00          0          0
nvme1n1           0.00         0.00         0.00          0          0
nvme2n1           0.00         0.00         0.00          0          0
nvme0n1        4460.00         0.00    332288.00          0     332288
dm-0           4608.00         0.00    332288.00          0     332288

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.35    0.00    0.38    0.22    0.00   98.06

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda              48.00         0.00       200.00          0        200
nvme1n1           0.00         0.00         0.00          0          0
nvme2n1           0.00         0.00         0.00          0          0
nvme0n1        4187.00         0.00    332368.00          0     332368
dm-0           4348.00         0.00    332368.00          0     332368

不知道为什么只有一个块ssd有流量，可能跟只写一个文件有关系

SSD中，SATA、m2、PCIE和NVME各有什么意义

高速信号协议

SAS，SATA，PCIe 这三个是同一个层面上的，模拟串行高速接口。

  • SAS 对扩容比较友好，也支持双控双活。接上SAS RAID 卡，一般在阵列上用的比较多。
  • SATA 对热插拔很友好，早先台式机装机市场的 SSD基本上都是SATA的，现在的 机械硬盘也是SATA接口居多。但速率上最高只能到 6Gb/s，上限 768MB/s左右，现在已经慢慢被pcie取代。
  • PCIe 支持速率更高，也离CPU最近。很多设备 如 网卡，显卡也都走pcie接口，当然也有SSD。现在比较主流的是PCIe 3.0,8Gb/s 看起来好像也没比 SATA 高多少，但是 PCIe 支持多个LANE，每个LANE都是 8Gb/s，这样性能就倍数增加了。目前，SSD主流的是 PCIe 3.0x4 lane，性能可以做到 3500MB/s 左右。

传输层协议

SCSI，ATA，NVMe 都属于这一层。主要是定义命令集，数字逻辑层。

  • SCSI 命令集 历史悠久，应用也很广泛。U盘，SAS 盘，还有手机上 UFS 之类很多设备都走的这个命令集。
  • ATA 则只是跑在SATA 协议上
  • NVMe 协议是有特意为 NAND 进行优化。相比于上面两者，效率更高。主要是跑在 PCIe 上的。当然，也有NVMe-MI，NVMe-of之类的。是个很好的传输层协议。

物理接口

M.2 , U.2 , AIC, NGFF 这些属于物理接口

像 M.2 可以是 SATA SSD 也可以是 NVMe（PCIe） SSD。金手指上有一个 SATA/PCIe 的选择信号，来区分两者。很多笔记本的M.2 接口也是同时支持两种类型的盘的。

  • M.2 , 主要用在 笔记本上，优点是体积小，缺点是散热不好。

  • U.2,主要用在 数据中心或者一些企业级用户，对热插拔需求高的地方。优点热插拔，散热也不错。一般主要是pcie ssd(也有sas ssd)，受限于接口，最多只能是 pcie 4lane

  • AIC，企业，行业用户用的比较多。通常会支持pcie 4lane/8lane，带宽上限更高

数据总结

  • 性能排序 NVMe SSD > SATA SSD > SAN > ESSD > HDD
  • 本地ssd性能最好、sas机械盘(RAID10)性能最差
  • san存储走特定的光纤网络，不是走tcp的san（至少从网卡看不到san的流量），性能居中
  • 从rt来看 ssd:san:sas 大概是 1:3:15
  • san比本地sas机械盘性能要好，这也许取决于san的网络传输性能和san存储中的设备（比如用的ssd而不是机械盘）
  • NVMe SSD比SATA SSD快很多，latency更稳定
  • 阿里云的云盘ESSD比本地SAS RAID10阵列性能还好

参考资料

http://cizixs.com/2017/01/03/how-slow-is-disk-and-network

https://tobert.github.io/post/2014-04-17-fio-output-explained.html

https://zhuanlan.zhihu.com/p/40497397

块存储NVMe云盘原型实践

机械硬盘随机IO慢的超乎你的想象

搭载固态硬盘的服务器究竟比搭机械硬盘快多少？

Linux

如何制作本地yum repository

如何制作本地yum repository

某些情况下在没有外网的环境需要安装一些软件，但是软件依赖比较多，那么可以提前将所有依赖下载到本地，然后将他们制作成一个yum repo，安装的时候就会自动将依赖包都安装好。

收集所有rpm包

创建一个文件夹，比如 Yum，将收集到的所有rpm包放在里面，比如安装ansible和docker需要的依赖文件：

1
2
3
4
5
6
7
8
9
10
11
12
-rwxr-xr-x 1 root root  73K 7月  12 14:22 audit-libs-python-2.8.4-4.el7.x86_64.rpm
-rwxr-xr-x 1 root root 295K 7月  12 14:22 checkpolicy-2.5-8.el7.x86_64.rpm
-rwxr-xr-x 1 root root  23M 7月  12 14:22 containerd.io-1.2.2-3.el7.x86_64.rpm
-rwxr-xr-x 1 root root  26K 7月  12 14:22 container-selinux-2.9-4.el7.noarch.rpm
-rwxr-xr-x 1 root root  37K 7月  12 14:22 container-selinux-2.74-1.el7.noarch.rpm
-rwxr-xr-x 1 root root  14M 7月  12 14:22 docker-ce-cli-18.09.0-3.el7.x86_64.rpm
-rwxr-xr-x 1 root root  29K 7月  12 14:22 docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch.rpm
-r-xr-xr-x 1 root root  22K 7月  12 14:23 sshpass-1.06-2.el7.x86_64.rpm
-r-xr-xr-x 1 root root  22K 7月  12 14:23 sshpass-1.06-1.el7.x86_64.rpm
-r-xr-xr-x 1 root root 154K 7月  12 14:23 PyYAML-3.10-11.el7.x86_64.rpm
-r-xr-xr-x 1 root root  29K 7月  12 14:23 python-six-1.9.0-2.el7.noarch.rpm
-r-xr-xr-x 1 root root 397K 7月  12 14:23 python-setuptools-0.9.8-7.el7.noarch.rpm

收集方法：

1
2
3
4
5
6
7
8
//先安装yum工具
yum install yum-utils -y
//将 ansible 依赖包都下载下来
repoquery --requires --resolve --recursive ansible | xargs -r yumdownloader --destdir=/tmp/ansible
//将ansible rpm自己下载回来
yumdownloader --destdir=/tmp/ansible --resolve ansible
//验证一下依赖关系是完整的
//repotrack ansible

创建仓库索引

需要安装工具 yum install createrepo -y：

1
2
3
4
5
6
7
8
9
10
# createrepo ./public_yum/
Spawning worker 0 with 6 pkgs
Spawning worker 1 with 6 pkgs
Spawning worker 23 with 5 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

会在yum文件夹下生成一个索引文件夹 repodata

1
2
3
4
5
6
7
8
9
drwxr-xr-x 2 root root 4.0K 7月  12 14:25 repodata
[root@az1-drds-79 yum]# ls repodata/
5e15c62fec1fe43c6025ecf4d370d632f4b3f607500016e045ad94b70f87bac3-filelists.xml.gz
7a314396d6e90532c5c534567f9bd34eee94c3f8945fc2191b225b2861ace2b6-other.xml.gz
ce9dce19f6b426b8856747b01d51ceaa2e744b6bbd5fbc68733aa3195f724590-primary.xml.gz
ee33b7d79e32fe6ad813af92a778a0ec8e5cc2dfdc9b16d0be8cff6a13e80d99-filelists.sqlite.bz2
f7e8177e7207a4ff94bade329a0f6b572a72e21da106dd9144f8b1cdf0489cab-primary.sqlite.bz2
ff52e1f1859790a7b573d2708b02404eb8b29aa4b0c337bda83af75b305bfb36-other.sqlite.bz2
repomd.xml

生成iso镜像文件

非必要步骤，如果需要带到客户环境可以先生成iso，不过不够灵活。

也可以不用生成iso，直接在drds.repo中指定 createrepo 的目录也可以，记得要先执行 yum clean all和yum update 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#mkisofs -r -o docker_ansible.iso ./yum/
I: -input-charset not specified, using utf-8 (detected in locale settings)
Using PYTHO000.RPM;1 for  /python-httplib2-0.7.7-3.el7.noarch.rpm (python-httplib2-0.9.1-3.el7.noarch.rpm)
Using MARIA006.RPM;1 for  /mariadb-5.5.56-2.el7.x86_64.rpm (mariadb-libs-5.5.56-2.el7.x86_64.rpm)
Using LIBTO001.RPM;1 for  /libtomcrypt-1.17-25.el7.x86_64.rpm (libtomcrypt-1.17-26.el7.x86_64.rpm)
  6.11% done, estimate finish Sun Jul 12 14:26:47 2020
 97.60% done, estimate finish Sun Jul 12 14:26:48 2020
Total translation table size: 0
Total rockridge attributes bytes: 14838
Total directory bytes: 2048
Path table size(bytes): 26
Max brk space used 21000
81981 extents written (160 MB)

将 生成的 iso挂载到目标机器上

1
2
3
# mkdir /mnt/iso
# mount ./docker_ansible.iso /mnt/iso
mount: /dev/loop0 is write-protected, mounting read-only

配置本地 yum 源

yum repository不是必须要求iso挂载，直接指向rpm文件夹（必须要有 createrepo 建立索引了）也可以

1
2
3
4
5
6
7
8
9
# cat /etc/yum.repos.d/drds.repo 
[drds]
name=drds Extra Packages for Enterprise Linux 7 - $basearch
enabled=1
failovermethod=priority
baseurl=file:///mnt/repo #baseurl=http://192.168.1.91:8000/ 本地内网
priority=1  #添加priority=1，数字越小优先级越高，也可以修改网络源的priority的值
gpgcheck=0
#gpgkey=file:///mnt/cdrom/RPM-GPG-KEY-CentOS-5    #注：这个你cd /mnt/cdrom/可以看到这个key，这里仅仅是个例子， 因为gpgcheck是0 ，所以gpgkey不需要了

到此就可以在没有网络环境的机器上直接：yum install ansible docker -y 了

测试

测试的话可以指定repo 源： yum install ansible –enablerepo=drds （drds 优先级最高）

本地会cache一些rpm的版本信息，可以执行 yum clean all 得到一个干净的测试环境

1
2
3
yum clean all
yum list
yum deplist ansible

yum 源问题处理

Yum commands error “pycurl.so: undefined symbol”

xargs 作用

xargs命令的作用，是将标准输入转为命令行参数。因为有些命令是不接受标准输入的，比如echo

xargs的作用在于，大多数命令（比如rm、mkdir、ls）与管道一起使用时，都需要xargs将标准输入转为命令行参数。

dnf 使用

DNF 是新一代的rpm软件包管理器。他首先出现在 Fedora 18 这个发行版中。而最近，它取代了yum，正式成为 Fedora 22 的包管理器。

DNF包管理器克服了YUM包管理器的一些瓶颈，提升了包括用户体验，内存占用，依赖分析，运行速度等多方面的内容。DNF使用 RPM, libsolv 和 hawkey 库进行包管理操作。尽管它没有预装在 CentOS 和 RHEL 7 中，但你可以在使用 YUM 的同时使用 DNF 。你可以在这里获得关于 DNF 的更多知识：《 DNF 代替 YUM ，你所不知道的缘由》

DNF 包管理器作为 YUM 包管理器的升级替代品，它能自动完成更多的操作。但在我看来，正因如此，所以 DNF 包管理器不会太受那些经验老道的 Linux 系统管理者的欢迎。举例如下：

  1. 在 DNF 中没有 –skip-broken 命令，并且没有替代命令供选择。
  2. 在 DNF 中没有判断哪个包提供了指定依赖的 resolvedep 命令。
  3. 在 DNF 中没有用来列出某个软件依赖包的 deplist 命令。
  4. 当你在 DNF 中排除了某个软件库，那么该操作将会影响到你之后所有的操作，不像在 YUM 下那样，你的排除操作只会咋升级和安装软件时才起作用。

安装yum源

安装7.70版本curl yum源

1
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-2-1.rhel7.noarch.rpm

其它技巧

rpm依赖查询

1
2
3
4
rpm -q --whatprovides file-name //查询一个文件来自哪个rpm包
rpm -qf /usr/lib/systemd/libsystemd-shared-239.so // 查询一个so lib来自哪个rpm包
或者 yum whatprovides /usr/lib/systemd/libsystemd-shared-239.so
yum provides */libmysqlclient.so.18

制作debian 仓库

适合ubuntu、deepin、uos等, 参考：https://lework.github.io/2021/04/03/debian-kubeadm-install/

1
2
#添加新仓库
sudo apt-add-repository 'deb http://ftp.us.debian.org/debian stretch main contrib non-free'

img

rpm转换成 dpkg

apt-mirror

先要安装apt-mirror 工具，安装后会生成配置文件 /etc/apt/mirror.list 然后需要手工修改配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
#cat /etc/apt/mirror.list
############# config ##################

#下载下来的仓库文件放在哪里
set base_path    /polarx/debian

set mirror_path  $base_path/mirror
set skel_path    $base_path/skel
set var_path     $base_path/var
set cleanscript $var_path/clean.sh
set defaultarch  amd64
#set postmirror_script $var_path/postmirror.sh
set run_postmirror 0
set nthreads     20
set _tilde 0
#
############# end config ##############

#从哪里镜像仓库
deb http://yum.tbsite.net/mirrors/debian/ buster main non-free contrib
#deb https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main

#deb http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-src http://ftp.us.debian.org/debian unstable main contrib non-free

# mirror additional architectures
#deb-alpha http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-amd64 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-armel http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-hppa http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-i386 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-ia64 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-m68k http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-mips http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-mipsel http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-powerpc http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-s390 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-sparc http://ftp.us.debian.org/debian unstable main contrib non-free

#clean http://ftp.us.debian.org/debian
clean http://yum.tbsite.net/mirrors/debian/

debian仓库介绍

一个Debian仓库包含多个发行版。Debian 的发行版是以 “玩具总动员 “电影中的角色命名的 (wheezy, jessie, stretch, …)。 代号有别名，叫做套件(stable, oldstable, testing, unstable)。一个发行版会被分成几个组件。在 Debian 中，这些组件被命名为 main, contrib, 和 non-free，并表并表示它们所包含的软件的授权条款。一个版本也有各种架构(amd64, i386, mips, powerpc, s390x, …)的软件包，以及源码和架构独立的软件包。

仓库的根目录下有一个dists 目录，而这个目录又有每个发行版和套件的目录，后者通常是前者的符号链接，但浏览器不会向您显示出这个区别。每个发行版子目录都包含一个加密签名的Release文件和每个组件的目录，里面是不同架构的目录，名为binary-*<架构>*和sources。而在这些文件中，Packages是文本文件，包含了软件包。嗯，那么实际的软件包在哪里？

image-20220829163817671

软件包本身在仓库根目录下的pool。在pool下面又有所有组件的目录，其中有0，…，9，a，b，.., z, liba, … , libz。 而在这些目录中，是以它们所包含的软件包命名的目录，这些目录最后包含实际的软件包，即.deb文件。这个名字不一定是软件包本身的名字，例如，软件包bsdutils在目录pool/main/u/util-linux 下，它是生成软件包的源码的名称。一个上游源可能会生成多个二进制软件包，而所有这些软件包最终都会在pool下面的同一个子目录中。额外的单字母目录只是一个技巧，以避免在一个目录中有太多的条目，因为这是很多系统传统上存在性能问题的原因。

在pool下面的子目录中，通常会有多个版本的软件包，而每个版本的软件包属于什么发行版的信息只存在于索引中。这样一来，同一个版本的包可软件以属于多个发行版，但只使用一次磁盘空间，而且不需要求助于硬链接或符号链接，所以镜像相当简单，甚至可以在没有这些概念的系统中进行。

常用命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
apt install kubeadm=1.20.12-00 //指定版本安装

#查询可用版本
apt-cache policy kubeadm
apt list --all-versions kubeadm

#清理
apt clean --dry-run 
apt update
apt list
apt show kubeadm

#查询安装包的所有文件
dpkg-query -L kubeadm

#列出所有依赖包
apt-cache depends ansible

#被依赖查询
apt-cache rdepends kubelet

dpkg -I kubernetes/pool/kubeadm_1.21.0-00_amd64.deb

#下载依赖包
apt-get download $(apt-rdepends kubeadm|grep -v "^ ")
aptitude --download-only -y install $(apt-rdepends kubeadm|grep -v "^ ") //不能下载已经安装了的依赖包

apt download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances kubeadm | grep "^\w" | sort -u)

简单仓库

下载所有 deb 包以及他们的依赖

1
apt download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances kubeadm | grep "^\w" | sort -u)

生成 index

1
dpkg-scanpackages -m . > Packages

apt source 指向这个目录

1
deb [trusted=yes] file:/polarx/test /

Kubernetes 仓库

debian 上通过kubeadm 安装 kubernetes 集群

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
//官方
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | tee -a /etc/apt/sources.list.d/kubernetes.list

//阿里云仓库
echo 'deb https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main' > /etc/apt/sources.list.d/kubernetes.list
curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -
apt-get update

export KUBE_VERSION="1.20.5"
apt-get install -y kubeadm=$KUBE_VERSION-00 kubelet=$KUBE_VERSION-00 kubectl=$KUBE_VERSION-00
sudo apt-mark hold kubelet kubeadm kubectl

[ -d /etc/bash_completion.d ] && \
    { kubectl completion bash > /etc/bash_completion.d/kubectl; \
      kubeadm completion bash > /etc/bash_completion.d/kubadm; }
      
[ ! -d /usr/lib/systemd/system/kubelet.service.d ] && mkdir -p /usr/lib/systemd/system/kubelet.service.d
cat << EOF > /usr/lib/systemd/system/kubelet.service.d/11-cgroup.conf
[Service]
CPUAccounting=true
MemoryAccounting=true
BlockIOAccounting=true
ExecStartPre=/usr/bin/bash -c '/usr/bin/mkdir -p /sys/fs/cgroup/{cpuset,memory,systemd,pids,"cpu,cpuacct"}/{system,kube,kubepods}.slice'
Slice=kube.slice
EOF
systemctl daemon-reload
 
systemctl enable kubelet.service

docker 仓库

1
2
3
4
5
6
7
apt-get install -y apt-transport-https ca-certificates curl gnupg2 lsb-release bash-completion
    
curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/debian/gpg | sudo apt-key add -
echo "deb [arch=amd64] https://mirrors.aliyun.com/docker-ce/linux/debian $(lsb_release -cs)   stable" > /etc/apt/sources.list.d/docker-ce.list
sudo apt-get update
apt-get install -y docker-ce docker-ce-cli containerd.io
apt-mark hold docker-ce docker-ce-cli containerd.io

参考资料

xargs 命令教程

Linux

如何制作本地软件仓库

如何制作软件仓库

某些情况下在没有外网的环境需要安装一些软件，但是软件依赖比较多，那么可以提前将所有依赖下载到本地，然后将他们制作成一个yum repo，安装的时候就会自动将依赖包都安装好。

centos下是 yum 仓库，Debian、ubuntu下是apt仓库，我们先讲 yum 仓库的制作，Debian apt 仓库类似

收集所有rpm包

创建一个文件夹，比如 Yum，将收集到的所有rpm包放在里面，比如安装ansible和docker需要的依赖文件：

1
2
3
4
5
6
7
8
9
10
11
12
-rwxr-xr-x 1 root root  73K 7月  12 14:22 audit-libs-python-2.8.4-4.el7.x86_64.rpm
-rwxr-xr-x 1 root root 295K 7月  12 14:22 checkpolicy-2.5-8.el7.x86_64.rpm
-rwxr-xr-x 1 root root  23M 7月  12 14:22 containerd.io-1.2.2-3.el7.x86_64.rpm
-rwxr-xr-x 1 root root  26K 7月  12 14:22 container-selinux-2.9-4.el7.noarch.rpm
-rwxr-xr-x 1 root root  37K 7月  12 14:22 container-selinux-2.74-1.el7.noarch.rpm
-rwxr-xr-x 1 root root  14M 7月  12 14:22 docker-ce-cli-18.09.0-3.el7.x86_64.rpm
-rwxr-xr-x 1 root root  29K 7月  12 14:22 docker-ce-selinux-17.03.2.ce-1.el7.centos.noarch.rpm
-r-xr-xr-x 1 root root  22K 7月  12 14:23 sshpass-1.06-2.el7.x86_64.rpm
-r-xr-xr-x 1 root root  22K 7月  12 14:23 sshpass-1.06-1.el7.x86_64.rpm
-r-xr-xr-x 1 root root 154K 7月  12 14:23 PyYAML-3.10-11.el7.x86_64.rpm
-r-xr-xr-x 1 root root  29K 7月  12 14:23 python-six-1.9.0-2.el7.noarch.rpm
-r-xr-xr-x 1 root root 397K 7月  12 14:23 python-setuptools-0.9.8-7.el7.noarch.rpm

收集方法：

1
2
3
4
5
6
7
8
//先安装yum工具
yum install yum-utils -y
//将 ansible 依赖包都下载下来
repoquery --requires --resolve --recursive ansible | xargs -r yumdownloader --destdir=/tmp/ansible
//将ansible rpm自己下载回来
yumdownloader --destdir=/tmp/ansible --resolve ansible
//验证一下依赖关系是完整的
//repotrack ansible

创建仓库索引

需要安装工具 yum install createrepo -y：

1
2
3
4
5
6
7
8
9
10
# createrepo ./public_yum/
Spawning worker 0 with 6 pkgs
Spawning worker 1 with 6 pkgs
Spawning worker 23 with 5 pkgs
Workers Finished
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete

会在yum文件夹下生成一个索引文件夹 repodata

1
2
3
4
5
6
7
8
9
drwxr-xr-x 2 root root 4.0K 7月  12 14:25 repodata
[root@az1-drds-79 yum]# ls repodata/
5e15c62fec1fe43c6025ecf4d370d632f4b3f607500016e045ad94b70f87bac3-filelists.xml.gz
7a314396d6e90532c5c534567f9bd34eee94c3f8945fc2191b225b2861ace2b6-other.xml.gz
ce9dce19f6b426b8856747b01d51ceaa2e744b6bbd5fbc68733aa3195f724590-primary.xml.gz
ee33b7d79e32fe6ad813af92a778a0ec8e5cc2dfdc9b16d0be8cff6a13e80d99-filelists.sqlite.bz2
f7e8177e7207a4ff94bade329a0f6b572a72e21da106dd9144f8b1cdf0489cab-primary.sqlite.bz2
ff52e1f1859790a7b573d2708b02404eb8b29aa4b0c337bda83af75b305bfb36-other.sqlite.bz2
repomd.xml

生成iso镜像文件

非必要步骤，如果需要带到客户环境可以先生成iso，不过不够灵活。

也可以不用生成iso，直接在drds.repo中指定 createrepo 的目录也可以，记得要先执行 yum clean all和yum update 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#mkisofs -r -o docker_ansible.iso ./yum/
I: -input-charset not specified, using utf-8 (detected in locale settings)
Using PYTHO000.RPM;1 for  /python-httplib2-0.7.7-3.el7.noarch.rpm (python-httplib2-0.9.1-3.el7.noarch.rpm)
Using MARIA006.RPM;1 for  /mariadb-5.5.56-2.el7.x86_64.rpm (mariadb-libs-5.5.56-2.el7.x86_64.rpm)
Using LIBTO001.RPM;1 for  /libtomcrypt-1.17-25.el7.x86_64.rpm (libtomcrypt-1.17-26.el7.x86_64.rpm)
  6.11% done, estimate finish Sun Jul 12 14:26:47 2020
 97.60% done, estimate finish Sun Jul 12 14:26:48 2020
Total translation table size: 0
Total rockridge attributes bytes: 14838
Total directory bytes: 2048
Path table size(bytes): 26
Max brk space used 21000
81981 extents written (160 MB)

将 生成的 iso挂载到目标机器上

1
2
3
# mkdir /mnt/iso
# mount ./docker_ansible.iso /mnt/iso
mount: /dev/loop0 is write-protected, mounting read-only

配置本地 yum 源

yum repository不是必须要求iso挂载，直接指向rpm文件夹（必须要有 createrepo 建立索引了）也可以

1
2
3
4
5
6
7
8
9
# cat /etc/yum.repos.d/drds.repo 
[drds]
name=drds Extra Packages for Enterprise Linux 7 - $basearch
enabled=1
failovermethod=priority
baseurl=file:///mnt/repo #baseurl=http://192.168.1.91:8000/ 本地内网
priority=1  #添加priority=1，数字越小优先级越高，也可以修改网络源的priority的值
gpgcheck=0
#gpgkey=file:///mnt/cdrom/RPM-GPG-KEY-CentOS-5    #注：这个你cd /mnt/cdrom/可以看到这个key，这里仅仅是个例子， 因为gpgcheck是0 ，所以gpgkey不需要了

到此就可以在没有网络环境的机器上直接：yum install ansible docker -y 了

测试

测试的话可以指定repo 源： yum install ansible –enablerepo=drds （drds 优先级最高）

本地会cache一些rpm的版本信息，可以执行 yum clean all 得到一个干净的测试环境

1
2
3
yum clean all
yum list
yum deplist ansible

yum 源问题处理

Yum commands error “pycurl.so: undefined symbol”

xargs 作用

xargs命令的作用，是将标准输入转为命令行参数。因为有些命令是不接受标准输入的，比如echo

xargs的作用在于，大多数命令（比如rm、mkdir、ls）与管道一起使用时，都需要xargs将标准输入转为命令行参数。

dnf 使用

DNF 是新一代的rpm软件包管理器。他首先出现在 Fedora 18 这个发行版中。而最近，它取代了yum，正式成为 Fedora 22 的包管理器。

DNF包管理器克服了YUM包管理器的一些瓶颈，提升了包括用户体验，内存占用，依赖分析，运行速度等多方面的内容。DNF使用 RPM, libsolv 和 hawkey 库进行包管理操作。尽管它没有预装在 CentOS 和 RHEL 7 中，但你可以在使用 YUM 的同时使用 DNF 。你可以在这里获得关于 DNF 的更多知识：《 DNF 代替 YUM ，你所不知道的缘由》

DNF 包管理器作为 YUM 包管理器的升级替代品，它能自动完成更多的操作。但在我看来，正因如此，所以 DNF 包管理器不会太受那些经验老道的 Linux 系统管理者的欢迎。举例如下：

  1. 在 DNF 中没有 –skip-broken 命令，并且没有替代命令供选择。
  2. 在 DNF 中没有判断哪个包提供了指定依赖的 resolvedep 命令。
  3. 在 DNF 中没有用来列出某个软件依赖包的 deplist 命令。
  4. 当你在 DNF 中排除了某个软件库，那么该操作将会影响到你之后所有的操作，不像在 YUM 下那样，你的排除操作只会咋升级和安装软件时才起作用。

安装yum源

安装7.70版本curl yum源

1
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-2-1.rhel7.noarch.rpm

其它技巧

rpm依赖查询

1
2
3
4
rpm -q --whatprovides file-name //查询一个文件来自哪个rpm包
rpm -qf /usr/lib/systemd/libsystemd-shared-239.so // 查询一个so lib来自哪个rpm包
或者 yum whatprovides /usr/lib/systemd/libsystemd-shared-239.so
yum provides */libmysqlclient.so.18

制作debian 仓库

适合ubuntu、deepin、uos等, 参考：https://lework.github.io/2021/04/03/debian-kubeadm-install/

1
2
#添加新仓库
sudo apt-add-repository 'deb http://ftp.us.debian.org/debian stretch main contrib non-free'

img

rpm转换成 dpkg

apt-mirror

先要安装apt-mirror 工具，安装后会生成配置文件 /etc/apt/mirror.list 然后需要手工修改配置文件：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
#cat /etc/apt/mirror.list
############# config ##################

#下载下来的仓库文件放在哪里
set base_path    /polarx/debian

set mirror_path  $base_path/mirror
set skel_path    $base_path/skel
set var_path     $base_path/var
set cleanscript $var_path/clean.sh
set defaultarch  amd64
#set postmirror_script $var_path/postmirror.sh
set run_postmirror 0
set nthreads     20
set _tilde 0
#
############# end config ##############

#从哪里镜像仓库
deb http://yum.tbsite.net/mirrors/debian/ buster main non-free contrib
#deb https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main

#deb http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-src http://ftp.us.debian.org/debian unstable main contrib non-free

# mirror additional architectures
#deb-alpha http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-amd64 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-armel http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-hppa http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-i386 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-ia64 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-m68k http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-mips http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-mipsel http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-powerpc http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-s390 http://ftp.us.debian.org/debian unstable main contrib non-free
#deb-sparc http://ftp.us.debian.org/debian unstable main contrib non-free

#clean http://ftp.us.debian.org/debian
clean http://yum.tbsite.net/mirrors/debian/

debian仓库介绍

一个Debian仓库包含多个发行版。Debian 的发行版是以 “玩具总动员 “电影中的角色命名的 (wheezy, jessie, stretch, …)。 代号有别名，叫做套件(stable, oldstable, testing, unstable)。一个发行版会被分成几个组件。在 Debian 中，这些组件被命名为 main, contrib, 和 non-free，并表并表示它们所包含的软件的授权条款。一个版本也有各种架构(amd64, i386, mips, powerpc, s390x, …)的软件包，以及源码和架构独立的软件包。

仓库的根目录下有一个dists 目录，而这个目录又有每个发行版和套件的目录，后者通常是前者的符号链接，但浏览器不会向您显示出这个区别。每个发行版子目录都包含一个加密签名的Release文件和每个组件的目录，里面是不同架构的目录，名为binary-*<架构>*和sources。而在这些文件中，Packages是文本文件，包含了软件包。嗯，那么实际的软件包在哪里？

image-20220829163817671

软件包本身在仓库根目录下的pool。在pool下面又有所有组件的目录，其中有0，…，9，a，b，.., z, liba, … , libz。 而在这些目录中，是以它们所包含的软件包命名的目录，这些目录最后包含实际的软件包，即.deb文件。这个名字不一定是软件包本身的名字，例如，软件包bsdutils在目录pool/main/u/util-linux 下，它是生成软件包的源码的名称。一个上游源可能会生成多个二进制软件包，而所有这些软件包最终都会在pool下面的同一个子目录中。额外的单字母目录只是一个技巧，以避免在一个目录中有太多的条目，因为这是很多系统传统上存在性能问题的原因。

在pool下面的子目录中，通常会有多个版本的软件包，而每个版本的软件包属于什么发行版的信息只存在于索引中。这样一来，同一个版本的包可软件以属于多个发行版，但只使用一次磁盘空间，而且不需要求助于硬链接或符号链接，所以镜像相当简单，甚至可以在没有这些概念的系统中进行。

常用命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
apt install kubeadm=1.20.12-00 //指定版本安装

#查询可用版本
apt-cache policy kubeadm
apt list --all-versions kubeadm

#清理
apt clean --dry-run 
apt update
apt list
apt show kubeadm

#查询安装包的所有文件
dpkg-query -L kubeadm

#列出所有依赖包
apt-cache depends ansible

#被依赖查询
apt-cache rdepends kubelet

dpkg -I kubernetes/pool/kubeadm_1.21.0-00_amd64.deb

#下载依赖包
apt-get download $(apt-rdepends kubeadm|grep -v "^ ")
aptitude --download-only -y install $(apt-rdepends kubeadm|grep -v "^ ") //不能下载已经安装了的依赖包

apt download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances kubeadm | grep "^\w" | sort -u)

简单仓库

下载所有 deb 包以及他们的依赖

1
apt download $(apt-cache depends --recurse --no-recommends --no-suggests --no-conflicts --no-breaks --no-replaces --no-enhances kubeadm | grep "^\w" | sort -u)

到deb 包所在的目录下生成 index

1
dpkg-scanpackages -m . > Packages

apt source 指向这个目录

1
deb [trusted=yes] file:/polarx/test /

Kubernetes 仓库

debian 上通过kubeadm 安装 kubernetes 集群

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
//官方
echo "deb http://apt.kubernetes.io/ kubernetes-xenial main" | tee -a /etc/apt/sources.list.d/kubernetes.list

//阿里云仓库
echo 'deb https://mirrors.aliyun.com/kubernetes/apt kubernetes-xenial main' > /etc/apt/sources.list.d/kubernetes.list
curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg | sudo apt-key add -
apt-get update

export KUBE_VERSION="1.20.5"
apt-get install -y kubeadm=$KUBE_VERSION-00 kubelet=$KUBE_VERSION-00 kubectl=$KUBE_VERSION-00
sudo apt-mark hold kubelet kubeadm kubectl

[ -d /etc/bash_completion.d ] && \
    { kubectl completion bash > /etc/bash_completion.d/kubectl; \
      kubeadm completion bash > /etc/bash_completion.d/kubadm; }
      
[ ! -d /usr/lib/systemd/system/kubelet.service.d ] && mkdir -p /usr/lib/systemd/system/kubelet.service.d
cat << EOF > /usr/lib/systemd/system/kubelet.service.d/11-cgroup.conf
[Service]
CPUAccounting=true
MemoryAccounting=true
BlockIOAccounting=true
ExecStartPre=/usr/bin/bash -c '/usr/bin/mkdir -p /sys/fs/cgroup/{cpuset,memory,systemd,pids,"cpu,cpuacct"}/{system,kube,kubepods}.slice'
Slice=kube.slice
EOF
systemctl daemon-reload
 
systemctl enable kubelet.service

docker 仓库

1
2
3
4
5
6
7
apt-get install -y apt-transport-https ca-certificates curl gnupg2 lsb-release bash-completion
    
curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/debian/gpg | sudo apt-key add -
echo "deb [arch=amd64] https://mirrors.aliyun.com/docker-ce/linux/debian $(lsb_release -cs)   stable" > /etc/apt/sources.list.d/docker-ce.list
sudo apt-get update
apt-get install -y docker-ce docker-ce-cli containerd.io
apt-mark hold docker-ce docker-ce-cli containerd.io

锁定已安装版本

1
2
//锁定这三个软件的版本，避免意外升级导致版本错误：
sudo apt-mark hold kubeadm kubelet kubectl

参考资料

xargs 命令教程

docker

kubernetes service

kubernetes service 和 kube-proxy详解

service 模式

根据创建Service的type类型不同，可分成4种模式：

  • ClusterIP： 默认方式。根据是否生成ClusterIP又可分为普通Service和Headless Service两类：
    • 普通Service：通过为Kubernetes的Service分配一个集群内部可访问的固定虚拟IP（Cluster IP），实现集群内的访问。为最常见的方式。
    • Headless Service：该服务不会分配Cluster IP，也不通过kube-proxy做反向代理和负载均衡。而是通过DNS提供稳定的网络ID来访问，DNS会将headless service的后端直接解析为podIP列表。主要供StatefulSet中对应POD的序列用。
  • NodePort：除了使用Cluster IP之外，还通过将service的port映射到集群内每个节点的相同一个端口，实现通过nodeIP:nodePort从集群外访问服务。NodePort会RR转发给后端的任意一个POD，跟ClusterIP类似
  • LoadBalancer：和nodePort类似，不过除了使用一个Cluster IP和nodePort之外，还会向所使用的公有云申请一个负载均衡器，实现从集群外通过LB访问服务。在公有云提供的 Kubernetes 服务里，都使用了一个叫作 CloudProvider 的转接层，来跟公有云本身的 API 进行对接。所以，在上述 LoadBalancer 类型的 Service 被提交后，Kubernetes 就会调用 CloudProvider 在公有云上为你创建一个负载均衡服务，并且把被代理的 Pod 的 IP 地址配置给负载均衡服务做后端。
  • ExternalName：是 Service 的特例。此模式主要面向运行在集群外部的服务，通过它可以将外部服务映射进k8s集群，且具备k8s内服务的一些特征（如具备namespace等属性），来为集群内部提供服务。此模式要求kube-dns的版本为1.7或以上。这种模式和前三种模式（除headless service）最大的不同是重定向依赖的是dns层次，而不是通过kube-proxy。

service yaml案例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Service
metadata:
  name: nginx-ren
  labels:
    app: web
spec:
  type: NodePort
# clusterIP: None  
  ports:
  - port: 8080
    targetPort: 80
    nodePort: 30080
  selector:
    app: ren

ports 字段指定服务的端口信息：

  • port：虚拟 ip 要绑定的 port，每个 service 会创建出来一个虚拟 ip，通过访问 vip:port 就能获取服务的内容。这个 port 可以用户随机选取，因为每个服务都有自己的 vip，也不用担心冲突的情况
  • targetPort：pod 中暴露出来的 port，这是运行的容器中具体暴露出来的端口，一定不能写错–一般用name来代替具体的port
  • protocol：提供服务的协议类型，可以是 TCP 或者 UDP
  • nodePort： 仅在type为nodePort模式下有用，宿主机暴露端口

但是nodePort和loadbalancer可以被外部访问，loadbalancer需要一个外部ip，流量走外部ip进出

NodePort向外部暴露了多个宿主机的端口，外部可以部署负载均衡将这些地址配置进去。

默认情况下，服务会rr转发到可用的后端。如果希望保持会话（同一个 client 永远都转发到相同的 pod），可以把 service.spec.sessionAffinity 设置为 ClientIP。

1
2
3
4
5
6
7
8
9
10
iptables-save | grep 3306

iptables-save | grep KUBE-SERVICES

#iptables-save |grep KUBE-SVC-RVEVH2XMONK6VC5O
:KUBE-SVC-RVEVH2XMONK6VC5O - [0:0]
-A KUBE-SERVICES -d 10.10.70.95/32 -p tcp -m comment --comment "drds/mysql-read:mysql cluster IP" -m tcp --dport 3306 -j KUBE-SVC-RVEVH2XMONK6VC5O
-A KUBE-SVC-RVEVH2XMONK6VC5O -m comment --comment "drds/mysql-read:mysql" -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-XC4TZYIZFYB653VI
-A KUBE-SVC-RVEVH2XMONK6VC5O -m comment --comment "drds/mysql-read:mysql" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-MK4XPBZUIJGFXKED
-A KUBE-SVC-RVEVH2XMONK6VC5O -m comment --comment "drds/mysql-read:mysql" -j KUBE-SEP-AAYXWGQJBDHUJUQ3

看起来 service 是个完美的方案，可以解决服务访问的所有问题，但是 service 这个方案（iptables 模式）也有自己的缺点。

首先，如果转发的 pod 不能正常提供服务，它不会自动尝试另一个 pod，当然这个可以通过 readiness probes 来解决。每个 pod 都有一个健康检查的机制，当有 pod 健康状况有问题时，kube-proxy 会删除对应的转发规则。

另外，nodePort 类型的服务也无法添加 TLS 或者更复杂的报文路由机制。因为只做了NAT

NodePort 的一些问题

  • 首先endpoint回复不能走node 1给client，因为会被client reset（如果在node1上将src ip替换成node2的ip可能会路由不通）。回复包在 node1上要snat给node2
  • 经过snat后endpoint没法拿到client ip（slb之类是通过option带过来）
1
2
3
4
5
6
7
8
9
          client
            \ ^
             \ \
              v \
  node 1 <--- node 2
   | ^   SNAT
   | |   --->
   v |
endpoint

可以将 Service 的 spec.externalTrafficPolicy 字段设置为 local，这就保证了所有 Pod 通过 Service 收到请求之后，一定可以看到真正的、外部 client 的源地址。

而这个机制的实现原理也非常简单：这时候，一台宿主机上的 iptables 规则，会设置为只将 IP 包转发给运行在这台宿主机上的 Pod。所以这时候，Pod 就可以直接使用源地址将回复包发出，不需要事先进行 SNAT 了。这个流程，如下所示：

1
2
3
4
5
6
7
8
9
      client
      ^ /   \
     / /     \
    / v       X
  node 1     node 2
   ^ |
   | |
   | v
endpoint

当然，这也就意味着如果在一台宿主机上，没有任何一个被代理的 Pod 存在，比如上图中的 node 2，那么你使用 node 2 的 IP 地址访问这个 Service，就是无效的。此时，你的请求会直接被 DROP 掉。

Service和kube-proxy的工作原理

kube-proxy有两种主要的实现（userspace基本没有使用了）：

  • [[iptables使用]]来做NAT以及负载均衡
  • ipvs来做NAT以及负载均衡

Service 是由 kube-proxy 组件通过监听 Pod 的变化事件，在宿主机上维护iptables规则或者ipvs规则。

Kube-proxy 主要监听两个对象，一个是 Service，一个是 Endpoint，监听他们启停。以及通过selector将他们绑定。

IPVS 是专门为LB设计的。它用hash table管理service，对service的增删查找都是*O(1)*的时间复杂度。不过IPVS内核模块没有SNAT功能，因此借用了iptables的SNAT功能。IPVS 针对报文做DNAT后，将连接信息保存在nf_conntrack中，iptables据此接力做SNAT。该模式是目前Kubernetes网络性能最好的选择。但是由于nf_conntrack的复杂性，带来了很大的性能损耗。

iptables 实现负载均衡的工作流程

如果kube-proxy不是用的ipvs模式，那么主要靠iptables来做DNAT和SNAT以及负载均衡

iptables+clusterIP工作流程：

  1. 集群内访问svc 10.10.35.224:3306 命中 kube-services iptables
  2. iptables 规则：KUBE-SEP-F4QDAAVSZYZMFXZQ 对应到 KUBE-SEP-F4QDAAVSZYZMFXZQ
  3. KUBE-SEP-F4QDAAVSZYZMFXZQ 指示 DNAT到 宿主机：192.168.0.83:10379（在内核中将包改写了ip port）
  4. 从svc description中可以看到这个endpoint的地址 192.168.0.83:10379（pod使用Host network）

image.png

在对应的宿主机上可以清楚地看到容器中的mysqld进程正好监听着 10379端口

1
2
3
4
5
6
7
8
[root@az1-drds-83 ~]# ss -lntp |grep 10379
LISTEN     0      128         :::10379                   :::*                   users:(("mysqld",pid=17707,fd=18))
[root@az1-drds-83 ~]# ps auxff | grep 17707 -B2
root     13606  0.0  0.0  10720  3764 ?        Sl   17:09   0:00  \_ containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/ead57b52b11902b9b5004db0b72abb060b56a1af7ee7ad7066bd09c946abcb97 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc

root     13624  0.0  0.0 103044 10424 ?        Ss   17:09   0:00  |   \_ python /entrypoint.py
root     14835  0.0  0.0  11768  1636 ?        S    17:10   0:00  |   \_ /bin/sh /u01/xcluster/bin/mysqld_safe --defaults-file=/home/mysql/my10379.cnf
alidb    17707  0.6  0.0 1269128 67452 ?       Sl   17:10   0:25  |       \_ /u01/xcluster_20200303/bin/mysqld --defaults-file=/home/mysql/my10379.cnf --basedir=/u01/xcluster_20200303 --datadir=/home/mysql/data10379/dbs10379 --plugin-dir=/u01/xcluster_20200303/lib/plugin --user=mysql --log-error=/home/mysql/data10379/mysql/master-error.log --open-files-limit=8192 --pid-file=/home/mysql/data10379/dbs10379/az1-drds-83.pid --socket=/home/mysql/data10379/tmp/mysql.sock --port=10379

对应的这个pod的description：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#kubectl describe pod apsaradbcluster010-cv6w
Name:         apsaradbcluster010-cv6w
Namespace:    default
Priority:     0
Node:         az1-drds-83/192.168.0.83
Start Time:   Thu, 10 Sep 2020 17:09:33 +0800
Labels:       alisql.clusterName=apsaradbcluster010
              alisql.pod_name=apsaradbcluster010-cv6w
              alisql.pod_role=leader
Annotations:  apsara.metric.pod_name: apsaradbcluster010-cv6w
Status:       Running
IP:           192.168.0.83
IPs:
  IP:           192.168.0.83
Controlled By:  ApsaradbCluster/apsaradbcluster010
Containers:
  engine:
    Container ID:   docker://ead57b52b11902b9b5004db0b72abb060b56a1af7ee7ad7066bd09c946abcb97
    Image:          reg.docker.alibaba-inc.com/apsaradb/alisqlcluster-engine:develop-20200910140415
    Image ID:       docker://sha256:7ad5cc53c87b34806eefec829d70f5f0192f4127c7ee4e867cb3da3bb6c2d709
    Ports:          10379/TCP, 20383/TCP, 46846/TCP
    Host Ports:     10379/TCP, 20383/TCP, 46846/TCP
    State:          Running
      Started:      Thu, 10 Sep 2020 17:09:35 +0800
    Ready:          True
    Restart Count:  0
    Environment:
      ALISQL_POD_NAME:  apsaradbcluster010-cv6w (v1:metadata.name)
      ALISQL_POD_PORT:  10379
    Mounts:
      /dev/shm from devshm (rw)
      /etc/localtime from etclocaltime (rw)
      /home/mysql/data from data-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-n2bmn (ro)
  exporter:
    Container ID:  docker://b49865b7798f9036b431203d54994ac8fdfcadacb01a2ab4494b13b2681c482d
    Image:         reg.docker.alibaba-inc.com/apsaradb/alisqlcluster-exporter:latest
    Image ID:      docker://sha256:432cdd0a0e7c74c6eb66551b6f6af9e4013f60fb07a871445755f6577b44da19
    Port:          47272/TCP
    Host Port:     47272/TCP
    Args:
      --web.listen-address=:47272
      --collect.binlog_size
      --collect.engine_innodb_status
      --collect.info_schema.innodb_metrics
      --collect.info_schema.processlist
      --collect.info_schema.tables
      --collect.info_schema.tablestats
      --collect.slave_hosts
    State:          Running
      Started:      Thu, 10 Sep 2020 17:09:35 +0800
    Ready:          True
    Restart Count:  0
    Environment:
      ALISQL_POD_NAME:   apsaradbcluster010-cv6w (v1:metadata.name)
      DATA_SOURCE_NAME:  root:@(127.0.0.1:10379)/
    Mounts:
      /dev/shm from devshm (rw)
      /etc/localtime from etclocaltime (rw)
      /home/mysql/data from data-dir (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-n2bmn (ro)

DNAT 规则的作用，就是在 PREROUTING 检查点之前，也就是在路由之前，将流入 IP 包的目的地址和端口，改成–to-destination 所指定的新的目的地址和端口。可以看到，这个目的地址和端口，正是被代理 Pod 的 IP 地址和端口。

哪些组件会修改iptables

image.png

ipvs 实现负载均衡的原理

ipvs模式下，kube-proxy会先创建虚拟网卡，kube-ipvs0下面的每个ip都对应着svc的一个clusterIP：

1
2
3
4
5
6
# ip addr
  ...
5: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default 
    link/ether de:29:17:2a:8d:79 brd ff:ff:ff:ff:ff:ff
    inet 10.68.70.130/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever

kube-ipvs0下面绑的这些ip就是在发包的时候让内核知道如果目标ip是这些地址的话，这些地址是自身的所以包不会发出去，而是给INPUT链，这样ipvs内核模块有机会改写包做完NAT后再发走。

ipvs会放置DNAT钩子在INPUT链上，因此必须要让内核识别 VIP 是本机的 IP。这样才会过INPUT 链，要不然就通过OUTPUT链出去了。k8s 通过kube-proxy将service cluster ip 绑定到虚拟网卡kube-ipvs0。

同时在路由表中增加一些ipvs 的路由条目：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# ip route show table local
local 10.68.0.1 dev kube-ipvs0 proto kernel scope host src 10.68.0.1 
local 10.68.0.2 dev kube-ipvs0 proto kernel scope host src 10.68.0.2 
local 10.68.70.130 dev kube-ipvs0 proto kernel scope host src 10.68.70.130 -- ipvs
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 
broadcast 172.17.0.0 dev docker0 proto kernel scope link src 172.17.0.1 
local 172.17.0.1 dev docker0 proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 proto kernel scope link src 172.17.0.1 
local 172.20.185.192 dev tunl0 proto kernel scope host src 172.20.185.192 
broadcast 172.20.185.192 dev tunl0 proto kernel scope link src 172.20.185.192 
broadcast 172.26.128.0 dev eth0 proto kernel scope link src 172.26.137.117 
local 172.26.137.117 dev eth0 proto kernel scope host src 172.26.137.117 
broadcast 172.26.143.255 dev eth0 proto kernel scope link src 172.26.137.117

而接下来，kube-proxy 就会通过 Linux 的 IPVS 模块，为这个 IP 地址设置三个 IPVS 虚拟主机，并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略。我们可以通过 ipvsadm 查看到这个设置，如下所示：

1
2
3
4
5
ipvsadm -ln |grep 10.68.114.131 -A5
TCP  10.68.114.131:3306 rr
  -> 172.20.120.143:3306          Masq    1      0          0         
  -> 172.20.185.209:3306          Masq    1      0          0         
  -> 172.20.248.143:3306          Masq    1      0          0

172.20.. 是后端真正pod的ip， 10.68.114.131 是cluster-ip.

完整的工作流程如下：

  1. 因为service cluster ip 绑定到虚拟网卡kube-ipvs0上，内核可以识别访问的 VIP 是本机的 IP.
  2. 数据包到达INPUT链.
  3. ipvs监听到达input链的数据包，比对数据包请求的服务是为集群服务，修改数据包的目标IP地址为对应pod的IP，然后将数据包发至POSTROUTING链.
  4. 数据包经过POSTROUTING链选路由后，将数据包通过tunl0网卡(calico网络模型)发送出去。从tunl0虚拟网卡获得源IP.
  5. 经过tunl0后进行ipip封包，丢到物理网络，路由到目标node（目标pod所在的node）
  6. 目标node进行ipip解包后给pod对应的网卡
  7. pod接收到请求之后，构建响应报文，改变源地址和目的地址，返回给客户端。

image.png

ipvs实际案例

ipvs负载均衡下一次完整的syn握手抓包。

宿主机上访问 curl clusterip+port 后因为这个ip绑定在kube-ipvs0上，本来是应该发出去的包（prerouting）但是内核认为这个包是访问自己，于是给INPUT链，接着被ipvs放置在INPUT中的DNAT钩子勾住，将dest ip根据负载均衡逻辑改成pod-ip，然后将数据包再发至POSTROUTING链。这时因为目标ip是POD-IP了，根据ip route 选择到出口网卡是tunl0。

可以看下内核中的路由规则：

1
2
3
4
5
# ip route get 10.68.70.130
local 10.68.70.130 dev lo src 10.68.70.130  //这条规则指示了clusterIP是发给自己的
    cache <local> 
# ip route get 172.20.185.217
172.20.185.217 via 172.26.137.117 dev tunl0 src 172.20.22.192  //这条规则指示clusterIP替换成POD IP后发给本地tunl0做ipip封包

于是cip变成了tunl0的IP，这个tunl0是ipip模式，于是将这个包打包成ipip，也就是外层sip、dip都是宿主机ip，再将这个包丢入到物理网络

网络收包到达内核后的处理流程如下，核心都是查路由表，出包也会查路由表（判断是否本机内部通信，或者外部通信的话需要选用哪个网卡）

补两张内核netfilter框架的图：

packet filtering in IPTables

image.png

完整版：

image.png

ipvs的一些分析

ipvs是一个内核态的四层负载均衡，支持NAT以及IPIP隧道模式，但LB和RS不能跨子网，IPIP性能次之，通过ipip隧道解决跨网段传输问题，因此能够支持跨子网。而NAT模式没有限制，这也是唯一一种支持端口映射的模式。

但是ipvs只有NAT（也就是DNAT），NAT也俗称三角模式，要求RS和LVS 在一个二层网络，并且LVS是RS的网关，这样回包一定会到网关，网关再次做SNAT，这样client看到SNAT后的src ip是LVS ip而不是RS-ip。默认实现不支持ful-NAT，所以像公有云厂商为了适应公有云场景基本都会定制实现ful-NAT模式的lvs。

我们不难猜想，由于Kubernetes Service需要使用端口映射功能，因此kube-proxy必然只能使用ipvs的NAT模式。

如下Masq表示MASQUERADE（也就是SNAT），跟iptables里面的 MASQUERADE 是一个意思

1
2
3
# ipvsadm -L -n  |grep 70.130 -A12
TCP  10.68.70.130:12380 rr
  -> 172.20.185.217:9376          Masq    1      0          0

kuberletes对iptables的修改(图中黄色部分)：

image.png

kube-proxy

在 Kubernetes v1.0 版本，代理完全在 userspace 实现。Kubernetes v1.1 版本新增了 iptables 代理模式，但并不是默认的运行模式。从 Kubernetes v1.2 起，默认使用 iptables 代理。在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理模式

kube-proxy相当于service的管控方，业务流量不会走到kube-proxy，业务流量的负载均衡都是由内核层面的iptables或者ipvs来分发。

kube-proxy的三种模式：

image.png

一直以来，基于 iptables 的 Service 实现，都是制约 Kubernetes 项目承载更多量级的 Pod 的主要障碍。

ipvs 就是用于解决在大量 Service 时，iptables 规则同步变得不可用的性能问题。与 iptables 比较像的是，ipvs 的实现虽然也基于 netfilter 的钩子函数，但是它却使用哈希表作为底层的数据结构并且工作在内核态，这也就是说 ipvs 在重定向流量和同步代理规则有着更好的性能。

除了能够提升性能之外，ipvs 也提供了多种类型的负载均衡算法，除了最常见的 Round-Robin 之外，还支持最小连接、目标哈希、最小延迟等算法，能够很好地提升负载均衡的效率。

而相比于 iptables，IPVS 在内核中的实现其实也是基于 Netfilter 的 NAT 模式，所以在转发这一层上，理论上 IPVS 并没有显著的性能提升。但是，IPVS 并不需要在宿主机上为每个 Pod 设置 iptables 规则，而是把对这些“规则”的处理放到了内核态，从而极大地降低了维护这些规则的代价，“将重要操作放入内核态”是提高性能的重要手段。

IPVS 模块只负责上述的负载均衡和代理功能。而一个完整的 Service 流程正常工作所需要的包过滤、SNAT 等操作，还是要靠 iptables 来实现。只不过，这些辅助性的 iptables 规则数量有限，也不会随着 Pod 数量的增加而增加。

ipvs 和 iptables 都是基于 Netfilter 实现的。

Kubernetes 中已经使用 ipvs 作为 kube-proxy 的默认代理模式。

1
/opt/kube/bin/kube-proxy --bind-address=172.26.137.117 --cluster-cidr=172.20.0.0/16 --hostname-override=172.26.137.117 --kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig --logtostderr=true --proxy-mode=ipvs

image.png

为什么clusterIP不能ping通

集群内访问cluster ip（不能ping，只能cluster ip+port）就是在到达网卡之前被内核iptalbes做了dnat/snat, cluster IP是一个虚拟ip，可以针对具体的服务固定下来，这样服务后面的pod可以随便变化。

iptables模式的svc会ping不通clusterIP，可以看如下iptables和route（留意：–reject-with icmp-port-unreachable）：

1
2
3
4
5
6
7
8
9
10
11
12
13
#ping 10.96.229.40
PING 10.96.229.40 (10.96.229.40) 56(84) bytes of data.
^C
--- 10.96.229.40 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms


#iptables-save |grep 10.96.229.40
-A KUBE-SERVICES -d 10.96.229.40/32 -p tcp -m comment --comment "***-service:https has no endpoints" -m tcp --dport 8443 -j REJECT --reject-with icmp-port-unreachable

#ip route get 10.96.229.40
10.96.229.40 via 11.164.219.253 dev eth0  src 11.164.219.119 
    cache

准确来说如果用ipvs实现的clusterIP是可以ping通的：

  • 如果用iptables 来做转发是ping不通的，因为iptables里面这条规则只处理tcp包，reject了icmp
  • ipvs实现的clusterIP都能ping通
  • ipvs下的clusterIP ping通了也不是转发到pod，ipvs负载均衡只转发tcp协议的包
  • ipvs 的clusterIP在本地配置了route路由到回环网卡，这个包是lo网卡回复的

ipvs实现的clusterIP，在本地有添加路由到lo网卡

image.png

然后在本机抓包（到ipvs后端的pod上抓不到icmp包）：

image.png

从上面可以看出显然ipvs只会转发tcp包到后端pod，所以icmp包不会通过ipvs转发到pod上，同时在本地回环网卡lo上抓到了进去的icmp包。因为本地添加了一条路由规则，目标clusterIP被指示发到lo网卡上，lo网卡回复了这个ping包，所以通了。

port-forward

port-forward后外部也能够像nodePort一样访问到，但是port-forward不适合大流量，一般用于管理端口，启动的时候port-forward会固定转发到一个具体的Pod上，也没有负载均衡的能力。

1
2
#在本机监听1080端口，并转发给后端的svc/nginx-ren(总是给发给svc中的一个pod)
kubectl port-forward --address 0.0.0.0 svc/nginx-ren 1080:80

kubectl looks up a Pod from the service information provided on the command line and forwards directly to a Pod rather than forwarding to the ClusterIP/Service port and allowing the cluster to load balance the service like regular service traffic.

The portforward.go Complete function is where kubectl portforward does the first look up for a pod from options via AttachablePodForObjectFn:

The AttachablePodForObjectFn is defined as attachablePodForObject in this interface, then here is the attachablePodForObject function.

To my (inexperienced) Go eyes, it appears the attachablePodForObject is the thing kubectl uses to look up a Pod to from a Service defined on the command line.

Then from there on everything deals with filling in the Pod specific PortForwardOptions (which doesn’t include a service) and is passed to the kubernetes API.

Service 和 DNS 的关系

Service 和 Pod 都会被分配对应的 DNS A 记录（从域名解析 IP 的记录）。

对于 ClusterIP 模式的 Service 来说（比如我们上面的例子），它的 A 记录的格式是：..svc.cluster.local。当你访问这条 A 记录的时候，它解析到的就是该 Service 的 VIP 地址。

而对于指定了 clusterIP=None 的 Headless Service 来说，它的 A 记录的格式也是：..svc.cluster.local。但是，当你访问这条 A 记录的时候，它返回的是所有被代理的 Pod 的 IP 地址的集合。当然，如果你的客户端没办法解析这个集合的话，它可能会只会拿到第一个 Pod 的 IP 地址。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
#kubectl get pod -l app=mysql-r -o wide
NAME        READY   STATUS    RESTARTS IP               NODE          
mysql-r-0   2/2     Running   0        172.20.120.143   172.26.137.118
mysql-r-1   2/2     Running   4        172.20.248.143   172.26.137.116
mysql-r-2   2/2     Running   0        172.20.185.209   172.26.137.117

/ # nslookup mysql-r-1.mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r-1.mysql-r
Address 1: 172.20.248.143 mysql-r-1.mysql-r.default.svc.cluster.local
/ # 
/ # nslookup mysql-r-2.mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r-2.mysql-r
Address 1: 172.20.185.209 mysql-r-2.mysql-r.default.svc.cluster.local

#如果service是headless(也就是明确指定了 clusterIP: None)
/ # nslookup mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r
Address 1: 172.20.185.209 mysql-r-2.mysql-r.default.svc.cluster.local
Address 2: 172.20.248.143 mysql-r-1.mysql-r.default.svc.cluster.local
Address 3: 172.20.120.143 mysql-r-0.mysql-r.default.svc.cluster.local

#如果service 没有指定 clusterIP: None，也就是会分配一个clusterIP给集群
/ # nslookup mysql-r
Server:    10.68.0.2
Address 1: 10.68.0.2 kube-dns.kube-system.svc.cluster.local

Name:      mysql-r
Address 1: 10.68.90.172 mysql-r.default.svc.cluster.local

不是每个pod都会向DNS注册，只有：

  • StatefulSet中的POD会向dns注册，因为他们要保证顺序行
  • POD显式指定了hostname和subdomain，说明要靠hostname/subdomain来解析
  • Headless Service代理的POD也会注册

Ingress

kube-proxy 只能路由 Kubernetes 集群内部的流量，而我们知道 Kubernetes 集群的 Pod 位于 CNI 创建的外网络中，集群外部是无法直接与其通信的，因此 Kubernetes 中创建了 ingress 这个资源对象，它由位于 Kubernetes 边缘节点（这样的节点可以是很多个也可以是一组）的 Ingress controller 驱动，负责管理南北向流量，Ingress 必须对接各种 Ingress Controller 才能使用，比如 nginx ingress controller、traefik。Ingress 只适用于 HTTP 流量，使用方式也很简单，只能对 service、port、HTTP 路径等有限字段匹配来路由流量，这导致它无法路由如 MySQL、Redis 和各种私有 RPC 等 TCP 流量。要想直接路由南北向的流量，只能使用 Service 的 LoadBalancer 或 NodePort，前者需要云厂商支持，后者需要进行额外的端口管理。有些 Ingress controller 支持暴露 TCP 和 UDP 服务，但是只能使用 Service 来暴露，Ingress 本身是不支持的，例如 nginx ingress controller，服务暴露的端口是通过创建 ConfigMap 的方式来配置的。

Ingress是授权入站连接到达集群服务的规则集合。 你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。 用户通过POST Ingress资源到API server的方式来请求ingress。

1
2
3
4
5
 internet
     |
[ Ingress ]
--|-----|--
[ Services ]

可以将 Ingress 配置为服务提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及提供基于名称的虚拟主机等能力。 Ingress 控制器 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。

Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 类型的服务。

Ingress 其实不是Service的一个类型，但是它可以作用于多个Service，作为集群内部服务的入口。Ingress 能做许多不同的事，比如根据不同的路由，将请求转发到不同的Service上等等。

image.png

Ingress 对象，其实就是 Kubernetes 项目对“反向代理”的一种抽象。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  tls:
  - hosts:
    - cafe.example.com
    secretName: cafe-secret
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea              --入口url路径
        backend:
          serviceName: tea-svc  --对应的service
          servicePort: 80
      - path: /coffee
        backend:
          serviceName: coffee-svc
          servicePort: 80

在实际的使用中，你只需要从社区里选择一个具体的 Ingress Controller，把它部署在 Kubernetes 集群里即可。然后，这个 Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。

目前，业界常用的各种反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为 Kubernetes 专门维护了对应的 Ingress Controller。

一个 Ingress Controller 可以根据 Ingress 对象和被代理后端 Service 的变化，来自动进行更新的 Nginx 负载均衡器。

对service未来的一些探索

eBPF（extended Berkeley Packet Filter）和网络

eBPF 最早出现在 3.18 内核中，此后原来的 BPF 就被称为 “经典” BPF（classic BPF, cBPF），cBPF 现在基本已经废弃了。很多人知道 cBPF 是因为它是 tcpdump 的包过滤语言。现在，Linux 内核只运行 eBPF，内核会将加载的 cBPF 字节码 透明地转换成 eBPF 再执行。如无特殊说明，本文中所说的 BPF 都是泛指 BPF 技术。

2015年eBPF 添加了一个新 fast path：XDP，XDP 是 eXpress DataPath 的缩写，支持在网卡驱动中运行 eBPF 代码，而无需将包送 到复杂的协议栈进行处理，因此处理代价很小，速度极快。

BPF 当时用于 tcpdump，在内核中尽量前面的位置抓包，它不会 crash 内核；

bcc 是 tracing frontend for eBPF。

内核添加了一个新 socket 类型 AF_XDP。它提供的能力是：在零拷贝（ zero-copy）的前提下将包从网卡驱动送到用户空间。

AF_XDP 提供的能力与 DPDK 有点类似，不过：

  • DPDK 需要重写网卡驱动，需要额外维护用户空间的驱动代码。
  • AF_XDP 在复用内核网卡驱动的情况下，能达到与 DPDK 一样的性能。

而且由于复用了内核基础设施，所有的网络管理工具还都是可以用的，因此非常方便， 而 DPDK 这种 bypass 内核的方案导致绝大大部分现有工具都用不了了。

由于所有这些操作都是发生在 XDP 层的，因此它称为 AF_XDP。插入到这里的 BPF 代码 能直接将包送到 socket。

Facebook 公布了生产环境 XDP+eBPF 使用案例（DDoS & LB）

  • 用 XDP/eBPF 重写了原来基于 IPVS 的 L4LB，性能 10x。
  • eBPF 经受住了严苛的考验：从 2017 开始，每个进入 facebook.com 的包，都是经过了 XDP & eBPF 处理的。

Cilium 1.6 发布 第一次支持完全干掉基于 iptables 的 kube-proxy，全部功能基于 eBPF。Cilium 1.8 支持基于 XDP 的 Service 负载均衡和 host network policies。

传统的 kube-proxy 处理 Kubernetes Service 时，包在内核中的 转发路径是怎样的？如下图所示：

image.png

步骤：

  1. 网卡收到一个包（通过 DMA 放到 ring-buffer）。
  2. 包经过 XDP hook 点。
  3. 内核给包分配内存，此时才有了大家熟悉的 skb（包的内核结构体表示），然后 送到内核协议栈。
  4. 包经过 GRO 处理，对分片包进行重组。
  5. 包进入 tc（traffic control）的 ingress hook。接下来，所有橙色的框都是 Netfilter 处理点。
  6. Netfilter：在 PREROUTING hook 点处理 raw table 里的 iptables 规则。
  7. 包经过内核的连接跟踪（conntrack）模块。
  8. Netfilter：在 PREROUTING hook 点处理 mangle table 的 iptables 规则。
  9. Netfilter：在 PREROUTING hook 点处理 nat table 的 iptables 规则。
  10. 进行路由判断（FIB：Forwarding Information Base，路由条目的内核表示，译者注） 。接下来又是四个 Netfilter 处理点。
  11. Netfilter：在 FORWARD hook 点处理 mangle table 里的iptables 规则。
  12. Netfilter：在 FORWARD hook 点处理 filter table 里的iptables 规则。
  13. Netfilter：在 POSTROUTING hook 点处理 mangle table 里的iptables 规则。
  14. Netfilter：在 POSTROUTING hook 点处理 nat table 里的iptables 规则。
  15. 包到达 TC egress hook 点，会进行出方向（egress）的判断，例如判断这个包是到本 地设备，还是到主机外。
  16. 对大包进行分片。根据 step 15 判断的结果，这个包接下来可能会：发送到一个本机 veth 设备，或者一个本机 service endpoint， 或者，如果目的 IP 是主机外，就通过网卡发出去。

Cilium 如何处理POD之间的流量（东西向流量）

image.png

如上图所示，Socket 层的 BPF 程序主要处理 Cilium 节点的东西向流量（E-W）。

  • 将 Service 的 IP:Port 映射到具体的 backend pods，并做负载均衡。
  • 当应用发起 connect、sendmsg、recvmsg 等请求（系统调用）时，拦截这些请求， 并根据请求的IP:Port 映射到后端 pod，直接发送过去。反向进行相反的变换。

这里实现的好处：性能更高。

  • 不需要包级别（packet leve）的地址转换（NAT）。在系统调用时，还没有创建包，因此性能更高。
  • 省去了 kube-proxy 路径中的很多中间节点（intermediate node hops） 可以看出，应用对这种拦截和重定向是无感知的（符合 Kubernetes Service 的设计）。

Cilium处理外部流量（南北向流量）

image.png

集群外来的流量到达 node 时，由 XDP 和 tc 层的 BPF 程序进行处理， 它们做的事情与 socket 层的差不多，将 Service 的 IP:Port 映射到后端的 PodIP:Port，如果 backend pod 不在本 node，就通过网络再发出去。发出去的流程我们 在前面 Cilium eBPF 包转发路径 讲过了。

这里 BPF 做的事情：执行 DNAT。这个功能可以在 XDP 层做，也可以在 TC 层做，但 在XDP 层代价更小，性能也更高。

总结起来，Cilium的核心理念就是：

  • 将东西向流量放在离 socket 层尽量近的地方做。
  • 将南北向流量放在离驱动（XDP 和 tc）层尽量近的地方做。

性能比较

测试环境：两台物理节点，一个发包，一个收包，收到的包做 Service loadbalancing 转发给后端 Pods。

image.png

可以看出：

  • Cilium XDP eBPF 模式能处理接收到的全部 10Mpps（packets per second）。
  • Cilium tc eBPF 模式能处理 3.5Mpps。
  • kube-proxy iptables 只能处理 2.3Mpps，因为它的 hook 点在收发包路径上更后面的位置。
  • kube-proxy ipvs 模式这里表现更差，它相比 iptables 的优势要在 backend 数量很多的时候才能体现出来。

cpu：

  • XDP 性能最好，是因为 XDP BPF 在驱动层执行，不需要将包 push 到内核协议栈。
  • kube-proxy 不管是 iptables 还是 ipvs 模式，都在处理软中断（softirq）上消耗了大量 CPU。

标签和选择算符

标签（Labels） 是附加到 Kubernetes 对象（比如 Pods）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。

标签选择符

selector要和template中的labels一致

1
2
3
4
5
6
7
8
9
10
11
spec:
  serviceName: "nginx-test"
  replicas: 2
  selector:
    matchLabels:
      app: ren
  template:
    metadata:
      labels:
        app: web

selector就是要找别人的label和自己匹配的，label是给别人来寻找的。如下case，svc中的 Selector: app=ren 是表示这个svc要绑定到app=ren的deployment/statefulset上.

被 selector 选中的 Pod，就称为 Service 的 Endpoints

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@poc117 mysql-cluster]# kubectl describe svc nginx-ren 
Name:                     nginx-ren
Namespace:                default
Labels:                   app=web
Annotations:              <none>
Selector:                 app=ren
Type:                     NodePort
IP:                       10.68.34.173
Port:                     <unset>  8080/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  30080/TCP
Endpoints:                172.20.22.226:80,172.20.56.169:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>
[root@poc117 mysql-cluster]# kubectl get svc -l app=web
NAME        TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
nginx-ren   NodePort   10.68.34.173   <none>        8080:30080/TCP   13m
[root@poc117 mysql-cluster]# kubectl get svc -l app=ren
No resources found in default namespace.
[root@poc117 mysql-cluster]# kubectl get svc -l app=web
NAME        TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
nginx-ren   NodePort   10.68.34.173   <none>        8080:30080/TCP   14m

service mesh

  • Kubernetes 的本质是应用的生命周期管理，具体来说就是部署和管理（扩缩容、自动恢复、发布）。
  • Kubernetes 为微服务提供了可扩展、高弹性的部署和管理平台。
  • Service Mesh 的基础是透明代理，通过 sidecar proxy 拦截到微服务间流量后再通过控制平面配置管理微服务的行为。
  • Service Mesh 将流量管理从 Kubernetes 中解耦，Service Mesh 内部的流量无需 kube-proxy 组件的支持，通过为更接近微服务应用层的抽象，管理服务间的流量、安全性和可观察性。
  • xDS 定义了 Service Mesh 配置的协议标准。
  • Service Mesh 是对 Kubernetes 中的 service 更上层的抽象，它的下一步是 serverless。

Sidecar 注入及流量劫持步骤概述

下面是从 Sidecar 注入、Pod 启动到 Sidecar proxy 拦截流量及 Envoy 处理路由的步骤概览。

1. Kubernetes 通过 Admission Controller 自动注入，或者用户使用 istioctl 命令手动注入 sidecar 容器。

2. 应用 YAML 配置部署应用，此时 Kubernetes API server 接收到的服务创建配置文件中已经包含了 Init 容器及 sidecar proxy。

3. 在 sidecar proxy 容器和应用容器启动之前，首先运行 Init 容器，Init 容器用于设置 iptables（Istio 中默认的流量拦截方式，还可以使用 BPF、IPVS 等方式） 将进入 pod 的流量劫持到 Envoy sidecar proxy。所有 TCP 流量（Envoy 目前只支持 TCP 流量）将被 sidecar 劫持，其他协议的流量将按原来的目的地请求。

4. 启动 Pod 中的 Envoy sidecar proxy 和应用程序容器。这一步的过程请参考通过管理接口获取完整配置。

5. 不论是进入还是从 Pod 发出的 TCP 请求都会被 iptables 劫持，inbound 流量被劫持后经 Inbound Handler 处理后转交给应用程序容器处理，outbound 流量被 iptables 劫持后转交给 Outbound Handler 处理，并确定转发的 upstream 和 Endpoint。

6. Sidecar proxy 请求 Pilot 使用 xDS 协议同步 Envoy 配置，其中包括 LDS、EDS、CDS 等，不过为了保证更新的顺序，Envoy 会直接使用 ADS 向 Pilot 请求配置更新

参考资料

https://imroc.io/posts/kubernetes/troubleshooting-with-kubernetes-network/ Kubernetes 网络疑难杂症排查方法

https://blog.csdn.net/qq_36183935/article/details/90734936 kube-proxy ipvs模式详解

http://arthurchiao.art/blog/ebpf-and-k8s-zh/ 大规模微服务利器：eBPF 与 Kubernetes

http://arthurchiao.art/blog/cilium-life-of-a-packet-pod-to-service-zh/ Life of a Packet in Cilium：实地探索 Pod-to-Service 转发路径及 BPF 处理逻辑

http://arthurchiao.art/blog/understanding-ebpf-datapath-in-cilium-zh/ 深入理解 Cilium 的 eBPF 收发包路径（datapath）（KubeCon, 2019）

https://jiayu0x.com/2014/12/02/iptables-essential-summary/

docker

kubernetes 多集群管理

kubernetes 多集群管理

kubectl 管理多集群

指定config配置文件的方式访问不同的集群

1
kubectl --kubeconfig=/etc/kubernetes/admin.conf get nodes

一个kubectl可以管理多个集群，主要是 ~/.kube/config 里面的配置，比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
clusters:
- cluster:
    certificate-authority: /root/k8s-cluster.ca
    server: https://192.168.0.80:6443
  name: context-az1
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCQl0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
    server: https://192.168.0.97:6443
  name: context-az3

- context:
    cluster: context-az1
    namespace: default
    user: az1-admin
  name: az1
- context:
    cluster: context-az3
    namespace: default
    user: az3-read
  name: az3
current-context: az3  //当前使用的集群

kind: Config
preferences: {}
users:
- name: az1-admin
  user:
    client-certificate: /root/k8s.crt  //key放在配置文件中
    client-key: /root/k8s.key
- name: az3-read
  user:
    client-certificate-data: LS0tLS1CRUQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJThuL2VPM0YxSWpEcXBQdmRNbUdiU2c9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=

多个集群中切换的话 ： kubectl config use-context az3

快速合并两个cluster

简单来讲就是把两个集群的 .kube/config 文件合并，注意context、cluster name别重复了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 必须提前保证两个config文件中的cluster、context名字不能重复
export KUBECONFIG=~/.kube/config:~/someotherconfig 
kubectl config view --flatten

#激活这个上下文
kubectl config use-context az1 

#查看所有context
kubectl config get-contexts 
CURRENT   NAME   CLUSTER       AUTHINFO           NAMESPACE
          az1    context-az1   az1-admin          default
*         az2    kubernetes    kubernetes-admin   
          az3    context-az3   az3-read           default

背后的原理类似于这个流程：

1
2
3
4
5
6
7
8
9
# 添加集群 集群地址上一步有获取 ，需要指定ca文件，上一步有获取 
kubectl config set-cluster cluster-az1 --server https://192.168.146.150:6444  --certificate-authority=/usr/program/k8s-certs/k8s-cluster.ca

# 添加用户 需要指定crt，key文件，上一步有获取
kubectl config set-credentials az1-admin --client-certificate=/usr/program/k8s-certs/k8s.crt --client-key=/usr/program/k8s-certs/k8s.key

# 指定一个上下文的名字，我这里叫做 az1，随便你叫啥 关联刚才的用户
kubectl config set-context az1 --cluster=context-az1  --namespace=default --user=az1-admin

参考资料

http://coreos.com/blog/kubectl-tips-and-tricks

https://stackoverflow.com/questions/46184125/how-to-merge-kubectl-config-file-with-kube-config