上币交易系统优化

问题描述

今天bithumb发公告上ENJ和PST这两个币种。我在外面准备陪我妈去中山，收到这个公告消息的时候停高兴的，以为我的自动交易系统会买入这两个币，还兴冲冲的让亲爱的去帮我去gate上面卖出以为存在的PST。结果却发现我并没有买入PST，回到家中后检查发现是我的服务器挂了。

初步原因分析

因为我对异常的处理是特别的完善了，而且log里面也没有有异常导致服务器挂掉的字样，所以初步判断是由于服务器资源消耗太多，使得服务器将我的程序杀掉了，这点从vultr的服务器数据图表也可以看得出来。

vultr服务器图表

从日志中，我知道服务器挂掉的时候约为26号22点，这点跟图表上面的数据高度吻合。
从图表上面看，最有可能的原因是程序在往硬盘上面疯狂的读数据，导致被服务器杀死，这点特别的诡异。
我的代码当中涉及到读数据相关的操作有如下几种
1、读取配置文件
2、读取数据库中的数据

那么可能的原因是什么

这个问题比较难解决，复现一下可能更好点
现在我有一个新的思路，就是模拟不断读取配置文件或者读取数据库中数据的过程，来复现这个过程，看它们表现十分一致。
当我准备验证这两个的时候，我发现了另外一种可能性，通过对var/log/message日志的查看，我发现上面说的是内存不足，所以杀死了我的程序。
通过观察，我发现list pump运行后占用的内存比例一直在上升。
那么从目前来看，内些泄漏的可能性更大了，内存泄漏使得内存的全都被占用，然后触发了系统回收操作。在系统回收操作的过程中，会读取硬盘，所以出现了硬盘读取量特别大的现象。

验证猜想

我将程序拆分为两个部分，获取数据和获取公告，将两个部分单独运行，发现获取公告的部分占用内存一直在增长，确认内存泄漏时在公告部分。
按照相同的思路，最后发现内存增长的最快的事在bittrex公告这块。
但是bittrex这块并没有发现内存谢罗的可疑操作，目前怀疑是因为bittrex一次会获取两百多条数据，而这两百多条数据都会一次执行一系列mongodb操作，我认为内存泄漏存在mongodb操作当中，它们分别是

find_one
count: 如果find_one未找到相同数据才会执行count
update
insert

经过测试，发现是pymongo 3.7.1这个版本你的find_one接口会导致内存泄漏，应该我之前使用的pymongo3.5.1，所以没有这个问题。在vps卸载重装后，这个问题应该基本解决。