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

249 views
Skip to first unread message

倪颖强

unread,
Mar 11, 2020, 10:50:20 PM3/11/20
to openresty
试图使用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 (bui...@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"}';
                }
        }
}
```
Message has been deleted

倪颖强

unread,
Mar 12, 2020, 12:07:20 AM3/12/20
to openresty
修正:
每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;

DeJiang Zhu

unread,
Mar 13, 2020, 2:07:19 PM3/13/20
to open...@googlegroups.com
算下来,平均每个连接 20K+ 的水平,这个值不算离谱了
首先每个连接在内核层面会占用一些内存,我以前的经验是 8k
然后 nginx 对每个连接又有内存池,通常也是几 k

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


倪颖强 <sata...@gmail.com> 于2020年3月12日周四 下午12:07写道:
--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty...@googlegroups.com
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+...@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html
---
您收到此邮件是因为您订阅了Google网上论坛上的“openresty”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到openresty+...@googlegroups.com
要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/openresty/ecdf8c94-518b-4594-a3db-b342bfd4f1f8%40googlegroups.com

倪颖强

unread,
Mar 15, 2020, 9:43:21 PM3/15/20
to openresty
感谢您的回复.

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

在 2020年3月14日星期六 UTC+8上午2:07:19,doujiang写道:
订阅: 请发空白邮件到 open...@googlegroups.com
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 open...@googlegroups.com

归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html
---
您收到此邮件是因为您订阅了Google网上论坛上的“openresty”群组。
要退订此群组并停止接收此群组的电子邮件,请发送电子邮件到openresty+unsubscribe@googlegroups.com
要在网络上查看此讨论,请访问https://groups.google.com/d/msgid/openresty/ecdf8c94-518b-4594-a3db-b342bfd4f1f8%40googlegroups.com
Reply all
Reply to author
Forward
0 new messages