关于 Reactor 请求分配的问题

[suyar]

本文将讨论以下问题：高并发下，dispatch_mode=2 时 Reactor 在分配请求到 Worker 时负载不均衡

---

查找到的相关 issue

• dispatch_mode = 2 时，分配worker有问题 #766

事件背景

之前业务稳定日活在2万左右，容器的 cpu 一直稳定在 50% 以下，最近两天堆量日活达到6万，容器 cpu100% 预警，并且 P90 出现了从 50ms 飙升到了 2000ms，遂进行了如下排查：

• 容器是否进行了资源限制：否
• 是否内存泄漏：否（容器内存占用200M）
• 服务器资源：CPU8核（使用率60%），32G内存（使用率55%），磁盘IO（iops和io读写均未达到上限的50%），服务器负载（5-16之间波动）
• 使用框架：hyperf（SWOOLE_PROCESS模式）
• 是否有出现 mysql、redis 连接池等待超时：无；容器日志、框架日志均未出现现象级错误
• PHP版本：8.2.15
• 请求链路：nginx -> hyperf（run in docker）

PHP扩展安装列表

[PHP Modules]
apcu
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
FFI
fileinfo
filter
ftp
gd
gettext
hash
iconv
igbinary
imagick
intl
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
random
readline
redis
Reflection
session
shmop
SimpleXML
sockets
sodium
SPL
standard
swoole
sysvmsg
sysvsem
sysvshm
tokenizer
xml
xmlreader
xmlwriter
xsl
yaml
Zend OPcache
zip
zlib
[Zend Modules]

Zend OPcache

Swoole扩展信息

Swoole => enabled
Author => Swoole Team 
Version => 5.1.1
Built => Dec  1 2023 13:40:51
coroutine => enabled with boost asm context
epoll => enabled
eventfd => enabled
signalfd => enabled
cpu_affinity => enabled
spinlock => enabled
rwlock => enabled
sockets => enabled
openssl => OpenSSL 1.1.1f  31 Mar 2020
dtls => enabled
http2 => enabled
json => enabled
curl-native => enabled
pcre => enabled
mutex_timedlock => enabled
pthread_barrier => enabled
futex => enabled
mysqlnd => enabled
async_redis => enabled
Directive => Local Value => Master Value

swoole.enable_coroutine => On => On

swoole.enable_library => On => On

swoole.enable_fiber_mock => Off => Off

swoole.enable_preemptive_scheduler => Off => Off

swoole.display_errors => On => On

swoole.use_shortname => Off => Off

swoole.unixsock_buffer_size => 8388608 => 8388608

TCP连接数活跃在 5K 以上：

Swoole setting 相关配置如下：

array:10 [
  "enable_coroutine" => true
  "worker_num" => 8
  "pid_file" => "/www/runtime/hyperf.pid"
  "open_tcp_nodelay" => true
  "max_coroutine" => 100000
  "open_http2_protocol" => true
  "max_request" => 10000
  "socket_buffer_size" => 2097152
  "buffer_output_size" => 104857600
  "package_max_length" => 104857600
]

其中 dispatch_mode 未配置，默认值未 2.

对容器内进程进行排查，发现几乎只有一个 worker 进程的CPU一直居高不下，占用率第二的是定时任务：

看起来似乎其他处理请求的 worker 都在划水，emmm....
不死心的我看了下其他业务的容器，发现都是相同情况。

上述相关 issue 中，@matyhtf 有提到：dispatch_mode=2/4/5 这些固定分配的模式，如果并发客户端数量比 Worker 进程少，一定是无法利用所有Worker进程的。，但是我的并发肯定是超过 8 个 worker 的数量的，还是会出现这种场景。考虑到以后大概率会引入 websocket，所以目前并不适合去改 dispatch_mode=1/3.

假设是这样的话，是不是表示 Reactor 线程在分配请求到 worker 的时候，根据 fd 并不能很好的做到均衡？
当前我的做法是额外启动了两个容器，用 nginx 做了负载均衡，暂时解决了容器 cpu100% 的问题，P90 延迟也恢复了正常。

问题&猜想

