![MQL5 - Linguaggio delle strategie di trading integrato nel client terminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Stanco di fare il debug delle istantanee. Finalmente l'ha reso perfetto. Un consulente, niente. Due - perfetto. 20 - disastro: la CPU è sotto il 100%. HistorySelect ha un ritardo di molti millisecondi.
Sembra che MT5 non sia destinato a gestire molti Expert Advisors allo stesso tempo.
Stai scrivendo uno stress test o un normale Expert Advisor?
Molto probabilmente esattamente uno stress test multi-thread in una singola base. Quindi ripeterò:
Forum sul trading, sistemi di trading automatico e test di strategie di trading
MT5 e la velocità in azione
Renat Fatkhullin, 2020.09.16 12:47
Se ho capito bene, non c'è un EA lì, ma uno stress tester su ogni simbolo. Questo cambia completamente il caso. E mostra il nascondersi delle condizioni iniziali.
Cioè, su 8(4+HT) CPU 16 thread (+N worker terminal threads in parallelo) non stop e senza ritardo si rompono in un oggetto di database di simboli sincronizzato. I blocchi di lettura/scrittura si confondono perché c'è una scrittura a tick costante.
Di solito in un tale profilo, a seconda della ripidità del processore e della sua padronanza dei thread, ogni thread può passare dal 60% all'80% del tempo in attesa.
E questo indipendentemente dal tipo di compito.
Se si sta effettivamente avendo una battaglia non-stop per una risorsa in 20 fili, ci sono diverse opzioni:
Leggete attentamente la scatola. Se N threads colpiscono un singolo oggetto sync, l'attesa vuota sarà al 60-80%.
E il limite dell'efficienza multi-thread sarà da qualche parte intorno agli 8-12 thread. Man mano che il numero di thread aumenta, la frequenza di campionamento diminuisce. Su 2600k il limite di efficienza è ancora più basso.
Stai scrivendo uno stress test o un normale lavoro da esperto?
Ordinario
Piuttosto, è uno stress test multi-threaded in una singola base. Quindi ripeterò:
Se infatti state facendo una battaglia non-stop per una singola risorsa in 20 thread, ci sono diverse opzioni:
Leggete attentamente la scatola. Se N threads colpiscono un singolo oggetto sync, l'attesa vuota sarà al 60-80%.
E il limite dell'efficienza multi-thread sarà da qualche parte intorno agli 8-12 thread. Man mano che il numero di thread aumenta, la frequenza di campionamento diminuisce. Su 2600k il limite di efficienza è ancora più basso.
Caching completo della storia. Ma anche questo richiede di chiamare HistorySelect(0, INT_MAX).
Come esperimento, ho tagliato tutte le chiamate alla storia necessarie per la logica di trading. Il carico sulla CPU è diminuito molto.
In generale, se ci sono 20 robot, chiamarli in tutta la storia significa che si può causare un disastro con un solo terminale. Di diversi terminali non possiamo nemmeno parlare.
E sembra che l'oggetto sincro non sia solo storia. SymbolInfoTick, CopyTicks e qualcos'altro, sembra.
Comunque, non riesco nemmeno a far funzionare cinque terminali con una dozzina di robot su ciascuno.
Guardare il profilatore di frenata è un peccato.
Ordinario
Caching completo della storia. Ma anche questo richiede di chiamare HistorySelect(0, INT_MAX).
Come esperimento, ho tagliato tutte le chiamate storiche necessarie per la logica di trading. Il carico sulla CPU è diminuito molto.
In generale, se ci sono 20 robot, chiamarli in tutta la storia causerà un disastro con un solo terminale. Di diversi terminali non possiamo nemmeno parlare.
E sembra che l'oggetto sincro non sia solo storia. SymbolInfoTick, CopyTicks e qualcos'altro, sembra.
Comunque, non riesco nemmeno a far funzionare cinque terminali con una dozzina di robot su ciascuno.
Guardare il profilatore di frenata è un peccato.
Nessuna prova, né dati numerici.
1) Quante volte al secondo ogni EA fa delle query di HistorySelect?
2) Esattamente quali funzioni stanno rallentando?
3) Registri?
4) Qual è il principio dei robot?
Tutto sommato, se ci sono 20 robot, affrontare la storia in essi significa provocare un disastro con un solo terminale. I terminali multipli sono fuori questione.
Forse al contrario - ogni terminale supporterà il proprio oggetto synchro, e non ci sarà una coda di 20 EAs ad esso?
Provate ad eseguire 1 robot su 1 terminale, sarà interessante vedere il risultato.
Forse al contrario - ogni terminale supporterà il proprio oggetto sync e non ci sarà una coda di 20 EAs ad esso?
Provate ad eseguire 1 robot su 1 terminale, è interessante vedere il risultato.
Purtroppo, il risultato di questo esperimento non risponderà alla domanda: cosa fare?
Purtroppo, il risultato di questo esperimento non risponderà alla domanda: cosa fare?
Riconsiderare il concetto di robot di trading
Aggiunto
Ho 3 terminali su reale + 1 demo in cui lavoro
Ogni terminale ha 42 robot che usano OnBoorEvent da 3 a 4 caratteri,
In più ogni 0,5 sec il timer scatta + ogni robot accede alle variabili globali del terminale,
e utilizza 8,34 GB di 32 GB di RAM e il 6,7% di CPU
E niente rallenta, tranne il server TM5 all'inizio delle sessioni di trading.
Non ci sono prove, né dati numerici.
1) Quante volte al secondo ogni esperto fa delle query di HistorySelect?
2) Quali funzioni esattamente stanno rallentando?
3) Registri?
4) Qual è il principio alla base dei robot?
È molto difficile per me rispondere a queste domande, perché nemmeno io riesco a capire cosa sta rallentando. Il profiler non funziona nemmeno. Le loro misurazioni stanno imbrogliando, perché il ritardo viene già dalla CPU. Ridurre l'accesso alle funzioni d'ambiente tramite snapshot e caching, purtroppo, non ha dato l'effetto sperato. Sto aspettando un profiler, che sarà in grado di compilare l'Expert Advisor.
Mentre ero occupato, ho trovato un tale casino nello Strategy Tester con la storia degli scambi.
Il risultato è
Non ho quasi notato questo bug e ho cercato di scrivere un replay per più di un'ora. Il codice è idiota ma mostra il problema. Se c'è qualcosa di simile non nel Tester ma nel Terminale, non lo so.
Stringa di ricerca: Oshibka 013.
ZS b2626 - fissato.
Riconsiderare il concetto di robot di trading
Un solo robot che scambia tutti i simboli?
Un solo robot che scambia tutti i simboli?
Robot diversi, ma tutti costruiti più o meno sullo stesso modello.
Ci sono 42 lavori coinvolti in un terminale alla volta, e su tre, 126 sono circa 400 simboli
Aggiunto
Per ripetere (io)
Ogni robot usa OnBoorEvent da 3 a 4 caratteri,
più ogni 0,5 sec si attiva un timer + ogni robot accede allevariabili globali del terminale,
8,34 GB di 32 GB di RAM e 6,7% di utilizzo della CPU
E niente rallenta, tranne il server TM5 (o l'hardware Openreach) all'inizio delle sessioni di trading.
Robot diversi, ma tutti costruiti più o meno secondo lo stesso schema.
Ci sono 42 lavori coinvolti in un terminale alla volta, e su tre - 126 sono circa 400 caratteri
Aggiunto
Per ripetere (io).
Ogni robot usa OnBoorEvent da 3 a 4 caratteri,
più ogni 0,5 sec si attiva un timer + ogni robot accede allevariabili globali del terminale,
8,34 GB di 32 GB di RAM e 6,7% di utilizzo della CPU
E niente sta rallentando, tranne il server TM5 (o il ferro di Open) all'inizio delle sessioni di trading.
Ecco la cosa strana: per me è il contrario.
Il mio dispositivo ha 4 terminali, ho ridotto il numero di Expert Advisors a circa 200, ho tagliato tutti gli OnBooks, sono tornato a OnTick e ho aggiornato il mio hardware ma i problemi sono gli stessi di fxsaber.
Ma non ci sono lag al mattino nel mio Opener già da molto tempo. E come erano una volta! Fino a 75 secondi a volte :)