Erreurs de synchronisation du nuage - page 2

Nouveau commentaire
 
Quelle est la différence entre 10 minutes et 20 minutes ? Aucune différence. 10 minutes c'est extrêmement long pour un seul appel. Vous voulez tester un EA mal écrit ? Pas de problème. Mais n'étendez pas vos problèmes sur un serveur Cloud public. D'autres utilisateurs veulent aussi utiliser le serveur cloud. Vous pouvez utiliser des agents locaux et des agents distants sans aucune restriction - Vous êtes les bienvenus.
 
cowil:

Bonjour Stringo,

Tout d'abord, merci pour l'information.

Cependant, je suis intéressé par le raisonnement de MetaQuotes à ce sujet. Si une grande quantité de données "Every Tick" est utilisée (disons par exemple, 2003.1.1 -> 2013.1.1) et que l'expert à optimiser est raisonnablement compliqué, il faudra souvent plus de 10 minutes pour qu' une seule itération d'optimisation se produise. Y a-t-il une raison spécifique pour laquelle MetaQuotes a choisi une période de 10 minutes comme délai d'attente ? En outre, l'utilisateur du nuage a-t-il la possibilité d'augmenter ce délai ou MetaQuotes l'a-t-il fixé de manière contraignante ?

stringo:
Boucle sans fin détectée sur les agents Cloud uniquement. Si un des appels(OnInit, OnDeinit, OnTick, OnTimer etc) fonctionne plus de 10 minutes
Ce n'est pas une optimisation unique, c'est un appel de signal à une fonction.
 
angevoyageur:
Il ne s'agit pas d'une optimisation unique, mais d'un appel de signal à une fonction.

Ah, je me suis trompé, j'ai cru comprendre qu'il s'agissait d'une seule itération d'optimisation et non d'un seul appel à un gestionnaire d'événements (même si Stringo a spécifiquement mentionné un seul appel à un gestionnaire d'événements). Un appel unique à un gestionnaire d'événement qui dure plus de 10 minutes serait en effet ridicule.Mes humbles excuses - j'ai dû avoir un trou de mémoire - il est temps de reposer le cerveau. :)

Mmmmm - il doit donc se passer quelque chose de bizarre dans mon Expert qui fait que OnTick() prend parfois plus de 10 minutes pour terminer un appel. Il est temps de commencer à creuser...

Quoi qu'il en soit, merci encore pour votre aide !

 
angevoyageur:
Ce n'est pas une optimisation unique, c'est un appel de signal à une fonction.
Exactement. L'appel unique ne peut pas durer plus de 10 minutes pour l'un des agents du cloud.
 

Bonjour,

