La RAM ne se libère pas... - page 6

 
Renat:

Je ne parlais que du problème de la taille des fichiers. Les anciennes versions des blocs historiques y étaient stockées sans être supprimées.

La RAM est déjà utilisée par les experts eux-mêmes.

Un autre problème est que les agents consomment toute la RAM, commencent à travailler avec le swap et l'ordinateur devient alors une "tortue".
 

L'agent est maintenant 756.

Lequel a réglé le problème ?

 
GoRo:

L'agent est maintenant 756.

Lequel a réglé le problème ?

Le prochain, qui sort aujourd'hui. Il n'a pas encore été publié.
 

1. Il y a quelque temps, les agents travaillaient comme des horloges. Chacune d'entre elles occupait environ 300 Mo de mémoire. Mais sur le disque système (installé dans Progamm Files), chaque agent avait environ 5 Go de fichiers .tmp dans des dossiers temporaires.

Est-ce normal ?

2. J'ai trouvé ces entrées intéressantes dans les journaux des agents

JM      2       Logger  20:49:44        log was cleaned
JL      0       Network 00:00:00        connected to 3.agents.mql5.com
DK      0       Network 20:50:14        connected to 3.agents.mql5.com
KR      0       Network 20:50:44        connected to 3.agents.mql5.com
KI      0       Network 20:51:14        connected to 3.agents.mql5.com

Tous les journaux ont été supprimés et, en cas d'erreur, je ne serai même pas en mesure de fournir, comme preuve, les journaux.

Maintenant, même le temps de fonctionnement des agents n'est pas connu, la quantité de mémoire utilisée, etc. Alors pourquoi les journaux s'ils sont immédiatement nettoyés ? Auparavant, les journaux étaient supprimés pendant plus de 3 jours.

PS. Dans la deuxième ligne du journal, l'heure est erronée.

 
fyords:

...

Il est maintenant assez difficile de fournir des informations sur les bogues qui sont liés aux testeurs, à l'optimisation ou au cloud. Beaucoup de temps est consacré à l'analyse syntaxique. J'ai un jour suggéré de sauvegarder les résultats de l'optimisation dans une archive afin de pouvoir la rouvrir dans MetaTrader 5 pour l'analyser sans avoir à refaire l'optimisation. Si une telle archive pouvait être sauvegardée, il serait plus simple de l'envoyer aux développeurs pour qu'ils l'analysent. Autrement dit, l'archive contiendrait les résultats de l'optimisation, les journaux (uniquement les erreurs) et toutes les autres informations nécessaires.
 
Renat:
Dans le prochain, qui sort aujourd'hui. Il n'a pas encore été publié.
Je n'ai pas eu de mise à jour...
 
Les journaux devaient être supprimés plus activement car ils s'accumulent très rapidement et peuvent occuper des gigaoctets. L'agent garde ses propres répertoires propres.

Nous avons décidé de ne pas publier la version d'hier et de la reporter à lundi pour effectuer davantage de tests.
 
Renat:
Les journaux devaient être supprimés plus activement car ils s'accumulent très rapidement et peuvent occuper des gigaoctets. L'agent lui-même garde ses propres répertoires propres. ...

Non, eh bien, ça ne me dérange pas. Mais alors, s'il y a un problème, par exemple la manipulation des tâches dans un réseau domestique avec un routeur, que prévoir pour l'analyse syntaxique ?

Ou bien les journaux sont-ils nettoyés lorsqu'un certain événement se produit (pas tous les jours) ?

 
fyords:

Non, eh bien, ça ne me dérange pas. Mais alors, s'il y a un problème, par exemple la manipulation des tâches dans un réseau domestique avec un routeur, que prévoir pour l'analyse syntaxique ?

Ou bien les journaux sont-ils nettoyés lorsqu'un certain événement se produit (pas tous les jours) ?

Les journaux peuvent être consultés dans le dossier lors de problèmes.

Pour l'analyse syntaxique, il suffit d'arrêter l'agent à partir du gestionnaire d'agents et de voir les journaux complets.

 
Avec la sortie de la dernière version, la situation semble s'être améliorée.
Raison: