Une cachette folle d'agents de test
Bonne journée à vous tous !
J'ai rencontré le problème suivant :
Avoir 32 processeurs logiques dans le système - utiliser 32 agents pour l'optimisation respectivement (+ 40 autres à distance).
Chaque agent se constitue assez rapidement un cache d'une taille tout à fait inadéquate de 2-2,6 Go, qui s'élève au total à plus de 70 Go en une journée ! Le cache lui-même n'est pas supprimé et ne cesse de croître. La seule chose qui a arrêté cette folie a été de manquer d'espace disque. Après quoi, les agents cessent stupidement de travailler.
Les questions sont les suivantes :
Quelqu'un a-t-il été confronté à un tel problème ? Comment y faire face ? Qu'est-ce qui peut causer de telles tailles de cache ?
J'ai écrit une demande à servicedesk, jusqu'ici silence.
La taille du cache dépend du nombre de ticks générés (c'est-à-dire que plus la période de test et le nombre de caractères sont longs, plus le cache est grand).
Dans votre cas, le principal problème est probablement le nombre d'agents, car maintenant (build 1495) chaque agent utilise sa propre instance de cache !
L'espace cache est libéré après 5 minutes d'arrêt de l'agent.
En outre, l'historique des tics pour les agents de test peut prendre de la place s'ils sont utilisés dans le nuage (l'historique des tics finit par être nettoyé aussi, mais il se compte en jours ou en semaines).
À propos, les agents du nuage et les agents locaux sont différents. Dans l'image, les agents du nuage sur le même ordinateur sont ajoutés à la ferme du réseau local - Voilà ! Nous avons obtenu 8 agents de test sur un processeur à deux cœurs et quatre processeurs logiques (savoir si cela vaut la peine de le faire est une autre question).
В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!
Le testeur ne dispose d'aucun paramètre, il est donc impossible de l'optimiser pour votre système. En sortie, nous avons un abus de disque dur avec un nombre énorme de petits fichiers réécrits (jusqu'à 800 Go/jour sur un SSD de 120 Go avec 32 agents dans le système), et ce qui est amusant, c'est que les cœurs à ce moment-là sont inactifs.
J'ai partiellement résolu le problème en faisant tourner 4 testeurs différents en mode portable sur des disques physiques différents. Y compris la destruction de la mémoire vive, car le testeur laisse une grande quantité de mémoire sans surveillance.
À propos, l'exécution d'un agent avec un cache sur un disque RAM augmente souvent les performances jusqu'à 3 fois ! Ce qui montre une fois de plus la façon dégoûtante dont le testeur est organisé.
À propos, les agents du nuage et les agents locaux sont différents. Dans l'image, les agents du nuage sur le même ordinateur sont ajoutés à la ferme du réseau local - Voilà ! Nous avons obtenu 8 agents de test sur un processeur à deux cœurs et quatre processeurs logiques (savoir si vous devez faire cela est une autre question).
C'est la stupidité (pardonnez-moi les développeurs) de l'organisation des testeurs, où le nombre d'agents est transformé d'un avantage en un problème.
Le testeur ne dispose d'aucun paramètre, il est donc impossible de l'optimiser pour votre système. Dans le résultat, nous obtenons un abus du disque dur avec un grand nombre de petits fichiers écrasés (jusqu'à 800 Go/jour sur un SSD de 120 Go avec 32 agents dans le système), et ce qui est drôle, c'est que les cœurs restent inactifs pendant ce temps.
...
À propos, l'exécution d'un agent avec un cache sur un disque dur, augmente souvent les performances jusqu'à 3 fois ! Ce qui montre encore une fois l'organisation de travail dégoûtante du testeur.
...
Écrire au Service Desk.
Devoir lire plusieurs gigaoctets de données sur un disque est une "organisation dégoûtante" ? Même la lecture de 1 Go de données sur un disque dur à une vitesse moyenne de 200 Mbps prend 5 secondes. Et s'il y a 4-32 agents dans la nature ?
Vous ne pensez qu'à l'aspect technique de la tâche. Rien n'est gratuit et personne ne multiplie les exigences techniques par zéro.
La solution technique et le niveau d'optimisation des agents sont étonnants - nous y avons consacré une quantité folle de travail et avons gratté des millisecondes dans tous les processus. N'oubliez pas les volumes de données, mettez plus de RAM, mettez des ssd plus gros, mettez des disques frame et tout sera accéléré.
Les prix de toutes ces choses sont déjà raisonnables, mais la classe et le volume à résoudre exigent une approche sérieuse.
Chaque agent constitue rapidement un cache d'une taille totalement inadéquate, de 2 à 2,6 Go, totalisant plus de 70 Go en une journée ! Le cache ne s'efface pas et s'agrandit constamment. La seule chose qui a arrêté cette folie a été de manquer d'espace disque. Après quoi, les agents cessent stupidement de travailler.
Qu'y a-t-il à cacher dans de tels volumes ? !
Tout est OK avec les caches de données. Nous le conservons sur disque et le gardons en mémoire en attendant les rediffusions. Veuillez noter la rapidité du recalcul sur le même agent (prenez un agent et une exécution pour démontrer l'effet).
Une dernière chose : nous travaillons avec beaucoup de parcimonie avec les disques. Nous écrivons en grand nombre et comprenons clairement les particularités des disques ssd.
Les traders préfèrent généralement vérifier la taille du dossier sans remarquer qu'il y a environ 10 Gbytes de gros journaux générés personnellement.
J'ai partiellement résolu le problème en faisant tourner 4 testeurs différents en mode portable sur des disques physiques différents. Y compris le disque RAM, puisque le testeur laisse une grande quantité de mémoire sans surveillance.
À propos, l'exécution d'un agent avec cache sur un disque RAM augmente souvent les performances jusqu'à 3 fois ! Ce qui montre une fois de plus l'organisation dégoûtante du testeur.
Si le niveau d'optimisation des agents est "merveilleux", quelle est la raison pour laquelle l'organisation RAM-disque permet d'augmenter plusieurs fois les performances ? A mon avis, des questions logiques, bien que désagréables.
ZS Nous devons trouver un logiciel qui efface les enregistrements des agents. Ils sont inutiles en de telles quantités. L'impression+alerte doit être désactivée par l'utilisateur dans le code lors des optimisations.
fxsaber:
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?
Au lieu de faire des déclarations de forum, regardez par vous-même.
Quelle est la raison d'organiser le RAMdisk pour multiplier les performances si le niveau d'optimisation des agents est "incroyable" ? A mon avis, des questions logiques, bien que désagréables.
Parce que nous n'avons pas le droit de consommer 100% de la RAM pour le cache et de la conserver indéfiniment. Mais si une personne crée elle-même un cadre de disque de 32 à 64 Go, y installe des agents et commence à travailler activement avec le disque, alors oui, il est possible d'obtenir une accélération des opérations du disque plusieurs fois.
Mais il s'agit bien d'opérations sur disque, et non pas de "toutes en même temps par un facteur N".
Le fait que le testeur gère les données de manière étonnante est évident pour quiconque l'utilise en mode constant et tire de nombreux avantages des caches du testeur réchauffés qui attendent de nouvelles exécutions en arrière-plan. L'expérimentation consiste généralement en des dizaines ou des centaines d'essais avec une recompilation constante du code.
HH Nous avons besoin d'une sorte de logiciel pour effacer les logs des agents. Nous n'en avons pas besoin en si grande quantité. Et Print+Alert devrait être désactivé par l'utilisateur dans le code lors des optimisations.
Les journaux du testeur sont effacés automatiquement. Ceux qui utilisent le testeur le savent. Et les caches du testeur sont effacés par le terminal dès qu'il comprend que le testeur n'est plus utilisé.
Le topikstarter a lancé le fil de discussion en mode "combien de temps ?" et a fait des déclarations non fondées. S'il avait fourni des données correctement collectées, 50 % des questions seraient tombées dès la phase de collecte des données.
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Bonjour à tous !
J'ai rencontré le problème suivant :
Avoir 32 processeurs logiques dans le système - utiliser 32 agents pour l'optimisation respectivement (+ 40 autres à distance).
Chaque agent se constitue assez rapidement un cache d'une taille totalement inadéquate de 2-2,6 Go, ce qui représente au total plus de 70 Go par jour ! Le cache ne s'efface pas de lui-même et ne cesse de croître. La seule chose qui a arrêté cette folie a été de manquer d'espace disque. Après cela, les agents cessent stupidement de travailler.
Les questions sont les suivantes :
Quelqu'un a-t-il été confronté à un tel problème ? Comment y faire face ? Qu'est-ce qui peut causer des tailles de cache aussi importantes ?
J'ai écrit une demande à servicedesk, jusqu'ici silence.