Erreurs de synchronisation du nuage - page 3

Nouveau commentaire
 
Clock:

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

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...

Bonjour Clock,

1) Tout d'abord, à moins que vous n'utilisiez des indicateurs sur, disons, 10 ans de données sur 1 million d'unités et que les indicateurs soient incroyablement complexes, je serais très surpris, à notre époque de puissance de traitement, que cela prenne même 5 minutes sur un système NORMAL. Si j'insiste sur le mot "normal", c'est parce que je soupçonne toujours qu'un certain nombre d'agents dans le nuage fonctionnent sur des machines qui sont soit extrêmement chargées, soit simplement atteintes du syndrome de ralentissement de Windows (stress post-traumatique). Et il suffit d'un seul agent défaillant pour tuer votre optimisation.....

2) J'ai eu exactement le même problème que vous, c'est-à-dire qu'après le lancement d'une optimisation, un certain nombre d'agents du nuage renvoyaient des résultats sans problème. Puis, au bout de 5 à 20 minutes, voire plus longtemps, un agent lançait la redoutable erreur et BANG, l'optimisation était terminée. Il m'est également arrivé que l'optimisation se termine sans problème. Très frustrant car vous n'avez aucun accès aux fichiers journaux des agents, aux détails du système, à l'utilisation du CPU, etc. pour voir ce qui se passe.

3) C'est un point très intéressant que vous soulevez. D'après ce que je comprends, l'optimiseur ne considère une combinaison particulière de paramètres comme "utilisée" que lorsqu'il a obtenu les résultats pour cette combinaison particulière de paramètres, mais je peux me tromper. Peut-être que quelqu'un de MetaQuotes pourrait commenter ce point ?

En tout cas, j'espère que vous faites des progrès ! :)

 
angevoyageur:
Combien d'agents sont disponibles quand on rejette tous ceux qui ont moins de 32G de ram ?

Bonjour,

Cela semble être une grande quantité de RAM pour un PC grand public, mais le cloud ne semble pas avoir de problèmes pour trouver des machines avec ces spécifications. Lorsque je lance une optimisation, l'optimiseur trouve facilement les 64 agents initiaux, puis monte assez rapidement à 128 (en fonction de la configuration du jeu de paramètres, bien sûr). J'ai d'abord essayé 8 Go - l'optimisation a fonctionné plus longtemps et s'est souvent terminée, mais il arrivait encore régulièrement qu'un agent produise une erreur et, par conséquent, interrompe l'optimisation. J'ai ensuite essayé 16 Go - là encore, c'était mieux mais pas parfait. Je n'ai pas pris la peine d'essayer 24 Go - j'ai pensé passer directement à 32 Go et voir ce qui se passait :) Et voilà - des optimisations sans faille.

Je voulais jouer davantage et voir si je pouvais affiner un peu plus les exigences de configuration des agents, mais quand on vous fait payer pour jouer, la motivation disparaît rapidement :)

 
cowil:

Bonjour,

Cela semble être une grande quantité de RAM pour un PC grand public, mais le cloud ne semble pas avoir de problèmes pour trouver des machines avec ces spécifications. Lorsque je lance une optimisation, l'optimiseur trouve facilement les 64 agents initiaux, puis passe assez rapidement à 128 (en fonction de la configuration du jeu de paramètres, bien sûr). J'ai d'abord essayé 8 Go - l'optimisation a fonctionné plus longtemps et s'est souvent terminée, mais il arrivait encore régulièrement qu'un agent produise une erreur et, par conséquent, interrompe l'optimisation. J'ai ensuite essayé 16 Go - là encore, c'était mieux mais pas parfait. Je n'ai pas pris la peine d'essayer 24 Go - j'ai pensé passer directement à 32 Go et voir ce qui se passait :) Et voilà - des optimisations sans faille.

Je voulais jouer davantage et voir si je pouvais affiner un peu plus les exigences de configuration de l'agent, mais quand on vous fait payer pour jouer, la motivation disparaît rapidement :)

