问题描述
A服务，是一个检测MGR集群主节点是否发生变化的服务，使用python语言实现的。
针对每个集群，主线程会创建一个子线程，并由子线程去检测。子线程会频繁的创建和销毁。
上线以后，由于经常会有功能发布，从而重启服务，开始一段时间没有发现问题。
半个月前的周二服务发布后，大约一周时间，没有再发布。到周末的时候，突然告警系统负载高，经过排查，发现内存几乎耗尽，并查到是A服务占用巨大内存，没有释放。
排查过程
已经确定，A服务是存在内存泄露的，到底是什么地方内存使用完，却没有释放呢？
这是一个令人头疼的问题，以前确实没有遇到过Python的内存泄露。
首先，网上搜索关于python内存泄漏的问题。大体了解到，Python的内存回收是基于引用计数的，也就是说，如果某个对象被使用一次，引用计数就会增加1。对象的引用计数为0时，内存就会被回收掉。
常见的导致内存泄露的情况有两种：
- (1)对象一直被全局变量使用，全局变量生命周期比较长，所以内存一直得不到释放。
- (2)循环引用中的对象定义了__del__的情况.
网上提供了各种用于排查内存泄露的工具，例如objgraph、guppy、pympler等，其具体使用参考文后的链接。
看了半天这些工具的使用，感觉还是应该看看自己代码，是不是存在对象使用完，但是一直被引用的情况。
首先，排查内存泄露的位置是在主线程还是子线程。通过查看，发现「子线程一直在执行」与「子线程频繁创建和退出」两种情况下，内存消耗差别较大， 而且「子线程一直在执行」内存消耗很小。这样，就可以定位到，内存泄露位置是在主线程或「子线程loop之前的代码」。
接着，屏蔽子线程，发现内存正常。
所以，定位到问题是在「子线程loop之前的代码」中。
最后，发现是频繁调用第三方包的函数导致的。
解决办法
找到问题的原因了，那么解决方法就好办了。改用其他的包或修改使用方式，绕开这个大坑。
参考
一次调试python内存泄露的问题
使用gc、objgraph干掉python内存泄露与循环引用！
Python内存优化：Profile，slots，compact dict