1. dispatch_mode=2 的模式下，Reactor 线程是根据什么来分发请求到 worker 的？
2. 在文档中看到了 dispatch_mode=7 的模式，但是文档中并没有过多描述使用场景，什么情况下可以使用？
3. swoole 配置中，为了防止意外的内存泄漏，配置了 max_request 参数，这个参数会导致 worker 重建，是否会影响 fd 的分配平衡？
4. 有什么调整建议，才能让请求相对均匀的分配到各个 worker？

[matyhtf]

dispatch_mode=2 默认是使用 fd (操作系统文件描述符) % worker_num 来分配的。也就是同一个连接的所有请求都会固定分配到同一个 worker 进程。

[suyar]

dispatch_mode=2 默认是使用 fd (操作系统文件描述符) % worker_num 来分配的。也就是同一个连接的所有请求都会固定分配到同一个 worker 进程。

但是很奇怪，我们的QPS区间在30-100以内波动，worker1 的 cpu 使用率明显高于其他 worker， 大部分 worker 像是没在活动，有什么配置或者请求链路会影响到平衡么？

[matyhtf]

可以使用 getClientInfo 获取到连接的 fd 做一个统计，看看是不是分配到 worker-0 的更多。可以切换为 SWOOLE_BASE 模式或者修改 dispatch_mode 为其他试试看

[suyar]

@matyhtf 最近有空，简单写了个统计的代码，发现确实确实和预期的分配不一致，代码如下：

<?php

declare(strict_types=1);

function my_dispatch_mode(Swoole\Server $server, $fd, $data)
{
    return $fd % 8;
}

$table = new Swoole\Table(512);
$table->column('count', Swoole\Table::TYPE_INT);
$table->create();

$http = new Swoole\Http\Server('0.0.0.0', 9501, SWOOLE_PROCESS);
$http->set([
    'worker_num' => 8,
    'enable_coroutine' => true,
    'dispatch_mode' => 2,
    // 'dispatch_func' => 'my_dispatch_mode',
]);

$http->on('request', function (Swoole\Http\Request $request, Swoole\Http\Response $response) use ($http, $table) {
    if ($request->server['request_uri'] === '/count') {
        echo "=====统计数据如下=====\n";
        $arr = [];
        foreach ($table as $key => $row) {
            $arr[$key] = "{$key} ———— count: {$row['count']}";
        }
        ksort($arr);
        echo implode("\n", $arr) . "\n";
    } else {
        $fdKey = sprintf('fd %% 8 = %s', $request->fd % 8);
        $workerKey = sprintf('worker = %s', $http->worker_id);
        $table->incr($fdKey, 'count');
        $table->incr($workerKey, 'count');
        echo "fd: {$request->fd} ———— worker: {$http->worker_id}\n";
    }

    $response->end("Hello Swoole.\n");
});

$http->start();

场景1：使用 dispatch_mode=2 ，并且使用如下方式进行并发测试：

ab -n 1000 -c 4 http://127.0.0.1:9501/

测试结果如下：

...省略部分
fd: 987 ———— worker: 7
fd: 985 ———— worker: 5
fd: 988 ———— worker: 4
fd: 989 ———— worker: 5
fd: 990 ———— worker: 6
fd: 991 ———— worker: 4
fd: 992 ———— worker: 4
fd: 993 ———— worker: 5
fd: 995 ———— worker: 7
fd: 994 ———— worker: 6
fd: 996 ———— worker: 4
fd: 997 ———— worker: 5
fd: 998 ———— worker: 6
fd: 999 ———— worker: 7
fd: 1000 ———— worker: 4
=====统计数据如下=====
fd % 8 = 0 ———— count: 125
fd % 8 = 1 ———— count: 125
fd % 8 = 2 ———— count: 125
fd % 8 = 3 ———— count: 125
fd % 8 = 4 ———— count: 125
fd % 8 = 5 ———— count: 125
fd % 8 = 6 ———— count: 125
fd % 8 = 7 ———— count: 125
worker = 4 ———— count: 302
worker = 5 ———— count: 266
worker = 6 ———— count: 239
worker = 7 ———— count: 193

