Weakyon Blog
0%

发表于 更新于 分类于 ， 本文字数： 8k 阅读时长 ≈ 7 分钟

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

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

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

img

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

阅读全文 »

发表于 更新于 本文字数： 29k 阅读时长 ≈ 26 分钟

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

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

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

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

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

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

HTTP/1.1压测

阅读全文 »

发表于 更新于 分类于 本文字数： 4.5k 阅读时长 ≈ 4 分钟

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

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

make的debug

  • 查看实际的gcc语句

    • 特殊命令

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

    • 通用的

      make -n

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

  • 查看目标规则情况

    make -d

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

单步编译链接语句debug

阅读全文 »

发表于 更新于 分类于 本文字数： 6.4k 阅读时长 ≈ 6 分钟

最近业务报障，使用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，并且如何解决

初步定位并解决问题

阅读全文 »

发表于 更新于 分类于 本文字数： 12k 阅读时长 ≈ 11 分钟

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

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

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

背景

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

阅读全文 »

发表于 更新于 分类于 ， ， 本文字数： 11k 阅读时长 ≈ 10 分钟

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

平滑性

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

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

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

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

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

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

随机负载均衡

阅读全文 »

发表于 更新于 分类于 本文字数： 46k 阅读时长 ≈ 42 分钟

续接十年前总结的前文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

阅读全文 »

发表于 更新于 分类于 本文字数： 21k 阅读时长 ≈ 19 分钟

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

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

wait系统调用

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

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

发表于 更新于 本文字数： 24k 阅读时长 ≈ 22 分钟

docker相对于虚拟机

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

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

限制：Cgroup

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

阅读全文 »

发表于 更新于 本文字数： 21k 阅读时长 ≈ 19 分钟

对于编译器而言，符号的全部相关数据都在Elf32_Sym或Elf64_Sym，以Elf32_Sym为例了解一些编译器的知识，然后再分析C++的语法

1
2
3
4
5
6
7
8
9
typedef struct
{
  Elf32_Word    st_name;   /* Symbol name (string tbl index) */
  Elf32_Addr    st_value;  /* Symbol value */
  Elf32_Word    st_size;   /* Symbol size */
  unsigned char st_info;   /* Symbol type and binding */
  unsigned char st_other;  /* Symbol visibility under glibc>=2.2 */
  Elf32_Section st_shndx;  /* Section index */
} Elf32_Sym;

st_info这个结构是用于区分各种类型的，也是这一篇博文的重点，这个char结构8位

  • 高 4 位用于表示 st_bind：

    值 静态链接行为
    STB_LOCAL 允许在不同的目标文件中，存在多个相同名字的符号，符号之间相互隔离（无关联）。
    STB_GLOBAL 只允许一个目标文件存在 GLOBAL 符号定义，其它目标文件允许相同名字的未定义的符号引用，即不允许多个定义。
    STB_WEAK 允许在不同的目标文件中存在多个相同名字的符号。具体来说，如果同时存在一个 GLOBAL 符号和其它同名 WEAK 符号的定义，那就挑选 GLOBAL 符号（ignores the weak ones）；如果存在多个同名 WEAK 符号的定义，事实标准是挑选 linker 解析过程中接触到的第一个符号。

​ 我这里特意强调了静态链接行为，因为静态链接和动态链接虽然对LOCAL的逻辑是一致的，但是动态链接器在符号重定位的时候，对GLOBAL和WEAK是一视同仁的

阅读全文 »