ngx_http_dyups_module
ngx_http_dyups_module copied to clipboard
yzprofile
存在内存泄露的问题
使用ngx_http_dyups动态创建的upstream后内存会一直增长直到服务器失去响应，最后定位到应该是ngx_http_dyups模块存在内存泄露，google之发现以前也有人遇到过类型的问题，参考这里
@yfgu @iandyh 该问题你们的解决方案是什么呢？由于压测疏忽，基于该组件的项目已经上线，更换成本太高了，苦命 @yzprofile 恳请大神有空时看看能否修复该问题。
能否提供一下内存泄露的一些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 以下是debug_pool信息 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 587 9435 673 3992 12325 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 593 9429 673 3992 12319 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 595 9428 673 3992 12317 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 597 9425 673 3992 12315 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 599 9424 673 3992 12313 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 601 9422 673 3992 12312 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 602 9420 673 3992 12310 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 605 9417 673 3992 12307 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 605 9417 673 3992 12307 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 606 9416 673 3992 12306 Swap: 0 0 0 [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 607 9415 673 3992 12305 Swap: 0 0 0 [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7759 size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 65536 num: 4120 cnum: 3 lnum: 9814 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 33648 num: 8238 cnum: 2 lnum: 12357 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 37888 num: 172 cnum: 3 lnum: 4616 ngx_event_accept size: 577KB num: 12827 cnum: 53 lnum: 27047 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7759 size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 180224 num: 4300 cnum: 7 lnum: 10273 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 100944 num: 8596 cnum: 6 lnum: 12894 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 111104 num: 181 cnum: 8 lnum: 4815 ngx_event_accept size: 826KB num: 13374 cnum: 66 lnum: 28242 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7757 size: 150720 num: 252 cnum: 44 lnum: 266 ngx_dyups_init_upstream size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 36864 num: 1034 cnum: 2 lnum: 2498 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 16824 num: 2066 cnum: 1 lnum: 3099 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 19712 num: 51 cnum: 2 lnum: 1173 ngx_event_accept size: 515KB num: 3471 cnum: 50 lnum: 7052 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7759 size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 163840 num: 4844 cnum: 7 lnum: 11613 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 84264 num: 9681 cnum: 6 lnum: 14520 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 110592 num: 198 cnum: 7 lnum: 5412 ngx_event_accept size: 794KB num: 15020 cnum: 65 lnum: 31805 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7759 size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 36864 num: 5356 cnum: 2 lnum: 12884 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 16824 num: 10704 cnum: 1 lnum: 16056 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 20224 num: 217 cnum: 3 lnum: 5982 ngx_event_accept size: 516KB num: 16574 cnum: 51 lnum: 35182 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7761 size: 150720 num: 259 cnum: 44 lnum: 273 ngx_dyups_init_upstream size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 114688 num: 3640 cnum: 5 lnum: 8737 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 50688 num: 7198 cnum: 4 lnum: 10792 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 74752 num: 180 cnum: 6 lnum: 4195 ngx_event_accept size: 678KB num: 11345 cnum: 60 lnum: 24013 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7759 size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 36864 num: 5464 cnum: 2 lnum: 13156 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 16824 num: 10918 cnum: 1 lnum: 16377 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 3840 num: 222 cnum: 3 lnum: 6103 ngx_event_accept size: 500KB num: 16901 cnum: 51 lnum: 35896 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7757 size: 150720 num: 252 cnum: 44 lnum: 266 ngx_dyups_init_upstream size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 65536 num: 1220 cnum: 3 lnum: 2927 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 33648 num: 2436 cnum: 2 lnum: 3654 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 37888 num: 61 cnum: 3 lnum: 1387 ngx_event_accept size: 577KB num: 4037 cnum: 53 lnum: 8250 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7761 size: 150720 num: 259 cnum: 44 lnum: 273 ngx_dyups_init_upstream size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 180224 num: 3877 cnum: 7 lnum: 9318 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 100944 num: 7668 cnum: 6 lnum: 11499 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 94720 num: 191 cnum: 8 lnum: 4462 ngx_event_accept size: 810KB num: 12063 cnum: 66 lnum: 25568 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7754 size: 150720 num: 264 cnum: 44 lnum: 280 ngx_dyups_init_upstream size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 8192 num: 224 cnum: 1 lnum: 584 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 0 num: 446 cnum: 0 lnum: 669 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 1536 num: 14 cnum: 1 lnum: 263 ngx_event_accept size: 453KB num: 1016 cnum: 47 lnum: 1812 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7759 size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 122880 num: 5581 cnum: 5 lnum: 13421 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 67296 num: 11150 cnum: 4 lnum: 16725 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 74752 num: 229 cnum: 6 lnum: 6236 ngx_event_accept size: 702KB num: 17257 cnum: 60 lnum: 36642 [SUMMARY] [root@P-Nginx-01 ~]# curl 127.0.0.1:9088/debug_pool pid:7759 size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 36864 num: 5621 cnum: 2 lnum: 13518 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 16824 num: 11228 cnum: 1 lnum: 16842 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 37376 num: 231 cnum: 4 lnum: 6283 ngx_event_accept size: 532KB num: 17377 cnum: 52 lnum: 36903 [SUMMARY] [root@P-Nginx-01 ~]# free -m total used free shared buff/cache available Mem: 14016 869 9153 673 3993 12043 Swap: 0 0 0
hi @powerdesigner
从你的压测过程中debug_pool的信息看，是这个信息上涨
- ngx_http_create_request(请求内存池r->pool，cnum表示当前存在的池子数量，也是处理中的请求数)
- ngx_http_upstream_connect(后端连接内存是c->pool)
- ngx_event_accept（连接内存池c->pool）
这3个内存池都是浮动，理论上你把压测关闭后，这3个选项都应应该较低到很低才对。
而dyups使用的内存池内存占用一直没有变化：
- size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
另外还有1个信息关注下，保持一定压测平度一直不停，看看内存是否会不停消耗，还是只会消耗到一定程度（如果使用libc默认的内存分配器ptmalloc，有可能会缓存一部分内存不释放给os，这样即使你停止压测系统可用内存也不会下降）
@chobits 这么晚了还协助分析，非常感谢。我们曾保持压力不停，CentOS14G内存最后耗尽到只剩170M到150M之间，然后只在这两者范围内波动，没再继续下降。而生产环境中请求是一直存在的，无法寄希望于没请求后系统自动恢复。以下是我抓取的最新内存信息，压测在上午11点44左右就停止了。 total used free shared buff/cache available Mem: 14016 891 9047 689 4077 12008 Swap: 0 0 0
top - 14:41:11 up 23 days, 13:26, 1 user, load average: 0.22, 0.06, 0.11 Tasks: 164 total, 1 running, 163 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.3 us, 0.2 sy, 0.0 ni, 99.5 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 14352452 total, 9262344 free, 914264 used, 4175844 buff/cache KiB Swap: 0 total, 0 free, 0 used. 12295284 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
7759 nginx 20 0 297260 176868 5428 S 0.0 1.2 0:14.13 nginx
7761 nginx 20 0 246752 126704 5544 S 0.0 0.9 0:10.54 nginx
408 root 20 0 163820 99196 98832 S 0.0 0.7 4:58.31 systemd-journal
20861 influxdb 20 0 765820 74000 7920 S 0.7 0.5 0:41.43 influxd
7760 nginx 20 0 187404 66948 5484 S 0.0 0.5 0:05.92 nginx
7758 nginx 20 0 180560 60456 5468 S 0.0 0.4 0:05.36 nginx
892 root 20 0 602860 53788 51012 S 0.0 0.4 2:17.88 rsyslogd
7757 nginx 20 0 161136 40728 5400 S 0.0 0.3 0:03.84 nginx
7520 telegraf 20 0 727872 27500 9764 S 1.0 0.2 90:47.08 telegraf
21161 haproxy 20 0 69624 23116 700 S 1.7 0.2 179:03.68 haproxy
7756 nginx 20 0 142348 21896 5404 S 0.0 0.2 0:02.84 nginx
893 root 20 0 553712 18456 5676 S 0.0 0.1 3:02.96 tuned
1036 root 20 0 398724 17620 5328 S 1.0 0.1 140:11.24 python
7755 nginx 20 0 137224 16860 5392 S 0.0 0.1 0:02.14 nginx
7754 nginx 20 0 136272 16244 5400 S 0.0 0.1 0:02.09 nginx
896 root 20 0 222120 13324 4256 S 0.0 0.1 0:00.28 python
592 polkitd 20 0 633972 13024 4964 S 0.0 0.1 0:06.08 polkitd
843 root 20 0 113368 12780 296 S 0.0 0.1 0:00.00 dhclient
591 root 20 0 437492 7600 5920 S 0.0 0.1 0:04.56 NetworkManager
pid:7759
size: 150720 num: 230 cnum: 44 lnum: 244 ngx_dyups_init_upstream
size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked
size: 8192 num: 10856 cnum: 1 lnum: 20527 ngx_http_create_request
size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle
size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection
size: 0 num: 16966 cnum: 0 lnum: 25447 ngx_http_upstream_connect
size: 0 num: 1 cnum: 0 lnum: 0 main
size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker
size: 1536 num: 1255 cnum: 1 lnum: 14670 ngx_event_accept
size: 453KB num: 29374 cnum: 47 lnum: 60904 [SUMMARY]
pid:7761 size: 150720 num: 259 cnum: 44 lnum: 273 ngx_dyups_init_upstream size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 8192 num: 7829 cnum: 1 lnum: 14463 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 0 num: 11938 cnum: 0 lnum: 17904 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 1536 num: 2351 cnum: 1 lnum: 11474 ngx_event_accept size: 453KB num: 22445 cnum: 47 lnum: 44130 [SUMMARY]
pid:7756 size: 150720 num: 244 cnum: 44 lnum: 258 ngx_dyups_init_upstream size: 0 num: 62 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 8192 num: 1721 cnum: 1 lnum: 1715 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 0 num: 1420 cnum: 0 lnum: 2130 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 1536 num: 288 cnum: 1 lnum: 2958 ngx_event_accept size: 453KB num: 3740 cnum: 47 lnum: 7077 [SUMMARY]
pid:7760 size: 150720 num: 253 cnum: 44 lnum: 267 ngx_dyups_init_upstream size: 0 num: 63 cnum: 0 lnum: 0 ngx_http_dyups_read_msg_locked size: 8192 num: 3980 cnum: 1 lnum: 6987 ngx_http_create_request size: 303784 num: 2 cnum: 1 lnum: 12 ngx_init_cycle size: 0 num: 1 cnum: 0 lnum: 4 ngx_http_lua_create_fake_connection size: 0 num: 5916 cnum: 0 lnum: 8874 ngx_http_upstream_connect size: 0 num: 1 cnum: 0 lnum: 0 main size: 0 num: 1 cnum: 0 lnum: 0 ngx_http_lua_init_worker size: 1536 num: 1167 cnum: 1 lnum: 5972 ngx_event_accept size: 453KB num: 11384 cnum: 47 lnum: 22116 [SUMMARY]
@powerdesigner 从你最新的信息里top里看 软件内存占用并不高，ngx大致单worker160MB
整体top显示还有9G多 free ：KiB Mem : 14352452 total, 9262344 free,
你的压测方式得提供下，详细到第三方可以模拟出来
- 配置是怎样的
- 压测步骤是怎样的
- 请求压力如何构成
- 过程中是否变动upstream (这条非常关键: 这是dyups模块唯一可能内存变动点)
同样代码和dyups，在http场景下并未内存泄漏
dyups本身并不感知https/http
@powerdesigner 请问这个问题您解决了吗？我们在用这个模块时看到了这个issue，目前用的http没有出现内存泄漏，但后续可能会改为https。
目前改问题比较好复现，复现条件： （1）使用dyups设置upstream； （2）upstream server设置为短连接（Connection: close）; （3）配置为proxy_ssl_session_reuse on; （该配置默认为on）； 当设置为这3个条件后，不停的请求情况下会出现内存泄露，需要具体看upstream session reuse部分代码
目前把dyups自身实现的session给下掉了，不再save session，目前看来内存泄露问题不再存在了，希望官方给一个理想的修复方案，毕竟session reuse还是有好处的 PS: 目前实现dyups根本没实现session reuse
我这几天也在解决这个问题，确实是有内存泄漏，解决完之后发现这个存在很久的issue了，我的排查结论跟 @zhaiyan1234 一样。
你的压测方式得提供下，详细到第三方可以模拟出来
配置是怎样的
压测步骤是怎样的
- 请求压力如何构成
- 过程中是否变动upstream (这条非常关键: 这是dyups模块唯一可能内存变动点)
同样代码和dyups，在http场景下并未内存泄漏
dyups本身并不感知https/http
@chobits 虽然你说dyups本身不感知https，但是泄漏点就出在本模块的set_session和save_session这两个函数指针上，这两个正是与https相关的。复现很简单，如 @zhaiyan1234 在上面说的一样。
nginx默认是开启了proxy_ssl_session_reuse开关的，这个会导致set_session和save_session发生作用，而dyups这种在request上的peer我认为是没必要reuse_session的，会导致请求结束后没有free_ssl。
最简单的在线上环境避免该问题的方法是将proxy_ssl_session_reuse配置成off，但最根本的解决办法还是要修改一下本模块的set_session和save_session。
我个人目前的解决办法是将这两个函数的body都置为空。参考：https://github.com/RocFang/ngx_http_dyups_module/commit/4a1731b05ea9bd7d4c533d1600b7c8fec8a5f96e
下面附上确定是这个地方导致内存泄漏的排查过程相关材料：
-
采集内存泄漏火焰图可看到大量ngx_ssl_handshake的内存没有释放。
-
初步怀疑是openssl版本问题，但升级若干个openssl版本，均存在内存泄漏。
-
进而继续定位到本模块，只要将set_session和save_session的body置为空，或者关闭proxy_ssl_session_reuse配置，内存泄漏的现象马上消失。正常的火焰图这里就不必截出来了。
事实上，在nginx的历史代码中，也曾经存在过类似问题，参看： http://hg.nginx.org/nginx/rev/ff127ba3b091?revcount=240
我也查了一下本模块这两个函数的提交：https://github.com/yzprofile/ngx_http_dyups_module/commit/5b6bac5c3845e50d5a2e59ad93b8b27c02a01e68#diff-542d0606cf0e5efad29466029ed91845 从commit message里来看只是为了解决https时的core dump，但不知道这两个函数有经过实际的功能和压力测试吗？
综上，我认为要么应该直接像我一样简单的将这两个函数置为空，要么重新设计一下这两个函数。
@RocFang @yzprofile
I redesigned set_session and save_session function, the new solution will solve memory leak issue and keep ssl session reuse work. #143