虽然ab并发设置为4，自己对请求的 fd % worker_num 以及每个 worker 处理的请求数进行统计，但是 fd % worker_num 预期分配到8个 worker 里进行处理，但是实际上只有4个 worker 收到了请求.

场景2：使用自定义 dispatch_func=my_dispatch_mode ，使用相同方式进行并发测试：

ab -n 1000 -c 4 http://127.0.0.1:9501/

测试结果如下：

...省略部分
fd: 988 ———— worker: 4
fd: 990 ———— worker: 6
fd: 991 ———— worker: 7
fd: 992 ———— worker: 0
fd: 993 ———— worker: 1
fd: 998 ———— worker: 6
fd: 995 ———— worker: 3
fd: 1000 ———— worker: 0
fd: 999 ———— worker: 7
fd: 994 ———— worker: 2
fd: 996 ———— worker: 4
fd: 997 ———— worker: 5
=====统计数据如下=====
fd % 8 = 0 ———— count: 125
fd % 8 = 1 ———— count: 125
fd % 8 = 2 ———— count: 125
fd % 8 = 3 ———— count: 125
fd % 8 = 4 ———— count: 125
fd % 8 = 5 ———— count: 125
fd % 8 = 6 ———— count: 125
fd % 8 = 7 ———— count: 125
worker = 0 ———— count: 125
worker = 1 ———— count: 125
worker = 2 ———— count: 125
worker = 3 ———— count: 125
worker = 4 ———— count: 125
worker = 5 ———— count: 125
worker = 6 ———— count: 125
worker = 7 ———— count: 125

此场景下，我们也是用自定义函数对 fd % worker_num 进行 worker 进行请求分配，并发为 4 的场景下也能很好的分配到 8 个 worker.

按我的理解，代码里 dispatch_mode=2 也是用 fd 进行求模，此 fd 非彼 fd ？

swoole-src/src/server/master.cc

Lines 1308 to 1368 in 59f265b

	int Server::schedule_worker(int fd, SendData *data) {
	uint32_t key = 0;
	if (dispatch_func) {
	int id = dispatch_func(this, get_connection(fd), data);
	if (id != DISPATCH_RESULT_USERFUNC_FALLBACK) {
	return id;
	}
	}
	// polling mode
	if (dispatch_mode == DISPATCH_ROUND) {
	key = sw_atomic_fetch_add(&worker_round_id, 1);
	}
	// Using the FD touch access to hash
	else if (dispatch_mode == DISPATCH_FDMOD) {
	key = fd;
	}
	// Using the IP touch access to hash
	else if (dispatch_mode == DISPATCH_IPMOD) {
	Connection *conn = get_connection(fd);
	Address *addr;
	if (conn == nullptr) {
	DgramPacket *packet = (DgramPacket *) data->data;
	addr = &packet->socket_addr;
	} else {
	addr = &conn->info;
	}
	if (Socket::is_inet4(addr->type)) {
	key = ntohl(addr->addr.inet_v4.sin_addr.s_addr);
	} else {
	key = swoole_hash_php((char *) &addr->addr.inet_v6, sizeof(addr->addr.inet_v6));
	}
	} else if (dispatch_mode == DISPATCH_UIDMOD) {
	Connection *conn = get_connection(fd);
	if (conn == nullptr || conn->uid == 0) {
	key = fd;
	} else {
	key = conn->uid;
	}
	} else if (dispatch_mode == DISPATCH_CO_CONN_LB) {
	Connection *conn = get_connection(fd);
	if (conn == nullptr) {
	return fd % worker_num;
	}
	if (conn->worker_id < 0) {
	conn->worker_id = get_lowest_load_worker_id();
	}
	return conn->worker_id;
	} else if (dispatch_mode == DISPATCH_CO_REQ_LB) {
	return get_lowest_load_worker_id();
	} else if (dispatch_mode == DISPATCH_CONCURRENT_LB) {
	return get_lowest_concurrent_worker_id();
	}
	// deliver tasks to idle worker processes
	else {
	return get_idle_worker_id();
	}
	return key % worker_num;
	}