Build 600+ et utilisation du CPU - page 8

 
xaphod:

Build 628. Pas de tics entrants. >500 fois/seconde. Merveilleux !

S'il vous plaît, vérifiez avec la version 645 (dernière version officielle), et signalez-la au ServiceDesk de Metaquotes, si elle est inchangée. Merci.
 
xaphod:

Build 628. Pas de tics entrants. >500 fois/seconde. Merveilleux !


Donc la version 509 n'a rien donné ? Et la 625 ?
 
mikeyap9:
Corrigé et c'était dû à mon code. J'ai ajouté des variables qui n'étaient pas initialisées correctement et j'avais des calculs qui tournaient en boucle sans fin.


J'ai parlé trop vite, ce n'était pas ça. C'était en fait une contention de lecture de fichier, j'ai 28 bots qui lisent le même fichier de configuration. Tout ce que j'ai fait, c'est passer à FILE_SHARE_READ au lieu de FILE_READ. Tout est rentré dans l'ordre maintenant.
 

J'ai toujours une utilisation élevée du CPU sur un seul terminal. J'utilise les builds 745 et 765. J'ai testé le terminal sans graphiques chargés, les nouvelles désactivées, les alertes désactivées. J'obtiens toujours 40-60% d'utilisation du CPU. vps dual core 3.1Ghz win2008, R2 64 bit. 1.5GB ram, 400-800MB ram libre. Environ 7 terminaux en cours d'exécution. Certains terminaux chargés de graphiques affichent une utilisation du processeur de 1 à 3%. Pourquoi cette utilisation élevée sur des terminaux aléatoires, même si rien n'est en cours d'exécution ?

edit : Voici une capture d'écran de la page des propriétés du processus de Process Explorer :

J'essaie de tuer le fil d'exécution à forte utilisation, mais un autre fil d'exécution utilisant la même utilisation du processeur prend sa place.

edit : ensuite j'essaie de 'suspendre' le thread (pas de le tuer).

Cela réduit le cpu, mais je dois voir si cela affecte le terminal d'une autre manière. Des messages précédents ont suggéré que les cotations ont cessé d'arriver au terminal (lorsqu'elles sont tuées). Donc, lorsque le marché reprendra plus tard dans la journée, je devrai voir. J'ai essayé de le reprendre maintenant et le fil de discussion est juste revenu à l'utilisation élevée du processeur. Pas de graphiques ouverts, et la surveillance du marché n'a pas de symboles (cacher tout). De plus, les marchés sont fermés, donc pas de ticks entrants.

Lorsque je suspends le fil de discussion, le terminal semble fonctionner normalement pendant 5 à 10 minutes, puis il se fige soudainement (ne répond pas) et vous devez alors soit désuspendre (reprendre) le fil de discussion pour que le programme fonctionne, soit redémarrer le programme.

J'ai remarqué qu'un autre terminal que j'ai lancé à peu près au même moment après le redémarrage et qui avait également une utilisation élevée de la mémoire ne l'a plus (il est redescendu à 0,2-1,5 % d'utilisation du processeur). Et ce terminal a des graphiques ouverts avec des EA et des indicateurs. Il ne semble pas y avoir de raison rationnelle à cette utilisation élevée inexpliquée du processeur, à moins que je ne manque quelque chose.

 

Je viens de tester sur un tout nouveau serveur de test, cette fois avec Windows 2012 64 bits, 4 processeurs et 2 Go de RAM. J'ai lancé des terminaux avec une faible utilisation du processeur (entre 0,1 et 1%), même avec plusieurs graphiques et indicateurs chargés.

Ensuite, j'ai lancé un terminal fraîchement installé, et environ 2 minutes après le lancement, il passe à 25% d'utilisation (aucun graphique ouvert). Les autres terminaux existants ont une utilisation plus faible.

Puis les autres terminaux qui se comportaient sans incident. Lorsqu'ils sont redémarrés, les terminaux immédiats utilisent beaucoup de cpu. Hmmmm....

Je pense que c'est un bug de mt4 qui fait qu'un thread utilise autant de cpu. Mais pourquoi ?

-------

edit : En débloquant le fichier mql4.codebase.en.dat, l'utilisation du cpu est revenue à 0.2-3%. Il n'y a plus de maximum d'un processeur par terminal et le fichier s'écrit normalement.

Le fichier mql4.codebase.en.dat se trouve ici : Users\[user]\AppData\Roaming\MetaQuotes\Terminal\Community

Auparavant, des permissions de lecture seule étaient attribuées à certains fichiers mt4 afin de réduire le bloatware.

Raison: