前文分析了一波锁的原理：

并实现了协程下的锁：

距离上一篇记录过载保护的文章再看过载保护，已经过去有6年多了，回看那一篇文章，未免显得青涩，大部分都是错误的

文章核心理论集中在“控制任务队列长度”来规避过载，根据压测得出过载根因：并发上升 → 任务队列长度剧增 → 资源占用加剧 → 响应时间线性增加

看似没啥问题，但是压测是基于grpc服务和net/http服务的

net/http服务显然没有队列概念。grpc也没有内置队列，它主要依赖 HTTP/2 多路复用，在收到请求后就会启动相应的 Goroutine 进行处理

继上一篇实现HTTP长连接的HTTP/1.1连接池实现已经过去半年

这一段时间发现了HTTP/1.1连接池无法解决的致命缺点：

在突发高并发场景下，客户端由于需要额外建连很容易退化成短连接

• 在超高突增并发下和短链接几乎无异，我司由于业务特性就是这种情况

• 即使突增并发不高，只要并发持续增长超过一定比例后，由于新建连接的tcp握手+ssl握手需要耗费大量的cpu，造成客户端和服务端的cpu不稳定，叠加新建连接的tcp慢启动因素带来了更多的超时。

  而HTTP/1.1一旦超时就需要断开连接重新建连，更多的建连带来了更多的超时，又带来了更多的建连，就造成了雪崩效应

HTTP/1.1压测

本文整理一下遇到的编译问题，最常见的就是编译时缺符号，重定义

但是一般来说cmake生成的make语句会隐藏实际的gcc语句，如果手写的makefile，也有可能是目标规则没配置正确

make的debug

• 查看实际的gcc语句

  • 特殊命令

    VERBOSE = 1或者V=1，主要看makefile怎么写的，一般都能用

  • 通用的

    make -n

    实际上是只输出make试图运行的指令

• 查看目标规则情况

  make -d

  将打印 Make 为每个目标尝试的所有规则（包括内置规则）

单步编译链接语句debug

最近业务报障，使用taf框架编译成动态库，从3.4.5.8-notrace版本换成3.4.6.0-notcmalloc版本后

dlopen打开动态库报错cannot allocate memory in static TLS block，业务认为是不带tcmalloc导致的

我的最终结论是taf框架的动态库编译强制开启了静态TLS，这个线程私有变量区是存在上限的，trace代码有超大的线程私有变量，导致dlopen失败

总结了一下何时会开启静态TLS，并且如何解决

初步定位并解决问题

截止25年1月12日，打算使用dlmopen来装载serverless平台第三方动态库的计划，在挣扎了2周后正式宣布破产

总的来说dlmopen虽然已经有几十年历史了，但是在当前还是非常不成熟的，有很多细节问题没有解决

想用上dlmopen，需要深入理解glibc的实现原理，和patches的可能bug斗智斗勇，这个投入产出比很低

背景

serverless平台的设计原理属于机密，略过不提

首先分析一下我所见过的权重负载均衡算法的平滑性缺点，最后着重分析来自Nginx的默认算法：平滑加权轮询算法（Smooth Weighted Round-Robin ）

平滑性

首先负载均衡算法的平滑性，我认为包含两个重要特征：

• 在较大的某个时间窗口内一定会访问某些节点：

  违反这个特征，会导致部分节点的使用率过低

  这可以认为是一种稳定性，稳定的访问有权重的节点

• 不能太过连续访问某些节点

  违反这个特征，会导致部分节点使用率过高，导致过载

随机负载均衡

续接十年前总结的前文linux的内存管理介绍

最近遇到了Serverless平台的管理节点上报内存不准确的问题，导致调度误判从而大量oom，所以不同于前文对meminfo一笔带过，需要对meminfo做一个系统的深入了解，并对其内容做一个分类，搞清楚存在的相互联系

首先贴一个/proc/meminfo的数据，可以看到，有49项，非常复杂

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

MemTotal:        1950928 kB
MemFree:          110512 kB
MemAvailable:     300776 kB
Buffers:               0 kB
Cached:           295128 kB
SwapCached:            0 kB
Active:          1431548 kB
Inactive:         159160 kB
Active(anon):    1293796 kB
Inactive(anon):     1916 kB
Active(file):     137752 kB
Inactive(file):   157244 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              2108 kB
Writeback:             0 kB
AnonPages:       1295424 kB
Mapped:            85936 kB
Shmem:              2188 kB
KReclaimable:      53172 kB
Slab:             132728 kB
SReclaimable:      53172 kB
SUnreclaim:        79556 kB
KernelStack:        9360 kB
PageTables:        14280 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:      975464 kB
Committed_AS:    3710176 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
Percpu:             1136 kB
HardwareCorrupted:     0 kB
AnonHugePages:    397312 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      430776 kB
DirectMap2M:     1583104 kB
DirectMap1G:           0 kB

MemTotal，MemFree，MemAvailable

本篇总结一下信号的必要知识，以及实际场景下的处理，主要参考UNIX环境高级编程（第三版）

要先从子进程fork开始总结，因为信号和子进程息息相关

wait系统调用

根据书中8.3节 fork以及8.6节 wait

• fork出子进程以后，假如子进程退出，需要用wait或者waitpid检查子进程的退出状态，否则子进程会进入僵死状态，直到父进程退出，被系统的1号进程接管进行wait才会释放。
• 父进程可以直接wait等待，也可以啥也不做，在SIGCHLD信号处理函数中，再进行wait调用
• waitpid比wait多一些功能，最主要的就是可以在第二个参数传入WNOHANG进行非阻塞调用

docker相对于虚拟机

• 优点是通过镜像备份和恢复（类似于盗版windows的ghost系统），并且镜像的DockerFile以及镜像本身都是可描述的
• 缺点是隔离不彻底：内核和部分资源（例如时间）是共享的宿主系统的

docker的缺点是因为他的本质是限制和隔离，他并不是一个独立的操作系统，只是在”宿主系统“上限制了资源使用和隔离开了各种资源的视角

限制：Cgroup

cgroup在/sys/fs/cgroup 路径下，有很多诸如 cpuset、cpu、 memory 这样的子目录，也叫子系统