Il serait intéressant d'avoir un retour de Metaquotes. Si une machine avec 16G ram n'est pas suffisante pour exécuter une optimisation, il y a quelque chose à étudier. Si j'ai bien compris, lorsque vous exécutez votre optimisation localement, vous n'avez aucun problème, pourquoi alors, lorsque vous utilisez le nuage, y a-t-il besoin d'autant de mémoire ?
 
angevoyageur:
Il serait intéressant d'avoir un retour de Metaquotes. Si une machine avec 16G ram n'est pas suffisante pour exécuter une optimisation, il y a quelque chose à étudier. Si j'ai bien compris, lorsque vous exécutez votre optimisation localement vous n'avez pas de problème, pourquoi alors lorsque vous utilisez le cloud il y a un besoin de tant de mémoire ?

Je n'en ai absolument aucune idée. Ma machine locale est une machine dotée d'un processeur i7 de 8 Go, sur laquelle MT5 a installé 8 agents locaux (il ne s'agit évidemment que d'un processeur à 4 cœurs, mais avec Hyper-Threading, Windows et donc MT5 le considèrent bien sûr comme un processeur à 8 cœurs). Lorsqu'une optimisation est en cours, les agents semblent utiliser environ 400 Mo de mémoire chacun, ce qui correspond évidemment à environ 3,2 Go de mémoire nécessaire pour les 8 agents. Loin de 32 Go....

L'autre chose à laquelle j'ai pensé et qui pourrait être à l'origine de ce problème est le fait qu'un seul "mauvais" agent du nuage met fin à toute l'optimisation. En fait, il se peut que lorsque le serveur en nuage alloue des agents pour une tâche d'optimisation (sans que les exigences en matière de mémoire soient indiquées), le ou les mêmes agents "défectueux" soient sélectionnés. Lorsque les besoins en mémoire sont indiqués dans OnInit(), les "mauvais" agents sont ignorés parce que les boîtes sur lesquelles ils fonctionnent ne répondent pas aux exigences et seuls les bons agents sont sélectionnés. En y réfléchissant, je pense que c'est probablement plus le cas.

Et oui, j'ai signalé ce problème à MetaQuotes mais je n'ai pas encore eu de réponse.

 

Si OnInit (ou toute autre fonction) est exécutée pendant plus de 10 minutes, même sur un agent lent, cela est considéré comme une boucle sans fin nuisible pour le MQL5 Cloud Network (Notez qu'il n'y a pas de telle limitation pour les agents locaux et distants).

Pour ce genre de situations, nous avons implémenté le code de retour INIT_AGENT_NOT_SUITABLE pour la fonction OnInit. En l'utilisant, un utilisateur de réseau en nuage peut vérifier et rejeter les agents inadaptés au tout début d'un test.

Vous pouvez considérer ce commentaire comme une réponse officielle à votre ticket de Service Desk. Nous savons que vous avez pris connaissance des informations données ci-dessus.

En outre : Dans tous les cas, toute fonction est considérée comme anormale, inefficace et non optimale si son exécution prend plus de 10 minutes, même sur un PC des plus lents.

 
MetaQuotes:

Si OnInit (ou toute autre fonction) est exécutée pendant plus de 10 minutes, même sur un agent lent, cela est considéré comme une boucle sans fin nuisible pour le MQL5 Cloud Network (Notez qu'il n'y a pas de telle limitation pour les agents locaux et distants).

Pour ce genre de situations, nous avons implémenté le code de retour INIT_AGENT_NOT_SUITABLE pour la fonction OnInit. En l'utilisant, un utilisateur de réseau en nuage peut vérifier et rejeter les agents inadaptés au tout début d'un test.

Vous pouvez considérer ce commentaire comme une réponse officielle à votre ticket de Service Desk. Nous savons que vous avez pris connaissance des informations données ci-dessus.

