探索惊群 ④ - nginx - accept_mutex

2021-10-10

由主进程创建的 listen socket,要被 fork 出来的子进程共享,但是为了避免多个子进程同时争抢共享资源,nginx 采用一种策略:使得多个子进程,同一时段,只有一个子进程能获取资源,就不存在共享资源的争抢问题。

成功获取锁的,能获取一定数量的资源,而其它没有成功获取锁的子进程,不能获取资源,只能等待成功获取锁的进程释放锁后,nginx 多进程再重新进入锁竞争环节。


1. 配置

nginx 通过修改配置开启 accept_mutex 功能特性。

1
2
3
4
5
6
# vim /usr/local/nginx/conf/nginx.conf
events {
    ...
    accept_mutex on;
    ...
}

2. 解决方案

2.1. 负载均衡

nginx 子进程通过抢共享锁 🔐 实现负载均衡,现在用下面的伪代码去理解它的实现原理。

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
int main() {
    efd = epoll_create();

    while (1) {
        if (is_disabled) {
            ...
            /* 不抢,但是为了避免一直不抢,也要递减它的 disable 程度。*/
            is_disabled = reduce_disabled();
        } else {
            /* 抢。*/
            if (try_lock()) {
                /* 抢锁成功,epoll 关注 listen_fd 的 POLLIN 事件。 */
                if (!is_locked) {
                    epoll_ctl(efd, EPOLL_CTL_ADD, listen_fd, ...);
                    is_locked = true;
                }
            } else {
                if (is_locked) {
                    /* 抢锁失败,epoll 不再关注 listen_fd 事件。 */
                    epoll_ctl(efd, EPOLL_CTL_DEL, listen_fd, ...);
                    is_locked = false;
                }
            }
        }

        /* 超时等待链接资源到来。 */
        n = epoll_wait(...)
        if (n > 0) {
            if (is_able_to_accept) {
                /* 链接资源到来,取出链接。*/
                client_fd = accept();
                /* 每次取出链接后,重新检查 disabled 值。*/
                is_disabled = check_disabled();
            }
        }

        if (is_locked) {
            unlock();
        }
    }

    return 0;
}

nginx 通过 ngx_accept_disabled 负载均衡数值控制抢锁的时机,每次 accept 完链接资源后,都检查一下它。

1
ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n;

connection_n 最大连接数是固定的;free_connection_n 空闲连接数是变化的。只有在 ngx_accept_disabled > 0 的情况下,进程才不愿意抢锁,换句话说,就是已使用链接大于总链接的 7/8 了,空闲链接快用完了,原来拥有锁的进程才不会频繁去抢锁

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
/* src/event/ngx_event.c */
ngx_int_t ngx_accept_disabled;   /* 资源分配负载均衡值。 */

/* src/event/ngx_event_accept.c */
void ngx_event_accept(ngx_event_t *ev) {
    ...
    do {
        ...
#if (NGX_HAVE_ACCEPT4)
        if (use_accept4) {
            s = accept4(lc->fd, &sa.sockaddr, &socklen, SOCK_NONBLOCK);
        } else {
            s = accept(lc->fd, &sa.sockaddr, &socklen);
        }
#else
        s = accept(lc->fd, &sa.sockaddr, &socklen);
#endif
        ...
        /* 每次 accept 链接资源后,都检查一下负载均衡数值。*/
        ngx_accept_disabled = ngx_cycle->connection_n / 8
                              - ngx_cycle->free_connection_n;

        c = ngx_get_connection(s, ev->log);
        ...
    } while (ev->available);
}

/* src/event/ngx_event.c */
void ngx_process_events_and_timers(ngx_cycle_t *cycle) {
    ...
    if (ngx_use_accept_mutex) {
        if (ngx_accept_disabled > 0) {
            /* ngx_accept_disabled > 0,说明很少空闲链接了,放弃抢锁。 */
            ngx_accept_disabled--;
        } else {
            /* 通过锁竞争,获得获取资源的权限。 */
            if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
                return;
            }
            ...
        }
    }
    ...
}

2.2. 独占资源

2.2.1. 概述

核心逻辑在这个函数 ngx_trylock_accept_mutex,获得锁的子进程,可以将共享的 listen socket 通过 epoll_ctl 添加到事件驱动进行监控,当有资源到来时,子进程通过 epoll_wait 获得通知处理。而没有获得锁的子进程的 epoll 没有关注 listen socket 的事件,所以它们的 epoll_wait 是不会通知 listen socket 的事件。