Je continue à creuser mais je n'arrive pas à trouver quoi que ce soit. Le fait que mon expert s'optimise parfaitement sur mes agents locaux (c'est-à-dire qu'aucun des pourcentages de progression de mes agents ne s'arrête à aucun moment, ce que j'aurais pensé être le cas s'il y avait une sorte de boucle sans fin dans ma fonction OnTick() qui durait au moins 10 minutes ou plus) rend vraiment les choses difficiles.

Je suis curieux de savoir ce qu'indique le numéro PR à la fin du message d'erreur (par exemple, ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)". Quelqu'un peut-il nous éclairer à ce sujet ?

Merci d'avance pour votre aide.

Distributed Computing in the MQL5 Cloud Network
Distributed Computing in the MQL5 Cloud Network
  • cloud.mql5.com
Connect to the MQL5 Cloud Network (Cloud Computing) and earn extra income around the clock — there is much work for you computer!
 
cowil:

Bonjour,

Je continue à creuser mais je n'arrive pas à trouver quoi que ce soit. Le fait que mon expert s'optimise parfaitement sur mes agents locaux (c'est-à-dire qu'aucun des pourcentages de progression de mes agents ne s'arrête à aucun moment, ce que j'aurais pensé être le cas s'il y avait une sorte de boucle sans fin dans ma fonction OnTick() qui durait au moins 10 minutes ou plus) rend vraiment les choses difficiles.

Je suis curieux de savoir ce qu'indique le numéro PR à la fin du message d'erreur (par exemple, ".... expert rejected by MQL5 Cloud Network in 600 sec(PR116)". Quelqu'un peut-il nous éclairer à ce sujet ?

Merci d'avance pour votre aide à ce sujet.

Le PR est une note de performance d'un agent calculée selon une méthode spéciale unifiée. Plus le PR d'un agent est élevé, plus il accomplit sa tâche rapidement et plus son prix de location par unité de temps est élevé en conséquence.
Voir ici pour plus d'informations.
Questions Concerning Payment for Participation in the MQL5 Cloud Network
Questions Concerning Payment for Participation in the MQL5 Cloud Network
  • cloud.mql5.com
Questions concerning payment for participation in the MQL5 Cloud Network - distributed computing network
 
angevoyageur:
Voir ici pour plus d'informations.
Ah - cela explique certainement les choses. Merci pour votre aide !
 

Bonjour,

Eh bien, après avoir passé de nombreuses heures ce week-end à examiner mon code, je n'ai pu trouver aucun endroit dans le code de mon Expert où la possibilité d'une boucle sans fin pourrait apparaître. Au cours de ce processus, je suis également devenu de plus en plus convaincu que si mon Expert avait eu des problèmes de boucle sans fin, j'aurais dû le voir apparaître en utilisant mes agents locaux pour optimiser mon Expert. Comme je l'ai mentionné plus haut, mes agents locaux ne s'arrêtent à aucun moment pendant l'optimisation de mon Expert, et encore moins pendant une période de dix minutes ou plus.

Après avoir été convaincu que les problèmes ne provenaient pas de mon Expert, j'ai commencé à examiner les autres possibilités. Les seules alternatives logiques que je voyais étaient des problèmes avec les agents eux-mêmes (c'est-à-dire des bogues) ou des problèmes avec les boîtes sur lesquelles ils fonctionnaient. Il semble que ce soit la deuxième solution qui soit en cause.

D'après ce que j'ai pu constater, les gens exécutent des agents cloud sur toutes sortes de machines. Je présume également que ces agents en nuage sont tous basés sur Windows. La raison pour laquelle je mentionne ceci est que mon expérience personnelle des versions grand public de Windows est qu'elles sont notoirement instables lorsqu'elles sont malmenées pendant un certain temps, et qu'elles ont tendance à ralentir ou même à se bloquer lorsqu'elles sont soumises à des demandes de traitement importantes.

Les optimisations que j'ai tenté d'effectuer concernent un expert relativement complexe qui est exécuté sur 6-7 ans de données"Every Tick" - c'est-à-dire qu'il exige un traitement et une mémoire raisonnables. Je soupçonnais que les agents dans le nuage qui se chargeaient de cette tâche n'étaient pas suffisamment spécifiés, surtout s'il s'agissait de boîtes Windows.

J'ai donc ajouté la ligne de code suivante dans mon gestionnaire d'événement OnInit() :

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

La raison pour laquelle j'ai utilisé TERMINAL_MEMORY_PHYSICAL est que les autres options de mémoire :TERMINAL_MEMORY_TOTAL et TERMINAL_MEMORY_AVAILABLE ne sont pas très utiles car elles ne vous fournissent que l'espace d'adressage virtuel total, en mode utilisateur, du processeur de l'hôte (c'est-à-dire 4 Go pour un processeur 32 bits ou 8 To pour un processeur 64 bits). Je ne peux pas imaginer de machines 64 bits avec 8 To de mémoire - du moins, pas encore. :) TERMINAL_CPU_CORES est une autre option que j'ai envisagée, mais j'ai finalement décidé d'opter pour le test de la mémoire, car je suppose qu'une machine dotée d'une quantité décente de mémoire doit avoir des spécifications correctes dans tous les autres domaines importants.

Et devinez quoi - plus de problèmes ! Toutes mes optimisations fonctionnent bien maintenant :)


 
cowil:

Bonjour,

Eh bien, après avoir passé de nombreuses heures ce week-end à examiner mon code, je n'ai pu trouver aucun endroit dans le code de mon Expert où la possibilité d'une boucle sans fin pourrait apparaître. Au cours de ce processus, je suis également devenu de plus en plus convaincu que si mon Expert avait eu des problèmes de boucle sans fin, j'aurais dû le voir apparaître en utilisant mes agents locaux pour optimiser mon Expert. Comme je l'ai mentionné plus haut, mes agents locaux ne s'arrêtent à aucun moment pendant l'optimisation de mon Expert, et encore moins pendant une période de dix minutes ou plus.

Après avoir été convaincu que les problèmes ne provenaient pas de mon Expert, j'ai commencé à examiner les autres possibilités. Les seules alternatives logiques que je voyais étaient des problèmes avec les agents eux-mêmes (c'est-à-dire des bogues) ou des problèmes avec les boîtes sur lesquelles ils fonctionnaient. Il semble que la seconde de ces alternatives soit la coupable.

D'après ce que j'ai pu constater, les gens exécutent des agents cloud sur toutes sortes de machines. Je présume également que ces agents en nuage sont tous basés sur Windows. La raison pour laquelle je mentionne ceci est que mon expérience personnelle des versions grand public de Windows est qu'elles sont notoirement instables lorsqu'elles sont malmenées pendant un certain temps, et qu'elles ont tendance à ralentir ou même à se bloquer lorsqu'elles sont soumises à des demandes de traitement importantes.

Les optimisations que j'ai tenté d'effectuer concernent un expert relativement complexe qui est exécuté sur 6-7 ans de données "Every Tick" - c'est-à-dire qu'il exige un traitement et une mémoire raisonnables. Je soupçonnais que les agents dans le nuage qui se chargeaient de cette tâche n'étaient pas suffisamment spécifiés, surtout s'il s'agissait de boîtes Windows.

J'ai donc inséré la ligne de code suivante dans mon gestionnaire d'événement OnInit() :

La raison pour laquelle j'ai utilisé TERMINAL_MEMORY_PHYSICAL est que les autres options de mémoire :TERMINAL_MEMORY_TOTAL et TERMINAL_MEMORY_AVAILABLE ne sont pas très utiles car elles ne vous fournissent que l'espace d'adressage virtuel total, en mode utilisateur, du processeur de l'hôte (c'est-à-dire 4 Go pour un processeur 32 bits ou 8 To pour un processeur 64 bits). Je ne peux pas imaginer de machines 64 bits avec 8 To de mémoire - du moins, pas encore. :) TERMINAL_CPU_CORES est une autre option que j'ai envisagée, mais j'ai finalement décidé d'opter pour le test de la mémoire, car je suppose qu'une machine dotée d'une quantité décente de mémoire doit être correctement équipée dans tous les autres domaines importants.

Et devinez quoi - plus de problèmes ! Toutes mes optimisations fonctionnent bien maintenant :)


Cela semble être une excellente idée et je suis reconnaissant pour cette astuce.

Cependant, 3 choses à ce sujet :

1) Comme je l'ai mentionné ci-dessus, j'ai également le problème de la boucle "sans fin", mais comme j'ai compris dans ce fil de discussion que la "boucle sans fin" est juste la meilleure estimation pour "un événement a pris plus de dix minutes", j'accepte que cela puisse être mon code. J'utilise des indicateurs assez complexes, et comme (du moins je le pense) ils calculent tout leur historique lorsque leur handle est créé, cela peut (sur des ordinateurs lents) prendre plus de dix minutes.

2) Cependant ! Habituellement, mon nuage se plante au bout de 10-15 minutes. Mais la nuit dernière, il a fonctionné parfaitement pendant 8 heures. Pas une seule panne, bien que je n'aie pas modifié le code du tout. Bizarre !

3) Et le plus important, car lié à votre approche : Lorsque vous rejetez un agent sur la base de sa mémoire, l'agent (et par conséquent le nuage entier) ne se plante pas, je comprends cela. Mais je ne pense pas qu'une machine plus puissante réessayera le même jeu de paramètres, donc vous perdez fondamentalement des points de données d'optimisation, n'est-ce pas ? Diriez-vous que c'est le prix à payer ?


Je serai curieux de voir si mes agents fonctionnent toujours à mon retour du travail...

 
cowil:
...
Combien d'agents sont disponibles quand on rejette tous ceux qui ont moins de 32G de ram ?
12345
Nouveau commentaire