Verrückter Cache von Prüfmitteln
Guten Tag zusammen!
Ich bin auf das folgende Problem gestoßen:
32 logische Prozessoren im System - mit jeweils 32 Agenten für die Optimierung (+ weitere 40 Remote-Prozessoren)
Jeder Agent baut ziemlich schnell einen Cache von völlig unzureichender Größe auf: 2-2,6 GB, was insgesamt mehr als 70 GB an einem Tag ausmacht! Der Cache selbst wird nicht gelöscht und wächst ständig. Das Einzige, was dem Wahnsinn Einhalt gebot, war, dass der Speicherplatz knapp wurde. Danach hören die Agenten dummerweise auf zu arbeiten.
Die Fragen lauten wie folgt:
Ist jemand mit einem solchen Problem konfrontiert? Wie kann ich damit umgehen? Was kann die Ursache für solche Cache-Größen sein?
Habe eine Anfrage an servicedesk geschrieben, bisher Schweigen.
Die Größe des Zwischenspeichers hängt von der Anzahl der erzeugten Ticks ab (d. h. je länger der Testzeitraum und die Anzahl der Zeichen, desto größer der Zwischenspeicher).
In Ihrem Fall ist das Hauptproblem wahrscheinlich die Anzahl der Agenten, da jetzt (Build 1495) jeder Agent seine eigene Cache-Instanz verwendet!
Der Cache-Speicher wird nach 5 Minuten Ausfallzeit des Agenten freigegeben.
Darüber hinaus kann die Tick-Historie für Agenten im Tester viel Platz beanspruchen, wenn Agenten in der Cloud verwendet werden (die Tick-Historie wird zwar auch irgendwann bereinigt, aber es vergehen Tage oder Wochen).
Übrigens: Cloud-Agenten und lokale Agenten sind unterschiedlich. Im Bild werden die Cloud-Agenten auf demselben Computer zur lokalen Netzwerkfarm hinzugefügt - Voilà! Wir haben 8 Testagenten auf einem Prozessor mit zwei Kernen und vier logischen Prozessoren (ob sich das lohnt, ist eine andere Frage).
В Вашем случае, вероятно, главная проблема - количество агентов, т.к. сейчас (билд 1495) каждый агент использует собственный экземпляр кэша!
Das Testgerät verfügt über keinerlei Einstellungen, so dass es unmöglich ist, es für Ihr System zu optimieren. In der Ausgabe erhalten wir Festplattenmissbrauch mit einer riesigen Anzahl von kleinen Dateien neu geschrieben (bis zu 800 GB/Tag auf SSD 120 GB bei 32 Agenten im System), und was lustig ist, sind die Kerne zu der Zeit im Leerlauf.
Ich habe das Problem teilweise gelöst, indem ich 4 verschiedene Tester im portablen Modus auf verschiedenen physischen Laufwerken laufen ließ. Einschließlich RAM-Diske, da das Testgerät einen großen Teil des Speichers unbeaufsichtigt lässt.
Übrigens, wenn man einen Agenten mit Cache auf einer Ram-Disk laufen lässt, erhöht sich die Leistung oft um bis zu 3 Mal! Das zeigt einmal mehr, wie ekelhaft der Tester organisiert ist.
Übrigens: Cloud-Agenten und lokale Agenten sind unterschiedlich. Im Bild werden die Cloud-Agenten auf demselben Computer zur lokalen Netzwerkfarm hinzugefügt - Voilà! Wir haben 8 Testagenten auf einer CPU mit zwei Kernen und vier logischen Prozessoren (ob man das tun sollte, ist eine andere Frage).
Dies ist die (verzeihen Sie mir, liebe Entwickler) Dummheit der Testerorganisation, bei der die Anzahl der Bearbeiter von einem Vorteil zu einem Problem wird.
Das Testgerät verfügt über keinerlei Einstellungen, so dass es unmöglich ist, es für Ihr System zu optimieren. In der Ausgabe erhalten wir Festplattenmissbrauch mit einer riesigen Anzahl von kleinen Dateien, die überschrieben werden (bis zu 800 GB/Tag auf einer SSD mit 120 GB bei 32 Agenten im System), und was lustig ist, die Kerne bleiben während dieser Zeit im Leerlauf.
...
Übrigens, wenn man einen Agenten mit einem Cache auf einer Frame-Disk laufen lässt, erhöht sich die Leistung oft um bis zu 3 Mal! Das zeigt einmal mehr, wie ekelhaft der Tester organisiert ist.
...
Schreiben Sie an den Service Desk.
Mehrere Gigabyte an Daten von einem Laufwerk lesen zu müssen, ist eine "ekelhafte Organisation"? Selbst das Lesen von 1 GB Daten von einer SSD mit einer durchschnittlichen Geschwindigkeit von 200 MBit/s dauert 5 Sekunden. Und wenn es da draußen 4-32 Agenten gibt?
Sie denken nur an die technische Seite der Aufgabe. Nichts ist umsonst und niemand multipliziert die technischen Anforderungen mit Null.
Die technische Lösung und der Grad der Optimierung der Agenten ist erstaunlich - wir haben eine Menge Arbeit hineingesteckt und bei allen Prozessen Millisekunden herausgekitzelt. Vergessen Sie nicht die Datenvolumina, bauen Sie mehr RAM ein, bauen Sie größere SSDs ein, bauen Sie Frame-Disks ein und alles wird beschleunigt.
Die Preise für all diese Dinge sind bereits angemessen, aber die Klasse und das Volumen, die gelöst werden, erfordern einen ernsthaften Ansatz.
Jeder Agent baut in kürzester Zeit einen Cache von völlig unzureichender Größe auf, 2-2,6 GB, insgesamt über 70 GB an einem Tag! Der Cache löscht sich nicht selbst und wächst ständig. Das Einzige, was dem Wahnsinn Einhalt gebot, war, dass der Speicherplatz knapp wurde. Danach stellen die Agenten dummerweise ihre Arbeit ein.
Was gibt es bei solchen Mengen zu verbergen?!
Mit den Daten-Caches ist alles in Ordnung. Wir bewahren sie auf der Festplatte auf und speichern sie in Erwartung von Wiederholungen. Bitte beachten Sie, wie viel schneller die Neuberechnung bei demselben Agenten ist (nehmen Sie einen Agenten und einen Durchlauf, um die Wirkung zu demonstrieren).
Und noch etwas: Wir arbeiten sehr sparsam mit Festplatten. Wir schreiben in großen Stückzahlen und verstehen die Besonderheiten von SSD-Platten sehr gut.
Die Händler ziehen es in der Regel vor, die Größe des Ordners zu überprüfen, ohne zu bemerken, dass er etwa 10 Gbyte große, persönlich erstellte Protokolle enthält.
Ich habe das Problem teilweise gelöst, indem ich 4 verschiedene Tester im portablen Modus auf verschiedenen physischen Festplatten laufen ließ. Einschließlich RAM-Diske, da das Testgerät einen großen Teil des Speichers unbeaufsichtigt lässt.
Übrigens, wenn man einen Agenten mit Cache auf einer Ram-Disk laufen lässt, erhöht sich die Leistung oft um bis zu 3 Mal! Was einmal mehr auf die ekelhafte Organisation des Testers hinweist.
Welchen Grund gibt es für die RAM-Disk-Organisation, die Leistung um ein Vielfaches zu steigern, wenn der Optimierungsgrad der Agenten "fabelhaft" ist? Meiner Meinung nach logische Fragen, wenn auch unangenehm.
ZS Wir brauchen eine Software, mit der die Protokolle der Agenten gelöscht werden können. Sie sind in solchen Mengen nutzlos. Die Funktion Drucken+Warnung sollte vom Benutzer im Code während der Optimierungen deaktiviert werden.
fxsaber:
Речь шла о гигабайтах КЕША на каждый локальный агент. Мне до сих пор не понятно, что можно там хранить в таких количествах?
Anstatt sich in Foren zu äußern, sollten Sie sich selbst ein Bild machen.
Aus welchem Grund vervielfacht die RAMdisk-Organisation die Leistung, wenn das Niveau der Agentenoptimierung "erstaunlich" ist? Meiner Meinung nach logische Fragen, wenn auch unangenehm.
Denn wir haben nicht das Recht, 100 % des Arbeitsspeichers für den Cache zu verwenden und ihn unbegrenzt zu behalten. Aber wenn eine Person selbst einen 32-64-GB-Plattenrahmen erstellt, Agenten dorthin verschiebt und beginnt, aktiv mit der Platte zu arbeiten, dann ist es möglich, die Geschwindigkeit der Plattenoperationen um ein Vielfaches zu erhöhen.
Aber speziell Festplattenoperationen, nicht "alle auf einmal um einen Faktor N".
Dass der Tester erstaunlich gut mit Daten umgehen kann, ist jedem klar, der ihn im Dauerbetrieb einsetzt und von aufgewärmten Tester-Caches profitiert, die im Hintergrund auf neue Läufe warten. Die Experimente bestehen in der Regel aus Dutzenden oder Hunderten von Testläufen mit ständiger Neukompilierung des Codes.
HH Wir brauchen eine Software, um die Protokolle der Agenten zu löschen. Wir brauchen sie nicht in so großen Mengen. Und Print+Alert sollte vom Benutzer im Code während der Optimierungen deaktiviert werden.
Die Protokolle des Prüfers werden automatisch gelöscht. Diejenigen, die das Prüfgerät benutzen, wissen das. Und die Zwischenspeicher des Prüfgeräts werden vom Terminal gelöscht, sobald es feststellt, dass das Prüfgerät nicht mehr verwendet wird.
Der Topikstarter begann den Thread im "Wie lange?"-Modus und stellte einige unbegründete Behauptungen auf. Hätte er ordnungsgemäß erhobene Daten vorgelegt, wären 50 % der Fragen schon bei der Datenerhebung weggefallen.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Guten Tag zusammen!
Ich bin auf das folgende Problem gestoßen:
32 logische Prozessoren im System - Verwendung von 32 Agenten für die Optimierung (+ weitere 40 Remote-Prozessoren)
Jeder Agent baut ziemlich schnell einen Cache von völlig unzureichender Größe auf: 2-2,6 GB, was insgesamt mehr als 70 GB pro Tag ausmacht! Der Cache löscht sich nicht selbst und wächst ständig. Das Einzige, was diesen Wahnsinn stoppte, war, dass der Speicherplatz knapp wurde. Danach hören die Agenten dummerweise auf zu arbeiten.
Die Fragen lauten wie folgt:
Ist jemand mit einem solchen Problem konfrontiert? Wie geht man damit um? Wie kann es zu solch großen Cache-Größen kommen?
Habe eine Anfrage an servicedesk geschrieben, bisher Schweigen.