2.2.2. 源码分析

通过调试查看函数调用的堆栈工作流程。

1
2
3
4
5
6
7
8
9
10
# 子进程获取锁添加然后 listen socket 逻辑。
ngx_trylock_accept_mutex (cycle=0x72a6a0) at src/event/ngx_event_accept.c:323
# 子进程循环处理网络事件和时钟事件函数。
0x0000000000442059 in ngx_process_events_and_timers (cycle=0x72a6a0) at src/event/ngx_event.c:223
# 子进程工作逻辑。
0x000000000044f7c2 in ngx_worker_process_cycle (cycle=0x72a6a0, data=0x0) at src/os/unix/ngx_process_cycle.c:719
0x000000000044c804 in ngx_spawn_process (cycle=0x72a6a0, proc=0x44f714 <ngx_worker_process_cycle>, data=0x0, name=0x4da39f "worker process", respawn=-3) at src/os/unix/ngx_process.c:199
0x000000000044eb1e in ngx_start_worker_processes (cycle=0x72a6a0, n=2, type=-3) at src/os/unix/ngx_process_cycle.c:344
0x000000000044e31c in ngx_master_process_cycle (cycle=0x72a6a0) at src/os/unix/ngx_process_cycle.c:130
0x000000000040bdcf in main (argc=1, argv=0x7fffffffe578) at src/core/nginx.c:383

参考:gdb 调试 nginx(附视频)

可以通过下面源码分析查看抢锁的流程。

1
2
3
4
5
6
7
8
9
10
11
12
ngx_worker_process_cycle
|-- ngx_process_events_and_timers
    |-- ngx_trylock_accept_mutex
     if |-- ngx_shmtx_trylock
        |-- ngx_enable_accept_events
            |-- ngx_add_event
                |-- epoll_ctl(efd, EPOLL_CTL_ADD, listen_fd, ...);
   else |-- ngx_disable_accept_events
            |-- ngx_del_event
                |-- epoll_ctl(efd, EPOLL_CTL_DEL, listen_fd, ...);
    |-- ngx_process_events
    |-- ngx_shmtx_unlock
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
/* src/event/ngx_event.c */
ngx_shmtx_t           ngx_accept_mutex;      /* 进程共享互斥锁。 */
ngx_uint_t            ngx_use_accept_mutex;  /* accept_mutex 开启状态。 */
ngx_uint_t            ngx_accept_mutex_held; /* 表示当前进程是否可以获取资源。 */
ngx_int_t             ngx_accept_disabled;   /* 资源分配负载均衡值。 */

/* src/os/unix/ngx_process_cycle.c 
 * 子进程循环处理事件。*/
static void ngx_worker_process_cycle(ngx_cycle_t *cycle, void *data) {
    ...
    for ( ;; ) {
        ...
        ngx_process_events_and_timers(cycle);
        ...
    }
}

/* src/event/ngx_event.c 
 * 定时器事件和网络事件处理。*/
void ngx_process_events_and_timers(ngx_cycle_t *cycle) {
    ...
    if (ngx_use_accept_mutex) {
        /* 当 ngx_accept_disabled 越小,那么就越快执行抢锁的逻辑。 */
        if (ngx_accept_disabled > 0) {
            ngx_accept_disabled--;
        } else {
            /* 通过锁竞争,获得获取资源的权限。 */
            if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
                return;
            }
            ...
        }
    }
    ...
    /* 处理事件。 */
    (void) ngx_process_events(cycle, timer, flags);
    ...
    if (ngx_accept_mutex_held) {
        /* 释放锁。 */
        ngx_shmtx_unlock(&ngx_accept_mutex);
    }
    ...
}

