Une cachette folle d'agents de test

alrane  

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.

alrane  
P.S. : le terminal est 64x bit, dernière version
Andrey Sharov  
alrane:

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).

alrane  
Les cendres:

В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!

C'est là que réside (que les développeurs me pardonnent) la stupidité de l'organisation des testeurs, lorsque le nombre d'agents passe d'un avantage à un problème.

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é.

Les cendres:

À 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).

Vous ne devriez pas le faire pour la même raison - les cœurs attendront également des données du disque, mais déjà en double volume. Je pense que cela ne fera que diminuer les performances.
Andrey Sharov  
alrane:
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.

alrane  
Je l'ai déjà écrit. C'est inutile.
Renat Fatkhullin  

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.

fxsaber  
alrane:

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 ? !
Renat Fatkhullin  
fxsaber:
Qu'y a-t-il à cacher dans de tels volumes ? !
En général, les traders préfèrent regarder la taille du dossier sans remarquer qu'il contient des dizaines de gigaoctets de journaux détaillés générés par leurs soins.

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.
fxsaber  
Renat Fatkhullin:
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.
Nous parlions de gigaoctets de cache par agent local. Je ne comprends toujours pas ce qui peut y être stocké en telle quantité ?
alrane:
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.

Renat Fatkhullin  

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.

Raison: