Cloud-Synchronisationsfehler - Seite 2

[Slava]

Was ist der Unterschied zwischen 10 Minuten und 20 Minuten? Kein Unterschied. 10 Minuten sind extrem lang für einen einzigen Aufruf. Sie wollen einen falsch geschriebenen EA testen? Kein Problem. Aber weiten Sie Ihre Probleme nicht auf öffentliche Cloud-Server aus. Andere Nutzer wollen den Cloud Server auch nutzen. Sie können lokale Agenten und Remote-Agenten ohne Einschränkungen verwenden - Sie sind willkommen.

[Alain Verleyen]

cowil:

Hallo Stringo,

zunächst einmal danke für die Info.

Mich interessiert jedoch die Begründung von MetaQuotes für dieses Vorgehen. Wenn eine große Menge an "Every Tick"-Daten verwendet wird (z. B. 2003.1.1 -> 2013.1.1) und der zu optimierende Experte ziemlich kompliziert ist, dauert es oft länger als 10 Minuten, bis eine einzelne Optimierungsiteration erfolgt. Gibt es einen bestimmten Grund dafür, dass MetaQuotes einen Zeitraum von 10 Minuten als Timeout gewählt hat? Gibt es eine Möglichkeit für den Cloud-Benutzer, diese Zeitüberschreitung zu erhöhen, oder ist sie von MetaQuotes fest verdrahtet" worden?

stringo:
Endlosschleife nur bei Cloud-Agenten erkannt. Wenn einer der Aufrufe(OnInit, OnDeinit, OnTick, OnTimer usw.) länger als 10 Minuten läuft

Es handelt sich nicht um eine einzelne Optimierung, sondern um einen Signalaufruf an eine Funktion.

[cowil]

angevoyageur:
Es handelt sich nicht um eine einzelne Optimierung, sondern um einen Signalaufruf an eine Funktion.

Ah - mein Fehler - ich hatte irgendwie im Kopf, dass wir über eine einzelne Optimierungsiteration sprechen und nicht über einen einzelnen Aufruf eines Event-Handlers (obwohl Stringo ausdrücklich einen einzelnen Event-Handler-Aufruf erwähnt hatte). Ein einzelner Aufruf eines Event-Handlers, der länger als 10 Minuten dauert, wäre in der Tat lächerlich.Ich entschuldige mich in aller Bescheidenheit - ich hatte wohl einen Hirnschwund - Zeit, das Gehirn auszuruhen :)

Mmmmm - es muss also irgendetwas Seltsames in meinem Expert passieren, das dazu führt, dass OnTick() gelegentlich länger als 10 Minuten braucht, um einen Aufruf abzuschließen. Zeit, mit der Suche zu beginnen...

Wie auch immer, nochmals vielen Dank für eure Hilfe, Jungs!

[Slava]

angevoyageur:
Es handelt sich nicht um eine einzelne Optimierung, sondern um einen Signalaufruf an eine Funktion.

Ganz genau. Ein einzelner Aufruf kann nicht länger als 10 Minuten dauern, wenn einer der Cloud-Agenten

[cowil]

Hallo,

Ich suche noch immer, aber ich kann nichts finden. Die Tatsache, dass mein Experte optimiert einwandfrei auf meine lokalen Agenten (d.h. keiner der Fortschritt Prozentsätze meiner Agenten pausieren oder stoppen zu jeder Zeit, die ich gedacht hätte, wäre der Fall, wenn es irgendeine Art von Endlosschleife in meinem OnTick() Funktion, die mindestens 10 Minuten oder mehr dauerte) wirklich macht es schwierig.

Eine Sache, auf die ich neugierig bin - was bedeutet die PR-Nummer am Ende der Fehlermeldung (z. B. ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)". Kann jemand etwas Licht in diese Angelegenheit bringen?

Vielen Dank im Voraus für Ihre Hilfe in dieser Sache.

[Alain Verleyen]

cowil:

Hallo,

Ich suche noch immer, aber ich kann nichts finden. Die Tatsache, dass mein Experte optimiert einwandfrei auf meine lokalen Agenten (d.h. keiner der Fortschritt Prozentsätze meiner Agenten pausieren oder stoppen zu jeder Zeit, die ich gedacht hätte, wäre der Fall, wenn es irgendeine Art von Endlosschleife in meinem OnTick() Funktion, die mindestens 10 Minuten oder mehr dauerte) wirklich macht es schwierig.

Eine Sache, auf die ich neugierig bin - was bedeutet die PR-Nummer am Ende der Fehlermeldung (z. B. ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)". Kann jemand etwas Licht in diese Angelegenheit bringen?

Vielen Dank im Voraus für Ihre Hilfe in dieser Angelegenheit.

