![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Fatigué de déboguer les instantanés. C'est finalement parfait. Un conseiller, rien. Deux - parfait. 20 - désastre : le CPU est en dessous de 100%. HistorySelect a un retard de plusieurs millisecondes.
Il semble que MT5 ne soit pas prévu pour faire fonctionner plusieurs Expert Advisors en même temps.
Etes-vous en train d'écrire un test de stress ou un conseiller expert habituel ?
Il s'agit très probablement d'un test de résistance multithread dans une base unique. Je vais donc répéter :
Forum sur le trading, les systèmes de trading automatisés et les tests de stratégies de trading
MT5 et la vitesse en action
Renat Fatkhullin, 2020.09.16 12:47
Si je comprends bien, il ne s'agit pas d'un EA, mais d'un stress tester sur chaque symbole. Cela change complètement l'affaire. Et cela montre la dissimulation des conditions initiales.
C'est-à-dire que, sur 8(4+HT) CPU, 16 threads (+N threads de terminaux de travail en parallèle) décomposent sans arrêt et sans délai un objet de base de données de symboles synchronisés. Les verrous de lecture/écriture sont mélangés parce qu'il y a une écriture constante.
Habituellement, dans un tel profil, en fonction de la pente du processeur et de sa maîtrise des threads, chaque thread peut passer de 60% à 80% du temps à attendre.
Et ce, quel que soit le type de tâche.
Si vous êtes réellement en train de vous battre sans arrêt pour une ressource dans 20 fils, il existe plusieurs options :
Lisez attentivement la boîte. Si N threads touchent un seul objet de synchronisation, l'attente à vide sera de 60-80%.
Et la limite de l'efficacité du multithreading se situera quelque part autour de 8-12 threads. Plus le nombre de fils augmente, plus le taux d'échantillonnage diminue. Sur 2600k, la limite d'efficacité est encore plus basse.
Rédigez-vous un test de résistance ou un simple travail d'expert ?
Ordinaire
Il s'agit plutôt d'un test de résistance multithread dans une base unique. Je vais donc répéter :
Si, en fait, vous vous battez sans relâche pour une seule ressource dans 20 fils, il existe plusieurs options :
Lisez attentivement la boîte. Si N threads touchent un seul objet de synchronisation, l'attente à vide sera de 60-80%.
Et la limite de l'efficacité du multithreading se situera quelque part autour de 8-12 threads. Plus le nombre de fils augmente, plus le taux d'échantillonnage diminue. Sur 2600k, la limite d'efficacité est encore plus basse.
Mise en cache complète de l'historique. Mais même cela nécessite d'appeler HistorySelect(0, INT_MAX).
A titre expérimental, j'ai coupé tous les appels à l'historique nécessaires à la logique de trading. La charge sur le CPU a beaucoup diminué.
D'une manière générale, s'il y a 20 robots, les appeler dans toute l'histoire signifie que vous pouvez provoquer une catastrophe avec un seul terminal. De plusieurs terminaux dont nous ne pouvons même pas parler.
Et on a l'impression que l'objet synchro n'est pas seulement de l'histoire ancienne. SymbolInfoTick, CopyTicks et quelque chose d'autre, semble-t-il.
De toute façon, je n'arrive même pas à faire fonctionner cinq terminaux avec une douzaine de robots sur chacun.
Regarder le profileur de freinage est une déception.
Ordinaire
Mise en cache complète de l'historique. Mais même cela nécessite d'appeler HistorySelect(0, INT_MAX).
A titre expérimental, j'ai coupé tous les appels à l'historique nécessaires à la logique du trading. La charge sur le CPU a beaucoup diminué.
En règle générale, s'il y a 20 robots, les appeler dans toute l'histoire provoquera un désastre avec un seul terminal. De plusieurs terminaux dont nous ne pouvons même pas parler.
Et on a l'impression que l'objet synchro n'est pas seulement de l'histoire ancienne. SymbolInfoTick, CopyTicks et quelque chose d'autre, semble-t-il.
De toute façon, je n'arrive même pas à faire fonctionner cinq terminaux avec une douzaine de robots sur chacun.
Regarder le profileur de freinage est une déception.
Aucune preuve, ni données chiffrées.
1) Combien de fois par seconde chaque EA effectue-t-il des requêtes HistorySelect ?
2) Quelles sont exactement les fonctions qui ralentissent ?
3) Les journaux ?
4) Quel est le principe des robots ?
En somme, s'il y a 20 robots, alors aborder l'histoire en eux revient à provoquer une catastrophe avec un seul terminal. Les terminaux multiples sont hors de question.
Peut-être au contraire - chaque terminal supportera son propre objet synchro, et il n'y aura pas une file d'attente de 20 EAs vers lui ?
Essayez de faire fonctionner 1 robot sur 1 terminal, il sera intéressant de voir le résultat.
Peut-être au contraire - chaque terminal supportera son propre objet de synchronisation et il n'y aura pas une file d'attente de 20 EAs vers lui ?
Essayez de faire fonctionner 1 robot sur 1 terminal, c'est intéressant de voir le résultat.
Malheureusement, le résultat de cette expérience ne répondra pas à la question : que faire ?
Malheureusement, le résultat de cette expérience ne répondra pas à la question : que faire ?
Reconsidérer le concept de robot de trading
Ajouté
J'ai 3 terminaux sur le réel + 1 démo dans lesquels je travaille
Chaque terminal compte 42 robots qui utilisent OnBoorEvent de 3 à 4 caractères,
De plus, toutes les 0,5 secondes, un timer se déclenche + chaque robot accède aux variables globales du terminal,
et il utilise 8,34 Go de RAM sur 32 Go et 6,7 % de CPU
Et rien ne ralentit, à l'exception du serveur TM5 au début des sessions de négociation.
Il n'y a pas de preuve, ni de données chiffrées.
1) Combien de fois par seconde chaque expert effectue-t-il des requêtes HistorySelect ?
2) Quelles sont exactement les fonctions qui ralentissent ?
3) Les journaux ?
4) Quel est le principe des robots ?
Il m'est très difficile de répondre à ces questions, car moi-même, je n'arrive pas à comprendre ce qui nous ralentit. Le profileur ne fonctionne même pas. Leurs mesures sont trichées, car le décalage provient déjà du CPU. La réduction de l'accès aux fonctions d'environnement via les snapshots et la mise en cache n'a malheureusement pas donné l'effet escompté. J'attends un profileur, qui sera capable de compiler le Conseiller Expert.
Pendant que j'étais occupé, j'ai trouvé un tel désordre dans le testeur de stratégie avec l'historique des transactions.
Le résultat est
J'ai à peine remarqué ce bug et j'essaie d'écrire un replay depuis plus d'une heure. Le code est stupide mais il montre le problème. Je ne sais pas s'il existe quelque chose de similaire non pas dans le Testeur mais dans le Terminal.
Chaîne de recherche: Oshibka 013.
ZS b2626 - corrigé.
Reconsidérer le concept de robot de trading
Un seul robot qui négocie tous les symboles ?
Un seul robot qui négocie tous les symboles ?
Des robots différents, mais tous construits à peu près sur le même modèle.
Un terminal compte 42 emplois à la fois, et sur trois, 126, soit environ 400 symboles.
Ajouté
Pour répéter (moi)
Chaque robot utilise OnBoorEvent de 3 à 4 caractères,
plus toutes les 0.5 sec un timer est déclenché + chaque robot accède auxVariables Globales du terminal,
8,34 Go de RAM sur 32 Go sont utilisés et 6,7% du CPU est utilisé
Et rien ne ralentit, à l'exception du serveur TM5 (ou du matériel Openreach) au début des sessions de négociation.
Des robots différents, mais tous construits à peu près selon le même schéma.
Il y a 42 travaux impliqués dans un terminal à la fois, et sur trois - 126 est environ 400 caractères
Ajouté
Pour répéter (moi).
Chaque robot utilise OnBoorEvent de 3 à 4 caractères,
plus toutes les 0.5 sec un timer est déclenché + chaque robot accède auxVariables Globales du terminal,
8,34 Go de RAM sur 32 Go et 6,7 % d'utilisation du CPU
Et rien ne ralentit, sauf le serveur TM5 (ou le fer d'Open) au début des sessions de négociation.
Voilà le truc bizarre, c'est le contraire pour moi.
Mon appareil a 4 terminaux, j'ai réduit le nombre d'Expert Advisors à environ 200, j'ai coupé tous les OnBooks, je suis revenu à OnTick et j'ai mis à jour mon matériel mais les problèmes sont les mêmes qu'avec fxsaber.
Mais il n'y a pas de décalage le matin dans mon Opener depuis longtemps déjà. Et ce qu'ils étaient ! Jusqu'à 75 secondes parfois :)