erlang node_name phash 冲突坑

Posted 2021-09-03 enjolras1205

概述

在线上遇到了因节点名哈希值冲突导致的部分机器无负载问题。10台机器中，冲突的机器达到了4台之多。假设哈希的概率是平均的。10台机器中，不存在冲突的概率接近

>>> 1 - (1.0 / (2 ** 32)) * 10
0.9999999976716936

实际上，10台中哈希值冲突了6台。于是看源码找答案。

过程

先从phash2 api入手

erlang 的 api调用方式和 linux有相似之处。通过函数指针数组。
erl_bif_list.h 中看到，我们调用的phash2对应phash2_2。

BIF_LIST(am_erlang,am_phash,2,phash_2,phash_2,37)
BIF_LIST(am_erlang,am_phash2,1,phash2_1,phash2_1,38)
BIF_LIST(am_erlang,am_phash2,2,phash2_2,phash2_2,39)

bif.c:4905

BIF_RETTYPE phash2_2(BIF_ALIST_2)
{
    Uint32 hash;
    Uint32 final_hash;
    Uint32 range;
    Eterm trap_state = THE_NON_VALUE;

    /* Check for special case 2^32 */
    if (term_equals_2pow32(BIF_ARG_2)) {
    range = 0;
    } else {
    Uint u;
    if (!term_to_Uint(BIF_ARG_2, &u) || ((u >> 16) >> 16) != 0 || !u) {
        BIF_ERROR(BIF_P, BADARG);
    }
    range = (Uint32) u;
    }
    hash = trapping_make_hash2(BIF_ARG_1, &trap_state, BIF_P);
    if (trap_state != THE_NON_VALUE) {
        BIF_TRAP2(&bif_trap_export[BIF_phash2_2], BIF_P, trap_state, BIF_ARG_2);
    }
    if (range) {
    final_hash = hash % range; /* [0..range-1] */
    } else {
    final_hash = hash;
    }
    /*
     * Return either a small or a big. Use the heap for bigs if there is room.
     */
#if defined(ARCH_64)
    BIF_RET(make_small(final_hash));
#else
    if (IS_USMALL(0, final_hash)) {
    BIF_RET(make_small(final_hash));
    } else {
    Eterm* hp = HAlloc(BIF_P, BIG_UINT_HEAP_SIZE);
    BIF_RET(uint_to_big(final_hash, hp));
    }
#endif
}

通过调试可以确认

