dyups: https session重用的内存泄漏 // dyups: memory leak of ssl session reuse

[powerdesigner]

dyups组件是不是真如github上有人留言的那样，与https不兼容而导致内存泄漏。我目前就遇到跟那位反馈者类似的问题，场景也是https，困扰我半个多月了。经过持续跟踪，我发现lua的GC一直很小，怀疑泄漏点像是出在该组件上。能确认这是个BUG吗？如果是，有没有修复计划？

原反馈地址及讨论组帖子地址
yzprofile/ngx_http_dyups_module#67
https://groups.google.com/forum/#!topic/openresty/C_rnBilveJM

[chobits]

能否提供一下内存泄露的一些debug数据。邮件里agentzh已经提供了1个方法来帮助分析nginx中内存占用了。

另外我们这边，有个探测ngx中pool内存占用的工具ngx_debug_pool

• for tengine: 从2.2.2开始内置模块
• for nginx: here

如果是dyups的pool中内存占用过高，使用该工具会出现：ngx_dyups_init_upstream这个项目会一直增大。

提供如上一些信息来帮助开发者来定位会加速问题解决。

另外如果能够提供完整的reproduce方法，让开发者在自己环境中复现会更容易定位。

[chobits]

referer to yzprofile/ngx_http_dyups_module#67

[zhaiyan1234]

问题解决了吗？
目前改问题比较好复现，复现条件：
（1）使用dyups设置upstream；
（2）upstream server设置为短连接（Connection: close）;
（3）配置为proxy_ssl_session_reuse on; （该配置默认为on）；
当设置为这3个条件后，压测会出现内存泄露
不知道tengine是否计划解决这个问题？

[zhaiyan1234]

分别看了一下nginx round robin和dyups处理ssl session的代码，nginx round robin内的session是属于每个peer的，意味着单个upstream ip全局只会存在一个session，而dyups是分别属于每个的request的，这里是有坑的，request的pool relese的时根本没有调用ssl_free，造成这个session结构体泄露

[chobits]

分别看了一下nginx round robin和dyups处理ssl session的代码，nginx round robin内的session是属于每个peer的，意味着单个upstream ip全局只会存在一个session，而dyups是分别属于每个的request的，这里是有坑的，request的pool relese的时根本没有调用ssl_free，造成这个session结构体泄露

欢迎提交patch。如果属实，这将是一个有意义得修复

---

我简单看了下逻辑。你描述中ssl_free指的具体是什么函数？我浏览dyups代码 session 相关是存在这样逻辑：

tengine/modules/ngx_http_upstream_dyups_module/ngx_http_dyups_module.c

Line 2432 in e3b0618

ngx_ssl_free_session(old_ssl_session);

[ygm521]

@chobits 我这也有此情况，与后端session 复用，开启会话保持，内存泄漏。nginx round robin内的session是属于每个peer的，意味着单个upstream ip全局只会存在一个session，而sticky模块针对每请求的。

[chobits]

@chobits 我这也有此情况，与后端session 复用，开启会话保持，内存泄漏。nginx round robin内的session是属于每个peer的，意味着单个upstream ip全局只会存在一个session，而sticky模块针对每请求的。

我大致能力理解，但是需要对一下代码细节和复现方式（#1016 (comment) ）。如果 直接开pr提交patch 可以加速开发者定位。

[chobits]

分别看了一下nginx round robin和dyups处理ssl session的代码，nginx round robin内的session是属于每个peer的，意味着单个upstream ip全局只会存在一个session，而dyups是分别属于每个的request的，这里是有坑的，request的pool relese的时根本没有调用ssl_free，造成这个session结构体泄露

ngx round robin中

ngx_http_upstream_save_round_robin_peer_session
  ->  peer->ssl_session = ssl_session;  
    // 这里将连接上SSL上得session抓取下来存在关联得peer上
    // peer关联peers(来自cf->pool)，实际相当于session得索引被 ngx conf抓取到+1

而dyups逻辑

ngx_http_dyups_save_peer_session
  ->  ctx->ssl_session = ssl_session;
// ctx是从r->pool上生成，相当于ssl_session得索引被r抓取，随着r释放后，这个索引没有-1（ssl session free)
// 另外还有一个问题，由于ssl_session是存在当前r的ctx上，下一个请求r'再次进来后其新生成的ctx上是没有ssl session
// 导致ssl session reuse也不生效

产生 1. session 泄露，2. session reuse逻辑失效。
临时修复是关闭后端的session reuse逻辑 (关闭配置proxy_ssl_session_reuse)

---

这个可能没有简单的修复方法，需要重新设计下session关联在worker cf还是dyups自己的sharedmem上。
需要特别注意dyup的peers是多worker共享的，而非正常情况下peers是单个worker的cf pool产生的

[chobits]

hi @zhaiyan1234 @ygm521

I have opened a pull request(#1708) to fix this issue, you can try the patch firstly. More test cases need to be added.

Patch: https://patch-diff.githubusercontent.com/raw/alibaba/tengine/pull/1708.patch

[chobits]

hi @zhaiyan1234 @ygm521

I also fixed memory leak of ssl session reuse in session sticky module in the same pr: (#1708)

try patch firstly: https://patch-diff.githubusercontent.com/raw/alibaba/tengine/pull/1708.patch