Weakyon Blog
0%

发表于 分类于 本文字数： 27k 阅读时长 ≈ 24 分钟

当前的一致性哈希存在四个bug，分别进行分析

以这个版本https://git.huya.com/server_arch/taf/-/blob/924950284557f183bd025ed758dc2e878ae36938/src/libservant/EndpointManager.cpp#L2448为例

我新增了部分日志，总体流程的关键代码在getConHashProxyForNormal

他的输入是hashCode（也就是prx->taf_consistent_hash(hashCode)传入的），输出是本次负载均衡选出的节点指针

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
AdapterProxyPtr EndpointManager::getConHashProxyForNormal(int64_t hashCode)
{
    //_vLastConHashProxys是上一次更新一致性哈希时记下的节点
    //checkConHashChange中如果当前节点和上一次的有变化，那么返回true
    if(checkConHashChange(false, _vLastConHashProxys)) {

        //根据当前节点，把数据写入到_consistentHash
        updateConHashProxyWeighted(true, _vLastConHashProxys, _consistentHash);
    }
    LOG_INFO << "[TAF][EndpointManager::getConHashProxyForNormal _sObjName:"
             << _sObjName
             << "|_consistentHash.size():" << _consistentHash.size() << endl;

    if(_consistentHash.size() > 0) {
        //根据_consistentHash数据一致性哈希选节点
        ...

        //没选出来，返回空
        return nullptr;
    }
    //_consistentHash是空的，降级到普通hash

    return getHashProxyForNormal(hashCode);
}
阅读全文 »

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

在Serverless平台的研发过程中，意外在python的import问题上踩坑了

大概还是对python的包管理基本原理不够了解，首先对python的包管理机制做一个总结，然后分析这一次踩坑的问题

python的包管理

Import基本语法

Python 中 import 有四种常见语法形式：

阅读全文 »

发表于 更新于 分类于 ， 本文字数： 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

阅读全文 »