关于近期遇到的 C++ 服务器 内存泄漏排查

前言：

1.平台使用C++开发，底层基于MFC做的UI界面；

2.为了便于平台更新，使用的C++ 结合 Lua 状态机 的模式，部分业务逻辑使用Lua脚本实现，好处就是可以热更；

3.最近做了个排行数据库服务器，使用作为C++主程序，姑且简称程序X，所有的业务逻辑都用Lua实现，且平台很多底层都用到完全一样的程序X，可以说程序X是很稳定的；

 

重点：

然而，排行服务器上线之后，经过一段时间的观察，内存一直在涨；

刚开始还以为是消息频率和业务复杂度的问题，可能会稍微比其他服务器高一些，但最多也不会超过1G；

然而，很快达到1G的报警阈值；

甚至，半个月后，涨到 2G，3G 内存占用量！

这不是好现象，开始排查；

 

排查思路：

1.由于程序X一直很稳定，很自然滴，认为故障大概率的Lua业务脚本中，就这样想方设法排查了一周，然没任何进展，脚本代码看了一遍又一遍，都没啥问题；

2.继续观察Lua内存使用情况  collectgarbage("count") 得到的Lua内存使用基本每个线程都只有300k，没啥问题啊；

3.然而我还是继续找Lua脚本的内存问题，后来把所有的 Lua 中 _G 表中所有内容输出，观察了几天，确定没啥问题！

4.蛋疼了，难道是C++问题？

5.排查是否创建了TCP连接对象，但又没连接上，却持续往对象中请求发送消息，导致待发送的消息池堆积？有这种可能！毕竟之前项目组有遇到郭这种状况，就这样继续排查了2天，证实...没问题....

6.换个思路，开始比对同级别的项目脚本和各种配置文件，希望能查出问题，然而基本没啥不一样的，就算代码有一定差异，也不可能存在内存泄露的问题！

7.就这样继续想尽办法继续查，就在昨天晚上，想着会不会是系统库文件，或者，程序运行环境的问题，于是对比类似项目的目录文件，还真发现不一致的，缺了 【 mfcm140u.dll 】【 mfc140u.dll 】，因为我们是用 X64 环境编译的程序，然而在我们的服务器运行目录下缺少这几个动态库，系统目录下也找了，但在64位目录下没找到这几个库，于是，猜测是系统库引起的，把库补齐，重启了程序X，目前还没确定是否该问题，但能看得出来，内存工作集有增有降了，峰值工作集也没涨得那么夸张，总感觉看到曙光，继续观察ing，待续。。。

 

------------------------------------------------------  华丽分割线 ---------------------------------------------

2020-12-17

前面说的，怀疑是系统库问题，经过验证，并非系统库！

且，特大好消息，问题已修复！

经过2个多月的反复排查C++代码和Lua脚本代码，可以确定脚本没有内存泄漏，而C++代码也来来回回完整地排查好几轮，确定是没啥问题的；

最终，唯一有可能的，值得怀疑的，就是ODBC驱动版本问题；

由于平台一直使用的ODBC 5.2版本，刚开始虽然有怀疑过驱动版本问题，但平台大部分地方都在使用，所以呢，被我默默地排除可能性。。。

 

昨天平台维护，壮着胆子，把驱动升级到ODBC8.0版本，观察了内存变化，不涨了。。。不涨了。。。不涨了。。。。。。。