/* src/event/ngx_event_accept.c */
ngx_int_t ngx_trylock_accept_mutex(ngx_cycle_t *cycle) {
    /* 尝试获得锁。 */
    if (ngx_shmtx_trylock(&ngx_accept_mutex)) {
        ...
        if (ngx_accept_mutex_held && ngx_accept_events == 0) {
            return NGX_OK;
        }

        /* 将 listen socket 添加到 epoll 事件驱动里。 */
        if (ngx_enable_accept_events(cycle) == NGX_ERROR) {
            ngx_shmtx_unlock(&ngx_accept_mutex);
            return NGX_ERROR;
        }

        ngx_accept_events = 0;
        /* 修改持锁的状态。 */
        ngx_accept_mutex_held = 1;

        return NGX_OK;
    }

    if (ngx_accept_mutex_held) {
        /* 获取锁失败,如果之前是曾经成功获取锁的,不能再获取资源了,将 listen socket 从 epoll 里删除。 */
        if (ngx_disable_accept_events(cycle, 0) == NGX_ERROR) {
            return NGX_ERROR;
        }

        /* 改变持锁的状态。 */
        ngx_accept_mutex_held = 0;
    }

    return NGX_OK;
}

/* 子进程 epoll_ctl 关注 listen socket 事件。 */
ngx_int_t ngx_enable_accept_events(ngx_cycle_t *cycle) {
    ngx_uint_t         i;
    ngx_listening_t   *ls;
    ngx_connection_t  *c;

    ls = cycle->listening.elts;
    for (i = 0; i < cycle->listening.nelts; i++) {
        c = ls[i].connection;
        ...
        /* 将共享的 listen socket 通过 epoll_ctl 添加到子进程的 epoll 中,
         * 当该 socket 有新的链接进来,epoll_wait 会通知处理。  */
        if (ngx_add_event(c->read, NGX_READ_EVENT, 0) == NGX_ERROR) {
            return NGX_ERROR;
        }
    }

    return NGX_OK;
}

/* 子进程 epoll_ctl 取消关注 listen socket 事件。 */
static ngx_int_t ngx_disable_accept_events(ngx_cycle_t *cycle, ngx_uint_t all) {
    ngx_uint_t         i;
    ngx_listening_t   *ls;
    ngx_connection_t  *c;

    ls = cycle->listening.elts;
    for (i = 0; i < cycle->listening.nelts; i++) {
        c = ls[i].connection;
        ...
        /* 子进程将共享的 listen socket 从 epoll 中删除,不再关注它的事件。 */
        if (ngx_del_event(c->read, NGX_READ_EVENT, NGX_DISABLE_EVENT)
            == NGX_ERROR)
        {
            return NGX_ERROR;
        }
    }

    return NGX_OK;
}

2.2.3. 抢锁成功率

很多时候,原来抢到锁的进程,大概率会重新抢到锁,原因在于 抢锁时机

  1. 原来抢到锁的进程,在抢到锁后会先处理完事件(ngx_process_events),然后才会释放锁,在这个过程中,其它进程一直抢不到:因为它们都是盲目地抢,不知道锁什么时候释放,而抢到锁的进程它释放锁后,自己马上抢回,相对于其它进程盲目地抢,它的成功率更高。😎
  2. 原来抢到锁的进程,什么时候才会不抢呢,就是要满足这个条件:ngx_accept_disabled > 0。因为 ngx_accept_disabled = ngx_cycle->connection_n / 8 - ngx_cycle->free_connection_n,一般情况下,当已使用链接超过了 7/8 了,也就是说空闲链接快用完了,才不愿意抢锁了。如果配置的链接总数很大,那么预分配的空闲链接没那么快用完,那么原进程就一直抢,因为它一释放锁就马上去抢,它抢到锁的成功率自然高!😂

所以基于上面两个条件,可能会导致:有些进程很忙,有些进程比较闲。


3. 缺点

  1. nginx 是多进程框架,accept_mutex 解决惊群的策略,使得在同一个时间段,多个子进程始终只有一个子进程可以 accept 链接资源,这样,不能充分利用其它子进程进行并发处理,在密集的短链接场景中,链接的吞吐将会遇到瓶颈。
  2. 避免了内核抢锁问题,转换为应用层抢锁,虽然抢的频率降低,但是进程多了,抢锁效率依然是个问题。
  3. 通过 ngx_accept_disabled 去解决负载均衡问题,因为上述抢锁时机问题,可能会导致某个子进程长时间占用锁,其它子进程得不到 accept 链接资源的机会。😂

通过 nginx 的更新日志,我们发现 2016 年这个 accept_mutex 功能被默认关闭。

1
2
3
4
Changes with nginx 1.11.3                                        26 Jul 2016

    *) Change: now the "accept_mutex" directive is turned off by default.
    ...

4. 参考