PR ist eine Leistungsbewertung eines Agenten, die nach einer speziellen vereinheitlichten Methode berechnet wird. Je höher die PR eines Agenten ist, desto schneller erledigt er seine Aufgabe und desto höher ist demzufolge sein Mietpreis pro Zeiteinheit.

Weitere Informationen finden Sie hier.

[cowil]

angevoyageur:
Hier finden Sie weitere Informationen.

Ah - das erklärt natürlich einiges. Vielen Dank für Ihre Hilfe!

[cowil]

Hallo,

nachdem ich am Wochenende viele Stunden damit verbracht habe, meinen Code zu untersuchen, konnte ich keine Stelle im Code meines Experten finden, an der die Möglichkeit einer Endlosschleife auftreten könnte. Und dabei bin ich auch immer mehr zu der Überzeugung gelangt, dass, wenn mein Experte Probleme mit Endlosschleifen gehabt hätte, dies bei der Verwendung meiner lokalen Agenten zur Optimierung meines Experten hätte auffallen müssen. Wie ich bereits erwähnt habe, machen meine lokalen Agenten während der Optimierung meines Experten zu keinem Zeitpunkt eine Pause - und schon gar nicht über einen Zeitraum von zehn Minuten oder mehr.

Nachdem ich mich davon überzeugt hatte, dass die Probleme nicht von meinem Experten herrührten, begann ich, die anderen Alternativen zu untersuchen. Die einzige logische Alternative, die ich sehen konnte, war, dass es entweder Probleme mit den Agenten selbst (d. h. Bugs) oder Probleme mit den Boxen, auf denen sie laufen, gab. Es sieht so aus, als ob die zweite der beiden Alternativen der Übeltäter ist.

Soweit ich das beurteilen kann, lassen die Leute Cloud-Agenten auf allen möglichen Rechnern laufen. Ich gehe auch davon aus, dass diese Cloud-Agenten alle Windows-basiert sind. Der Grund, warum ich dies erwähne, ist, dass meine persönliche Erfahrung mit Consumer-Versionen von Windows ist, dass sie notorisch instabil sind, wenn sie über längere Zeit betrieben werden, und dazu neigen, sich zu verlangsamen oder sogar festzufahren, wenn sie mit ernsthaften Verarbeitungsanforderungen belastet werden.

Die Optimierungen, die ich vorzunehmen versuchte, betrafen einen recht komplexen Experten, der auf 6-7 Jahren"Every Tick"-Daten ausgeführt wurde - d. h., es waren angemessene Verarbeitungs- und Speicheranforderungen erforderlich. Ich hatte den Verdacht, dass die Agenten in der Cloud, die diese Aufgabe übernehmen, unzureichend spezifiziert sind - vor allem, wenn man bedenkt, dass es sich um Windows-Rechner handelt.

Also fügte ich die folgende Codezeile in meinen OnInit()-Ereignishandler ein:

    // Check optimisation agent stats...
    if (MQL5InfoInteger(MQL5_OPTIMIZATION) && TerminalInfoInteger(TERMINAL_MEMORY_PHYSICAL) < 32000)
        return(INIT_AGENT_NOT_SUITABLE);

Der Grund, warum ich TERMINAL_MEMORY_PHYSICAL verwendet habe, ist, dass die anderen SpeicheroptionenTERMINAL_MEMORY_TOTAL und TERMINAL_MEMORY_AVAILABLE nicht viel taugen, da sie nur den gesamten virtuellen Adressraum des Host-Prozessors im Benutzermodus liefern (d.h. 4 GB für einen 32-Bit-Prozessor oder 8 TB für einen 64-Bit-Prozessor). Ich kann mir nicht vorstellen, dass es 64-Bit-Maschinen mit 8 TB Speicher gibt - zumindest noch nicht :) TERMINAL_CPU_CORES war eine weitere Option, die ich in Erwägung gezogen hatte, aber ich entschied mich schließlich dafür, nur den Arbeitsspeicher zu testen, da ich davon ausging, dass jeder Rechner mit einer angemessenen Menge an Arbeitsspeicher auch in allen anderen wichtigen Bereichenanständig spezifiziert sein würde.

Und siehe da - keine Probleme mehr! Alle meine Optimierungen laufen jetzt einwandfrei :)

[Clock]

cowil:

Hallo,

nachdem ich am Wochenende viele Stunden damit verbracht habe, meinen Code zu untersuchen, konnte ich keine Stelle im Code meines Experten finden, an der die Möglichkeit einer Endlosschleife auftreten könnte. Und dabei bin ich auch immer mehr zu der Überzeugung gelangt, dass, wenn mein Experte Probleme mit Endlosschleifen gehabt hätte, dies bei der Verwendung meiner lokalen Agenten zur Optimierung meines Experten hätte auffallen müssen. Wie ich bereits erwähnt habe, machen meine lokalen Agenten während der Optimierung meines Experten zu keinem Zeitpunkt eine Pause - und schon gar nicht über einen Zeitraum von zehn Minuten oder mehr.

