请问参数优化过程占用的内存大小是由电脑核心数决定的吗？

电脑16核心32G内存，开启参数优化后占用的内存很快几分钟内就爆掉。

本来以为是线程太多了，但是后来我把run_ga_optimization函数中的max_workers改成了1，但是内存还是慢慢攀升，直到十几分钟后爆掉。。。

求助

参数优化的线程数是由电脑核心数决定的。

参数优化是通过多次的回测，然后筛选出回测结果做好的参数。所以，在参数优化中会进行多次回测，每次回测都会创建一个BacktestingEngine实例。理论上在每次回测结束后，这个实例都会被python的垃圾回收机制给回收掉，然后就会把内存空出来。但是这个垃圾回收机制可能会有延迟，然后就会一直占着内存，然后就会爆内存。你可能就是缓存没有被及时清除。

你可以试着手动清空缓存。在vnpy_ctastrategy下的backtesting.py文件的最后有evaluate函数，你可以在这个函数return之前调用BacktestingEngine实例的clear_data方法清空掉BacktestingEngine实例中的缓存数据。clear_data里缺少了对self.history_data的清理，你可以照着其他的写一下。

郭易燔 wrote:

参数优化的线程数是由电脑核心数决定的。

参数优化是通过多次的回测，然后筛选出回测结果做好的参数。所以，在参数优化中会进行多次回测，每次回测都会创建一个BacktestingEngine实例。理论上在每次回测结束后，这个实例都会被python的垃圾回收机制给回收掉，然后就会把内存空出来。但是这个垃圾回收机制可能会有延迟，然后就会一直占着内存，然后就会爆内存。你可能就是缓存没有被及时清除。

你可以试着手动清空缓存。在vnpy_ctastrategy下的backtesting.py文件的最后有evaluate函数，你可以在这个函数return之前调用BacktestingEngine实例的clear_data方法清空掉BacktestingEngine实例中的缓存数据。clear_data里缺少了对self.history_data的清理，你可以照着其他的写一下。

感谢感谢，厉害了，我马上去试一下。

并且，刚才的爆内存是在Ubuntu上出现的，我采用大约同样的配置和参数在Windows上跑，虽然内存也标红，但是还是能跑下来不会被kill，可能是两个平台下的垃圾回收机制不同吧

郭易燔 wrote:

参数优化的线程数是由电脑核心数决定的。

参数优化是通过多次的回测，然后筛选出回测结果做好的参数。所以，在参数优化中会进行多次回测，每次回测都会创建一个BacktestingEngine实例。理论上在每次回测结束后，这个实例都会被python的垃圾回收机制给回收掉，然后就会把内存空出来。但是这个垃圾回收机制可能会有延迟，然后就会一直占着内存，然后就会爆内存。你可能就是缓存没有被及时清除。

你可以试着手动清空缓存。在vnpy_ctastrategy下的backtesting.py文件的最后有evaluate函数，你可以在这个函数return之前调用BacktestingEngine实例的clear_data方法清空掉BacktestingEngine实例中的缓存数据。clear_data里缺少了对self.history_data的清理，你可以照着其他的写一下。

这个不能清理self.history_data，每个进程的数据只加载一次，后续历史数据不用加载，提升效率用的，每次优化前把它清空，会导致新的优化开始重新加载数据，而数据加载一般比回测运算时间要长一些，得不偿失的。等新版本用python3.10后就可以采用共享内存方式回测，内存肯定不会爆，但是我实验3.8版本的共享内存，发现单次回测运算的效率降低了，也不知道为什么。

在优化时每次都会创建一个新的实例，不会重复使用之前实例中的数据的，数据不是在这里做缓存优化的。
速度降低可能是跨进程通讯开销比较大，要是方便的话，可以分享一下，大家帮忙测测看，看看是不是有优化的余地。