Leistungsabfall in Build 143

Bei der Durchführung von Monte-Carlo- oder Walk-Forward-Matrix-Simulationen auf Version 143 ist im Vergleich zu Version 142 eine deutliche Leistungsverschlechterung (mit kontinuierlich steigendem Speicherverbrauch) festzustellen. Darüber hinaus stürzt die Version 143 häufig mit "Out-of-Memory"-Fehlern ab. SQX begrenzt den Arbeitsspeicher immer auf 8 GB, aber selbst wenn man ihn erhöht, stürzt die Anwendung immer noch ab.

Mein PC ist ein AMD Ryzen 9 5900X mit 32 GB RAM. Ich habe es sowohl mit GraalVM als auch mit Azul Java getestet, mit dem gleichen Verhalten.

Ist dieses Problem noch jemandem aufgefallen?

Ich bin wieder zur Version 142 zurückgekehrt, da die Version 143 derzeit nicht zu gebrauchen ist.

Die neue Version ist wirklich enttäuschend. Ich habe auch das gleiche Problem. Ich habe einen leistungsstarken PC und dennoch verlangsamt sich das Spiel bei den letzten Strategien während des erneuten Tests mit wenig RAM-Nutzung erheblich, was frustrierend ist

Lorena, können Sie Ihre Builder-Konfiguration und auch einen Screenshot mit CPU/Speicher-Einstellungen teilen? Ich werde dies in beiden Versionen testen

Sie können an unsere E-Mail senden [email protected]

Ich denke - ich habe das gleiche Problem. Ich habe 256GiG Ram frei, um 248Gig und 64 CPUs zu verwenden. Ich installierte in ein neues Verzeichnis und kopierte über

In 142 ist der Speicher schleichend angestiegen, in 143 ist er gefühlt ziemlich schnell erschöpft.

Ja, bei mir ist es genauso.

Wenn ich SQx den RAM-Verbrauch bestimmen lasse, bricht es immer wieder wegen des 85%-Verbrauchsspeichers ab, ich werde vielleicht auf 142 zurückgehen, wie Sie vorschlagen, da die IA des AlgoWizard für mich völlig nutzlos ist.

Ich werde noch einen Versuch mit einem benutzerdefinierten Project machen und Ihnen dann Bescheid geben.

Außerdem führe ich nur eine Aufgabe auf 143 aus, während ich früher ohne Probleme einen Erbauer und einen Nachprüfer auf 142 laufen hatte.

Hallo Leute, ich bin wieder auf 142 zurückgegangen, 143 war völlig instabil und stürzte ständig ab und fror ein.

Mal sehen, ob mein Arbeitsablauf in 142 besser ist.

yo probe en 143 y tuve que volver al 142. Un trabajo para que el constructor del 142 procesaba 100.000 algoritmos por hora , el 143 procesaba la mitad o la terte parte.

Das gleiche Problem hier, wir haben an den Support geschrieben, aber das gleiche Problem nach einigen Tests. wir versuchen, neu zu installieren

HI, und das Problem ist jetzt behoben? Haben Sie die Lösung gefunden?

Ich ging zurück zu 143, um einige Tests zu machen und blieb hier, ich ließ gerade den Müllsammler zu den Java-Entscheidungen, machen eine 30 Minuten sammelnden Müll und reduzierte die ram und Kerne auf die 1/2 meiner verfügbaren, und es funktioniert gut

Estou na versão 143 brasileira, e coloquei os erros em anexo, não consigo resolver isso.
NETCUP Server mit 20 Kernen, 64 GB Speicher und 3 TB Speicherplatz. Não consigo rodar mais de 2 horas ele já trava. In vielen Fällen hat er nur ein paar Stunden gearbeitet, ohne ein Projekt oder einen Test zu machen.

Hallo zusammen,

Ich möchte auf die Leistungsprobleme eingehen, die bei Build 143 aufgetreten sind.

In dieser Version gibt es keine absichtlichen Änderungen an der Kern-Engine, und nach internen Vergleichen zwischen Build 142 und 143 haben wir unter kontrollierten Bedingungen keinen messbaren Unterschied in der Engine-Leistung festgestellt. Da StrategyQuant X jedoch auf Java basiert, kann die Leistung je nach Hardware, Betriebssystem und Java-Distribution erheblich variieren - Faktoren, die außerhalb unserer Kontrolle liegen.

Nach der Untersuchung von Berichten betroffener Benutzer habe ich festgestellt, dass die meisten Probleme durch Befolgung dieser Konfigurationsrichtlinien behoben werden können:

Java und GC:

• Lösen Sie die Garbage Collection (GC) nicht manuell aus. Java verwaltet diese automatisch; sie zu erzwingen, kann die Leistung beeinträchtigen. Ziehen Sie die manuelle GC nur dann in Betracht, wenn Sie Out-of-Memory-Fehler feststellen.
• Verwenden Sie den G1 Garbage Collector, wenn Sie mit größeren Heap-Zuweisungen arbeiten.
• Für High-End-Maschinen wird GraalVM + G1GC für beste Leistung und Stabilität empfohlen.
• Testen Sie mehrere Java-Distributionen und vergleichen Sie die Ergebnisse mit Ihrer spezifischen Konfiguration. Laden Sie einfach die Java-Distribution aus den offiziellen Quellen herunter, entpacken Sie sie, und ersetzen Sie die /j64 Ordner in Ihrer StrategyQuant-Installation mit der heruntergeladenen Version.

Daten und Speicher:

• Vermeiden Sie die Speicherung einer großen Anzahl von Strategien in SQX-Datenbanken. Diese werden ständig im Heap-Speicher (RAM) gehalten und verbrauchen Ressourcen, auch wenn sie nicht benutzt werden. Speichern Sie Strategien extern und laden Sie sie nur bei Bedarf.
• Das Gleiche gilt für Monte-Carlo- und Walk-Forward-Simulationsergebnisse - halten Sie die Datenbanken schlank.
• Setzen Sie den maximalen Heap-Speicher (SQX zugewiesener RAM-Speicher) auf etwa 80% Ihres gesamten RAM-Speichers. Dies gibt SQX genügend Speicher, um damit zu arbeiten, und lässt gleichzeitig Spielraum für das Betriebssystem und Hintergrundprozesse.

System:

• Begrenzen Sie Hintergrundprozesse während der Ausführung von SQX.
• Passen Sie die Anzahl der SQX-Threads an die Anzahl der physischen CPU-Kerne (nicht der logischen/hyperthreaded Kerne) an.
• Abgesehen von den obigen Empfehlungen sollten Sie keine Änderungen an der SQX-Konfiguration oder an Java-Flags vornehmen, es sei denn, Sie haben einen konkreten Grund dafür und kennen die Auswirkungen.

Mit diesen Schritten konnten wir die meisten Performance-Probleme lösen - und in den meisten Fällen lag die Ursache nicht bei SQX selbst.

Wenn Sie nach diesen Schritten immer noch Probleme haben, wenden Sie sich bitte an unsere Support-E-Mail.

Wir helfen Ihnen gerne

Mit freundlichen Grüßen,

Petr
SQX Technische Unterstützung

Lieber Petr,

Nochmals vielen Dank für Ihre Unterstützung, jetzt funktioniert unsere 143 Ultimate perfekt!!!

Mit freundlichen Grüßen

Interessant ist, dass es in kontrollierten Tests keinen wirklichen Unterschied zwischen 142 und 143 gibt, aber in tatsächlichen Projekten scheint alles stark von der Konfiguration und der Arbeitslast abzuhängen. Das zeigt wirklich, wie wichtig die richtige Optimierung der Umgebung ist.