求助: 解决使用OpenResty实现TCP Proxy长连接占用大量内存

satannyq

试图使用OpenResty实现TCP Proxy, 在工作过程中client与server之间必须通过proxy维持tcp长连接.

在压测中发现, Proxy服务会消耗非常多的内存. 去掉所有逻辑代码后也是如此. 压测结果:

- 1w client, 使用110M内存

- 3w client, 使用600M+内存, 并且会出现客户端断线重连

---

压测环境

- 客户端部署说明

- 通过三台不同机器模拟产生, 并且处理两个不同网络. 并且

- 直连后端TCP服务则不会出现任何断线重连问题.

- Proxy部署环境:

- 阿里云K8S集群, 节点机器资源无抢占. 并通过SLB暴露Proxy服务

- 资源申请: 2核2G

- docker基础镜像: openresty/openresty:alpine

- openresty version: openresty/1.15.8.2

- Linux version 3.10.0-693.2.2.el7.x86_64 (builder@kbuilder.dev.centos.org) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Tue Sep 12 22:26:13 UTC 2017

- Linux目前没有做任何TCP调优配置, 使用默认配置

---

配置如下:

```nginx.conf

user root;

pid /var/run/nginx.pid;

daemon off;

worker_processes 2;

worker_rlimit_nofile 65535;

error_log /dev/stdout debug;

events {

use epoll;

worker_connections 65535;

multi_accept on;

}

stream {

upstream backend_chash {

server 10.0.3.220:30022;

}

server {

listen 8081;

access_log off;

proxy_pass backend_chash;

}

# 为K8S探针提供, 可忽略不计

http {

resolver 223.5.5.5;

charset UTF-8;

include conf/mime.types;

server {

listen 8080;

server_name _;

access_log off;

# 健康检查

location /actuator/health {

default_type application/json;

return 200 '{"status":"UP"}';

}

```

satannyq

修正:
每1w client 大约占用220m内存.

---
补充:
目前直接使用Nginx进行测试, 结果与OR相同.

- docker基础镜像: nginx:1.17.9-alpine

配置如下:
```nginx.conf
user    root;
pid     /var/run/nginx.pid;
# daemon  off;

worker_processes    4;
worker_rlimit_nofile    65535;

error_log   /dev/stdout debug;

events {
        use     epoll;
        worker_connections  65535;
        multi_accept    on;
}

stream {
        upstream backend_chash {
                server 10.0.3.220:30022;
        }

        server {
                listen 8081;
                access_log off;

                proxy_pass      backend_chash;
        }
}

# 为K8S探针提供, 可忽略不计
http {
        resolver    223.5.5.5;
        charset     UTF-8;

        server {
                listen 8080;
                server_name _;
                access_log off;

                # 健康检查
                location /actuator/health {
                        default_type application/json;
                        return 200 '{"status":"UP"}';
                }
        }
}
```

doujiang24

算下来，平均每个连接 20K+ 的水平，这个值不算离谱了

首先每个连接在内核层面会占用一些内存，我以前的经验是 8k

然后 nginx 对每个连接又有内存池，通常也是几 k

优化空间还是有的，比较容易的是分析下 nginx 连接级别的内存池占用

倪颖强 <sat...@gmail.com> 于2020年3月12日周四下午12:07写道：

修正:
每1w client 大约占用220m内存.

---
补充:
目前直接使用Nginx进行测试, 结果与OR相同.

- docker基础镜像: nginx:1.17.9-alpine

配置如下:
```nginx.conf
user    root;
pid     /var/run/nginx.pid;
# daemon  off;

worker_processes    4;
worker_rlimit_nofile    65535;

error_log   /dev/stdout debug;

events {
        use     epoll;
        worker_connections  65535;
        multi_accept    on;
}

stream {
        upstream backend_chash {
                server 10.0.3.220:30022;
        }

        server {
                listen 8081;
                access_log off;

                proxy_pass      backend_chash;
        }
}

# 为K8S探针提供, 可忽略不计
http {
        resolver    223.5.5.5;
        charset     UTF-8;

        server {
                listen 8080;
                server_name _;
                access_log off;

                # 健康检查
                location /actuator/health {
                        default_type application/json;
                        return 200 '{"status":"UP"}';
                }
        }
}
```

satannyq

感谢您的回复.

这样的内存占用对于需要支撑几十万长连接的服务集群来说消耗非常大. 我还是去想想其他办法吧...

在 2020年3月14日星期六 UTC+8上午2:07:19，doujiang写道：

算下来，平均每个连接 20K+ 的水平，这个值不算离谱了
首先每个连接在内核层面会占用一些内存，我以前的经验是 8k
然后 nginx 对每个连接又有内存池，通常也是几 k

优化空间还是有的，比较容易的是分析下 nginx 连接级别的内存池占用

倪颖强 <sata...@gmail.com> 于2020年3月12日周四下午12:07写道：
修正:
每1w client 大约占用220m内存.

---
补充:
目前直接使用Nginx进行测试, 结果与OR相同.

- docker基础镜像: nginx:1.17.9-alpine

配置如下:
```nginx.conf
user    root;
pid     /var/run/nginx.pid;
# daemon  off;

worker_processes    4;
worker_rlimit_nofile    65535;

error_log   /dev/stdout debug;

events {
        use     epoll;
        worker_connections  65535;
        multi_accept    on;
}

stream {
        upstream backend_chash {
                server 10.0.3.220:30022;
        }

        server {
                listen 8081;
                access_log off;

                proxy_pass      backend_chash;
        }
}

# 为K8S探针提供, 可忽略不计
http {
        resolver    223.5.5.5;
        charset     UTF-8;

        server {
                listen 8080;
                server_name _;
                access_log off;

                # 健康检查
                location /actuator/health {
                        default_type application/json;
                        return 200 '{"status":"UP"}';
                }
        }
}
```