Speicherprobleme im MQL5
Hallo,
ich habe eine Frage, die ich so noch nirgends beantwortet gefunden habe.
Gibt es Alternativen für IndicatorRelease() im Strategietester? Gemäss Doku funktioniert die Methode im Strategietester nicht.
Mein Problem: ich habe einen EA, welcher mit mehreren Indikatoren arbeitet. Beim Strategietest können in Summe auch >20 Indikatoren geladen sein - bei 24 aktiven Agenten. Mein Rechner verträgt das gut.
Nun sind manche Indikatoren "leichter" z.B. iMACD füllt den Speicher auf 700MB pro Agenten und dann steigt der Speicherbedarf nicht mehr an. Andere z.B. iRSI steigern den Speicherbedarf ohne ein absehbares Ende. Der Speicherbedarf steigt also von Test zu Test stetig an, bis zum Absturz des PCs.
Ein Workaround, den ich gefunden habe ist die Deaktivierung aller lokalen Agenten. Wenn ich das kurz mache, wird der Speicherbereich aller Agenten zurückgesetzt und der Test geht weiter.
Kennt Jemand eine Möglichkeit der "Agentendeaktivierung und Aktivierung" per MQL5 Code? Kann man eine Arbeitsspeicherbefreiung erzwingen, ohne den Strategietester zu unterbrechen?
Kann man alte Indikatoren "schneller" aus dem Arbeitsspeicher schmeissen?
Ich freue mich auf Eure Ideen. Liebe Grüsse
Simon
also wenn du Probleme mit den Speicher hast, bei ein paar Standardindikatoren, dann bring deinen Code in Ordnung
Ich denke auch, es liegt an Deinem Code!
Vielleicht könnte das Problem durch die Verwendung von OnDeinit() gelöst werde?
Ich nutze natürlich OnDeinit(), jede verwendete Klasse hat auch einen implementierten Destructor, welcher alles löscht. Das Problem ist die Zerstörung der Indikatoren, das geht gemäss Doku nicht. Gibt es einen memory analyzer in MQL5? Wenn ich die Verwendung der Indikatoren deaktiviere und den EA laufen lasse, gibt es keine Speicherprobleme. Der Code von iRSI und iMACD sieht in der Doku identisch aus aus der Sicht der Grössenbeschränkungen.
Hier ein Beispieldestructor der Indikatorklasse.
IndicatorClass::~IndicatorClass()
{
int result = 0;
if(IndicatorRelease(handleSchaff))
{
result += 1;
}
}
Ich nutze natürlich OnDeinit(), jede verwendete Klasse hat auch einen implementierten Destructor, welcher alles löscht. Das Problem ist die Zerstörung der Indikatoren, das geht gemäss Doku nicht. Gibt es einen memory analyzer in MQL5? Wenn ich die Verwendung der Indikatoren deaktiviere und den EA laufen lasse, gibt es keine Speicherprobleme. Der Code von iRSI und iMACD sieht in der Doku identisch aus aus der Sicht der Grössenbeschränkungen.
Hier ein Beispieldestructor der Indikatorklasse.
IndicatorClass::~IndicatorClass()
{
int result = 0;
if(IndicatorRelease(handleSchaff))
{
result += 1;
}
}
zeig lieber mal deinen code, das würde mehr sinn machen, die Klasse ist ja bekannt, die funktioniert
Ich habe eine Kleinigkeit herausgefunden, beim test mit 1 Minute OHLC, ist der Speicherverbrauch ohne Indikatoren bei 70 MB, bei Test mit real ticks bei 750MB für ein halbes Jahr.
Somit ergibt sich für mich das folgende Learning. Der Algo ist funktionsfähig und leicht betreibbar beim Testen mit ungenauen Daten. Bei genauen Daten braucht es mehr RAM. Ich habe die Anzahl der aktiven Agenten von 24 auf 12 reduziert und werde berichten für wie lange mein Arbeitsspeicher reicht.
Hallo,
Mein Problem: ich habe einen EA, welcher mit mehreren Indikatoren arbeitet. Beim Strategietest können in Summe auch >20 Indikatoren geladen sein - bei 24 aktiven Agenten. Mein Rechner verträgt das gut.
Wo ist das denn ein Problem ? 12 Kerner und nur 4 GB Ram , eher nicht, oder?
Ein Agent möchte bis zu 2 GB haben laut MQ Specs
Ps: mit 12 Agenten wird er kaum langsamer (Selbst getestet)
Das hört sich gut an, hast Du mit realen Ticks getestet? Ich habe für ein 1-Minütiges Intervall einen Real Tick Test für 6 Monate in Parallel 24 Mal mit je 4 Indikatoren bei 64 GB RAM getestet. Das ergab einen RAM-Overflow. Bei grossen Tests, werden die Strategietester ein Bisschen grösser als 2GB.
Sicher doch, aber teste ruhig selber weiter. Da ist der Lerneffekt am größten.
Ohne deinen Code gehts hier im Schneckentempo voran.
Danke für den Tipp mit OnDeinit(). Das Problem war, dass ein Abbruch im Ereignis OnInit() durch ExpertRemove() kein OnDeinit() Ergeignis im EA mehr zur Folge hat. Dadurch wurden die Destruktoren der beteiligten Objekte nicht aufgerufen. Ist das ein Bug im MQL5 oder so designed?
Die Lösung sieht also im OnInit() mit dem markierten Quellcode wie folgt aus:
if(!IsStopped())
{
// init(inputVariables, parameters);
mStop.checkDoubleIndicators(inputVariables);
mAlgorithm = new AlgorithmClass(mParameters,1,99999,_Symbol,true);
}
else
{
OnDeinit(0);
}
nicht aufgerufen. Ist das ein Bug im MQL5 oder so designed?
ExpertRemove() Ja ist so gewollt da ExpertRemove() ein direkter Programmabbruch ist.
- www.mql5.com
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Hallo,
ich habe eine Frage, die ich so noch nirgends beantwortet gefunden habe.
Gibt es Alternativen für IndicatorRelease() im Strategietester? Gemäss Doku funktioniert die Methode im Strategietester nicht.
Mein Problem: ich habe einen EA, welcher mit mehreren Indikatoren arbeitet. Beim Strategietest können in Summe auch >20 Indikatoren geladen sein - bei 24 aktiven Agenten. Mein Rechner verträgt das gut.
Nun sind manche Indikatoren "leichter" z.B. iMACD füllt den Speicher auf 700MB pro Agenten und dann steigt der Speicherbedarf nicht mehr an. Andere z.B. iRSI steigern den Speicherbedarf ohne ein absehbares Ende. Der Speicherbedarf steigt also von Test zu Test stetig an, bis zum Absturz des PCs.
Ein Workaround, den ich gefunden habe ist die Deaktivierung aller lokalen Agenten. Wenn ich das kurz mache, wird der Speicherbereich aller Agenten zurückgesetzt und der Test geht weiter.
Kennt Jemand eine Möglichkeit der "Agentendeaktivierung und Aktivierung" per MQL5 Code? Kann man eine Arbeitsspeicherbefreiung erzwingen, ohne den Strategietester zu unterbrechen?
Kann man alte Indikatoren "schneller" aus dem Arbeitsspeicher schmeissen?
Ich freue mich auf Eure Ideen. Liebe Grüsse
Simon