1298    {
(gdb) bt
#0  make_hash2_helper (term_param=203, can_trap=1, state_mref_write_back=0x7fd2b7bfc598, p=0x7fd2b9900b88) at beam/utils.c:1298
#1  0x0000558545a0a5eb in trapping_make_hash2 (term=203, state_mref_write_back=0x7fd2b7bfc598, p=0x7fd2b9900b88) at beam/utils.c:1983
#2  0x0000558545a284ad in phash2_1 (A__p=0x7fd2b9900b88, BIF__ARGS=0x7fd2ba200200, A__I=0x7fd2b7d5ef60) at beam/bif.c:4897
#3  0x00005585459455b2 in process_main (x_reg_array=0x7fd2ba200200, f_reg_array=0x7fd2ba202240) at x86_64-unknown-linux-gnu/opt/smp/beam_cold.h:121
#4  0x00005585459613ac in sched_thread_func (vesdp=0x7fd2b89440c0) at beam/erl_process.c:8498
#5  0x0000558545c47a63 in thr_wrapper (vtwd=0x7ffcd94d55a0) at pthread/ethread.c:122
#6  0x00007fd2fb2896db in start_thread (arg=0x7fd2b7bff700) at pthread_create.c:463
#7  0x00007fd2fadaa71f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

phash2 对atom的处理

erts/emulator/beam/utils.c:1418
直接用atom的值找到erts_atom_table对应的哈希值。

    if (primary_tag(term) == TAG_PRIMARY_IMMED1) {
    switch (term & _TAG_IMMED1_MASK) {
    case _TAG_IMMED1_IMMED2:
        switch (term & _TAG_IMMED2_MASK) {
        case _TAG_IMMED2_ATOM:
            /* Fast, but the poor hash value should be mixed. */
            return atom_tab(atom_val(term))->slot.bucket.hvalue;
        }

可以看到，erts_atom_table是全局的，上限为1024*1024哈希表。这也是为什么原子最大只能存储1048576。
erts/emulator/beam/atom.h:atom_tab

atom_tab(Uint i)
{
    return (Atom *) erts_index_lookup(&erts_atom_table, i);
}

erts/emulator/beam/index.h:erts_index_lookup
seg_table是一个 1024*1024 的二维数组

ERTS_GLB_INLINE IndexSlot*
erts_index_lookup(IndexTable* t, Uint ix)
{
    return t->seg_table[ix>>INDEX_PAGE_SHIFT][ix&INDEX_PAGE_MASK];
}

搜索erts_atom_table从代码可以看到，是生成原子时，在修改erts_atom_table时，计算的哈希值。问题的关键在于原子的哈希值是如何计算的。

atom hash

从atom.c:init_atom_table中可以看到。原子的哈希值是通过init时赋值的函数指针计算的，具体逻辑如下：
atom.c:atom_hash

static HashValue
atom_hash(Atom *obj)
{
    byte *p = obj->name;
    int len = obj->len;
    HashValue h = 0, g;
    byte v;

    while (len--)
    {
        v = *p++;
        /* latin1 clutch for r16 */
        if (len && (v & 0xFE) == 0xC2 && (*p & 0xC0) == 0x80)
        {
            v = (v << 6) | (*p & 0x3F);
            p++;
            len--;
        }
        /* normal hashpjw follows for v */
        h = (h << 4) + v;
        if ((g = h & 0xf0000000))
        {
            h ^= (g >> 24);
            h ^= g;
        }
    }
    return h;
}

调试确认，节点名atom的计算，也是走这里，那么为什么会冲突呢？

Thread 6 "2_scheduler" hit Breakpoint 1, atom_hash (obj=0x7f39bfef92d0) at beam/atom.c:131
131         byte* p = obj->name;
(gdb) p obj->name
$19 = (byte *) 0x7f3a08580180 "test1@ubuntu"
(gdb) p obj->len
$20 = 12
(gdb) bt
#0  atom_hash (obj=0x7f39bfef92d0) at beam/atom.c:131
#1  0x000055c20bd115ab in hash_fetch (h=0x55c20c1d8040 <erts_atom_table>, tmpl=0x7f39bfef92d0, hash=0x55c20bd12a67 <atom_hash>, 
    cmp=0x55c20bd12b48 <atom_cmp>) at beam/hash.h:133
#2  0x000055c20bd11d27 in hash_get (h=0x55c20c1d8040 <erts_atom_table>, tmpl=0x7f39bfef92d0) at beam/hash.c:228
#3  0x000055c20bd124bc in index_get (t=0x55c20c1d8040 <erts_atom_table>, tmpl=0x7f39bfef92d0) at beam/index.c:109
#4  0x000055c20bd12fb7 in erts_atom_put_index (name=0x7f3a08580180 "test1@ubuntu", len=12, enc=ERTS_ATOM_ENC_UTF8, trunc=1) at beam/atom.c:299
#5  0x000055c20bd13115 in erts_atom_put (name=0x7f3a08580180 "test1@ubuntu", len=12, enc=ERTS_ATOM_ENC_UTF8, trunc=1) at beam/atom.c:350
#6  0x000055c20bc57596 in list_to_atom_1 (A__p=0x7f39bf203588, BIF__ARGS=0x7f39c67c4280, A__I=0x7f39be3d9590) at beam/bif.c:2913
#7  0x000055c20bb65087 in process_main (x_reg_array=0x7f39c67c4280, f_reg_array=0x7f39c67c6300) at x86_64-unknown-linux-gnu/opt/smp/beam_hot.h:331
#8  0x000055c20bb973ac in sched_thread_func (vesdp=0x7f39c4f4e480) at beam/erl_process.c:8498
#9  0x000055c20be7da63 in thr_wrapper (vtwd=0x7ffc7f688b60) at pthread/ethread.c:122
#10 0x00007f3a078816db in start_thread (arg=0x7f39bfefc700) at pthread_create.c:463
#11 0x00007f3a073a271f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
        
(gdb) printf "%d,%s\\n", h, obj->name
1385189,test1@ubuntu
(gdb) printf "%d,%s\\n", h, obj->name
1385013,test4@ubuntu
(gdb) printf "%d,%s\\n", h, obj->name
1384965,test7@ubuntu

用python写了同样的算法，发现冲突概率真的很高，参考结论里的链接。

def atom_hash(s):
    h = 0
    g = 0
    for v in s:
        h = (h << 4) + ord(v)
        g = h & 0xf0000000
        if g:
            h ^= (g >> 24)
            h ^= g
    return h


for num in range(10):
    value = "test{0}@ubuntu".format(num)
    hash_val = atom_hash(value)
    print(value, hash_val)

test0@ubuntu 1385205
test1@ubuntu 1385189
test2@ubuntu 1385173
test3@ubuntu 1385157
test4@ubuntu 1385013
test5@ubuntu 1384997
test6@ubuntu 1384981
test7@ubuntu 1384965
test8@ubuntu 1385077
test9@ubuntu 1385061

结论

• 原子的哈希值和原子的字符串展示相关，即同样的原子，在不同的节点上（同样的erlang vm版本，同样的哈希算法），那么该原子的哈希值是一样的。
• atom_hash使用了hashpjw算法，该算法，即erlang原子哈希值的生成算法很容易冲突。没找到更权威的资料了：https://blog.csdn.net/iteye_1...