Nachdem ich mich davon überzeugt hatte, dass die Probleme nicht von meinem Experten herrührten, begann ich, die anderen Alternativen zu untersuchen. Die einzige logische Alternative, die ich sehen konnte, war, dass es entweder Probleme mit den Agenten selbst (d. h. Bugs) oder Probleme mit den Boxen, auf denen sie liefen, gab. Es scheint, dass die zweite der beiden Alternativen der Übeltäter zu sein scheint.

Soweit ich das beurteilen kann, lassen die Leute Cloud-Agenten auf allen möglichen Rechnern laufen. Ich gehe auch davon aus, dass diese Cloud-Agenten alle Windows-basiert sind. Der Grund, warum ich dies erwähne, ist, dass meine persönliche Erfahrung mit Consumer-Versionen von Windows ist, dass sie notorisch instabil sind, wenn sie über längere Zeit betrieben werden, und dazu neigen, sich zu verlangsamen oder sogar festzufahren, wenn sie mit ernsthaften Verarbeitungsanforderungen belastet werden.

Die Optimierungen, die ich vorzunehmen versuchte, betrafen einen recht komplexen Experten, der auf 6-7 Jahren "Every Tick"-Daten ausgeführt wurde - d. h., es waren angemessene Verarbeitungs- und Speicheranforderungen erforderlich. Ich hatte den Verdacht, dass die Agenten in der Cloud, die diese Aufgabe übernehmen, unzureichend spezifiziert sind - vor allem, wenn man bedenkt, dass es sich um Windows-Rechner handelt.

Also fügte ich die folgende Codezeile in meinen OnInit()-Ereignishandler ein:

Der Grund, warum ich TERMINAL_MEMORY_PHYSICAL verwendet habe, ist, dass die anderen SpeicheroptionenTERMINAL_MEMORY_TOTAL und TERMINAL_MEMORY_AVAILABLE nicht viel taugen, da sie nur den gesamten virtuellen Adressraum des Host-Prozessors im Benutzermodus liefern (d.h. 4 GB für einen 32-Bit-Prozessor oder 8 TB für einen 64-Bit-Prozessor). Ich kann mir nicht vorstellen, dass es 64-Bit-Maschinen mit 8 TB Speicher gibt - zumindest noch nicht :) TERMINAL_CPU_CORES war eine weitere Option, die ich in Erwägung gezogen hatte, aber ich entschied mich schließlich dafür, nur den Arbeitsspeicher zu testen, da ich davon ausging, dass jeder Rechner mit einer angemessenen Menge an Arbeitsspeicher auch in allen anderen wichtigen Bereichenanständig spezifiziert sein würde.

Und siehe da - keine Probleme mehr! Alle meine Optimierungen laufen jetzt einwandfrei :)

Das klingt nach einer großartigen Idee und ich bin dankbar für diesen Hinweis.

Allerdings gibt es dazu 3 Dinge:

1) Wie ich oben erwähnt habe, habe ich auch das Problem der "Endlosschleife", aber da ich in diesem Thread verstanden habe, dass "Endlosschleife" nur die beste Vermutung für "ein Ereignis dauerte länger als zehn Minuten" ist, akzeptiere ich, dass es an meinem Code liegen könnte. Ich verwende recht komplexe Indikatoren, und da sie (zumindest glaube ich das) ihre gesamte Historie berechnen, wenn ihr Handle erstellt wird, könnte dies (auf langsamen Computern) mehr als zehn Minuten dauern.

2) Wie auch immer! Normalerweise stürzte meine Cloud nach 10-15 Minuten ab. Aber letzte Nacht hat sie 8 Stunden lang perfekt funktioniert. Kein einziger Absturz, obwohl ich den Code überhaupt nicht geändert habe. Seltsam!

3) Und das Wichtigste, weil es mit Ihrem Ansatz zusammenhängt: Wenn man einen Agenten aufgrund seines Speichers ablehnt, stürzt der Agent (und damit die ganze Cloud) nicht ab, das verstehe ich. Aber ich glaube nicht, dass eine leistungsfähigere Maschine den gleichen Parametersatz noch einmal ausprobieren wird, so dass man im Grunde genommen Optimierungsdatenpunkte verliert, oder? Würden Sie sagen, dass dies der Preis ist, den wir zahlen müssen?

Ich bin gespannt, ob meine Agenten noch funktionieren, wenn ich von der Arbeit zurück bin...

[Alain Verleyen]

cowil:
...

Wie viele Agenten stehen zur Verfügung, wenn Sie alle Agenten mit weniger als 32 GB Speicherplatz ablehnen ?