Memory bug when WFA optimizing

[Oracletrades]

Hi there, I recently noticed that there may be an issue with memory allocation when running back testing. I noticed that the memory utilisation of my windows VPS increases steadily until the whole application crashes and no memory is left .

I’ve tried this on different machines and always observe the same outcome.

One of the main reasons I purchased a license was to be able to do complex backtesting. How can I troubleshoot this?

Thanks!

[NT-Roland]

Hi Oracletrades,
I'm more than happy to be corrected here, but I'm afraid Optimization can use UNLIMITED memory and crash. It might (still) be possible to limit the number of iterations running in parallel using the (undocumented) WaitForIterationsCompleted() command. However, individual users should not have to deal with "debugging" NT from my point of view. RAM Control is a must have, particularly for such software.
NT-Roland

[NinjaTrader_ChelseaB]

Hello Oracletrades,

With many backtest iterations of an optimization this may require very large amounts of memory.

If this is a script you have written, I recommend modifying the script to take advantage of IsInstantiatedOnEachOptimizationIteration being set to false. This will reduce the amount of backtest instances being generated in memory for each iteration.
https://ninjatrader.com/support/help...niteration.htm

Objects should only be initialized in State.DataLoaded when absolutely necessary, existing objects that can be reset like arrays should be cleared / reset instead of new objects initialized. All variables will need to be reset to an initial value.

Below is a link to an example that demonstrates the effect of IsInstantiatedOnEachOptimizationIteration.

https://forum.ninjatrader.com/forum/ninjatrader-8/strategy-development/1269771-strategy-analyzer-optimization-result-table-shows-incorrect-data?p=1270384#post1270384

Further, the IncludeTradeHistory can make a huge performance impact. If the script is not using the SystemPerformance collection, setting IncludeTradeHistory to false in State.Configure can dramatically improve backtest and optimization performance.
https://ninjatrader.com/support/help...inbacktest.htm

If the script is making a lot of Draw method calls, this can also have a large impact. Disabling draw method calls when the script is in the Strategy Analyzer can reduce this impact.
https://ninjatrader.com/support/help...gyanalyzer.htm

If this is not a script you have made, I would recommend contacting the vendor or author and requesting these changes.

[Oracletrades]

Thank you Chelsea, Roland. I wasn't aware of that script and assumed that NT would do that automatically. I have 24 GB of RAM on the machine and was running 100.000 iterations which is quite common when you have 4-5 variables... Will try what you suggest above and revert.

[Oracletrades]

Hi everyone, just a follow-up to this post. Quite frankly, the proposed solution is too complicated for me to implement and understand. Therefore, I did the following (in case anybody ever has the same issue):

- increased the Windows Paging file to 16GB
- as I am on a SSD, the read/write speeds are sufficient for the backtesting (it slows down a bit, but time is not my issue)

Cheers!

[Oracletrades]

SOLUTION: to anybody coming across this post, please just remove any "drawing" objects like arrows from the strategy. The memory leakage will stop and your strategy will run, even with 1.000.000 iterations (just doing this on a 16GB RAM machine).

Took me a few weeks. Support, please take note of this solution, it was mentioned in a few other posts.

FEATURE REQUEST: for future releases, can you consider "disabling" the drawing of objects in the strategy analyzer when doing optimizations, entirely? There is no value anyway during the optimization process and it solves the memory hog problem without the need of coding anything.

[NinjaTrader_ChrisL]

Hello Oracletrades, thanks for your reply .

You can use IsInStrategyAnalyzer to ignore drawing draw objects while backtesting/optimizing:

https://ninjatrader.com/support/helpGuides/nt8/en-us/?isinstrategyanalyzer.htm

[mcrobertg7]

SOLUTION: to anybody coming across this post, please just remove any "drawing" objects like arrows from the strategy. The memory leakage will stop and your strategy will run, even with 1.000.000 iterations (just doing this on a 16GB RAM machine).
Took me a few weeks. Support, please take note of this solution, it was mentioned in a few other posts.
FEATURE REQUEST: for future releases, can you consider "disabling" the drawing of objects in the strategy analyzer when doing optimizations, entirely? There is no value anyway during the optimization process and it solves the memory hog problem without the need of coding anything. https://givology.org/~GabrielBlocker/blog/326896/

Hi! Thanks for the suggestion: I've managed to stop memory leakage by removing "drawing" objects. But is it some kind of bug? I didn't find it on a list.

[NinjaTrader_ChelseaB]

Hello mcrobertg7,

Drawing object method calls all create new instances of the drawing object which all need need memory locations whether or not they will be drawn.
This is not a leak. This is the number of objects being created by the strategy that is calling the methods for these.
To avoid the drawing objects from being created, do not call the draw method during historical data or specifically when in the strategy analyzer.

Any objects created by a strategy will need memory locations.

This also involves using IsInstantiatedOnEachOptimizationIteration set to false where the variables should be initialized only when null in State.DataLoaded and reset when possible to save memory.

Below is a link to the help guide.

https://ninjatrader.com/support/helpGuides/nt8/isinstantiatedoneachoptimizationiteration.htm

Below is a link to a thread where this is mentioned.
https://ninjatrader.com/support/foru...39#post1069339

[DTBTraders]

Hi Oracletrades,
I'm more than happy to be corrected here, but I'm afraid Optimization can use UNLIMITED memory and crash. It might (still) be possible to limit the number of iterations running in parallel using the (undocumented) WaitForIterationsCompleted() command. However, individual users should not have to deal with "debugging" NT from my point of view. RAM Control is a must have, particularly for such software.
NT-Roland

Hi Oracletrades - any chance you could share with me more info on the WaitForIterationsCompleted() command? - would be much appreciated!