En outre : Dans tous les cas, toute fonction est considérée comme anormale, inefficace et non optimale si son exécution prend plus de 10 minutes même sur un PC des plus lents.

Salut MetaQuotes,

Tout d'abord, merci beaucoup pour vos commentaires - très appréciés.

Le problème auquel je suis confronté (et d'autres apparemment si vous regardez en arrière sur cette publication) est que lorsqu'une optimisation est effectuée en utilisant mes agents locaux, l'optimisation se déroule bien - c'est-à-dire que le statut "pourcentage d'achèvement" sur chaque agent augmente régulièrement au fur et à mesure que l'optimisation progresse. Si le gestionnaire d'événement OnTick() de mon expert contenait un code dont l'exécution prendrait plus d'une minute (sans parler de 10 minutes), ces pourcentages de "pourcentage d'exécution" devraient certainement s'interrompre à ces moments-là ? Ne devrais-je pas voir des pauses de 10 minutes (ou plus) dans ces pourcentages d'état si mon code contenait les formes de boucles sans fin auxquelles les erreurs de l'agent du nuage font allusion ?

 

Eh bien, après de nombreuses heures à réduire mon expert, il semble que j'ai trouvé la source des problèmes avec les erreurs de "boucle sans fin" OnInit() ou OnTick() - c'est la commande SymbolInfoInteger(). Je ne sais pas si SymbolInfoDouble() ou SymbolInfoTick() causent les mêmes problèmes car je n'ai pas encore eu l'occasion d'expérimenter davantage. Si quelqu'un veut essayer ceci, exécutez l'Expert suivant dans l'Optimiseur, en utilisant des agents de nuages :

/+------------------------------------------------------------------+
//|                                              MultiSymbolTest.mq5 |
//|                                                                  |
//+------------------------------------------------------------------+
input double var1 = 45;
input double var2 = 54;

input bool onInit = true;
input bool onTick = false;


//+------------------------------------------------------------------+
//| expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit() { 

    
    if (onInit) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return(INIT_FAILED);
        }
    }           

    // Return...
    return(INIT_SUCCEEDED);
}



//+------------------------------------------------------------------+
//| expert start function                                            |
//+------------------------------------------------------------------+
void OnTick() {

    if (onTick) {
    
        string pairsToTrade[] = {"AUDUSD","EURJPY","EURUSD","GBPUSD","AUDJPY","USDJPY","AUDCAD"};
        for (int i=0; i<ArraySize(pairsToTrade); i++) {
            int digits = SymbolInfoInteger(pairsToTrade[i], SYMBOL_DIGITS);
            if (digits == -1)
                return;
        }
    }           

    ExpertRemove();
}    

Choisissez si vous voulez tester OnInit() ou OnTick(), donnez à var1 et var2 suffisamment de valeurs start/step/stop pour générer environ 1000 combinaisons (probablement moins mais c'est ce que j'ai utilisé) et lancez l'optimiseur. Dans environ 10 minutes, vous verrez apparaître l'erreur "boucle sans fin détectée".

Oh, et la raison pour laquelle j'ai mis "ExpertRemove()" à la fin de OnTick() était de montrer qu'il suffit d'une itération de OnTick() pour générer l'erreur.

Inutile de dire que j'ai également signalé ce problème au service d'assistance...

 
Oh, et j'ai oublié de mentionner que, pour une raison quelconque, la correction de mémoire que j'ai fournie ci-dessus semble résoudre le problème la plupart du temps, mais pas tous. Comment/pourquoi/quoi cela fonctionne, je ne sais pas. Cela doit chatouiller quelque chose dans les entrailles de MT5... :)
 

Je peux confirmer ce problème :

2013.05.20 14:22:31 MQL5 Cloud Europe 2 passes génétiques (0, 22) testées avec l'erreur "boucle sans fin détectée dans la fonction OnInit, expert rejeté par MQL5 Cloud Network" en 602 sec (PR 140).

 
Je dois réfléchir...
12345
Nouveau commentaire