Noch 3 Wochen bis 3.0...

[JackTF]

Ich sehe grundsätzlich kein Problem drin, RAM auszulasten. Je mehr im RAM ist, desto weniger muss von der Platte geladen werden. Das ist nicht zwingend ein Speicherleck! Ein Speicherleck definiert sich darüber, dass Daten im Speicher landen, die nie vom Programm entfernt werden können. Dadurch wird der Speicherverbrauch immer größer, bis die Grenze erreicht wird, die zum Absturz führt.

Mir ist letztendlich egal, wie es genannt wird. Es gibt diese Freezes. Die sind meiner Meinung nach ein K.O.-Kriterium für den GoLive. Denn diese treten bei allen regelmäßig auf.

[Starwolf]

Genau das passiert doch...RAM wird massiv belegt, es wird TROTZDEM geswappt, und wenn das Swapfile voll ist, folgt der Crash...

Also ich weiß nicht, wie Du das nennst, aber für mich ist das ein klassisches Speicher-Leck.

[JackTF]

So hast du es aber nicht beschrieben. Du hast sogar von unterschiedlichen Auslastungen je nach vorhandenem Arbeitsspeicher gesprochen. Ein Speicherleck definiert sich eben nicht durch eine Auslastung des RAMs, sondern durch ein stetig ansteigenden Speicherverbrauch während der Laufzeit. Du hast anfangs nur von einer Auslastung gesprochen. Und ich meinte dazu, dass das grundsätzlich ja kein Problem ist. Zum Problem wird es erst, wenn mehr Speicher benötigt wird als vorhanden ist, weil Speicherleichen nicht aufgeräumt werden können. Ich kann bisher nicht sagen, ob so ein Fall bei mir aufgetreten ist. Ich hatte bislang nur einen Crash und habe nicht darauf geachtet, ob die RAM-Auslastung dabei kurzzeitig auf 100% gestiegen ist. Bei 32-Bit-Prozessen muss nicht mal eine 100%-Auslastung vorliegen. Da reichen 2GB schon aus, weil dann der maximal zuweisbare Speicherplatz verbraucht ist (Stichwort Adressierung).

Linux arbeitet bspw. grundsätzlich so, dass der vorhandene Arbeitsspeicher ausgenutzt wird, um Festspeicherzugriffe zu reduzieren. Dennoch spricht da niemand von einem Speicherleck. Ich wollte nur festhalten, dass es eben ein Unterschied ist, ob ein Programm den vorhandenen Arbeitsspeicher ausnutzt oder ein Speicherleck hat.

[Speedtrip1]

naja 32bit ist glaube ich seit Windows7 tot also kein Thema mehr. Aber Jack hat grundsätzlich recht. Ein Thema mit dem ich als Programmierer auch täglich zu kämpfen habe, da diese Fehler häufig nicht leicht zu finden sind, gerade bei Multi Threading.

[JackTF]

Off-topic: 32 Bit ist sehr wohl immer noch ein Thema. MS Office muss man immer noch in der 32-Bit-Version installieren, wenn man in VBA Forms verwenden möchte. Die 32 Bit-Version wird - soweit ich mich recht erinnere - auch immer noch von Microsoft empfohlen.

Speicherlecks sind fies und gemein. Bei Multi-Threading habe ich bisher keine gehabt. Aber bei Proxies tritt er sehr schnell auf. Ich programmiere auf .NET. Und wenn man AppDomains erzeugt, erfolgt die Kommunikation zwischen diesen AppDomains immer über Proxies. Ich habe da anfangs den Fehler gemacht und Ereignisse verwendet. Diese kann man aber nicht mehr vollständig entfernen, da die Ereignisse auch über Proxies angebunden werden. Man entkoppelt also auf einer Seite, während die andere Seite angebunden - und somit eben auch im Speicher liegen - bleibt. Mit ereignislosen Delegaten ging es dann ohne Probleme. Aber auf die Lösung musste man erst mal kommen.

Ein Speicherleck ist meist ein konzeptionelles Problem. Das muss hier aber gar nicht zwingend vorliegen. Es kann auch einfach sein, dass hier zu viel in den RAM ausgelagert wird oder die Methoden nicht erkennen, dass der physikalische RAM voll ist und nun geswappt wird. Sobald ein Programm mehr RAM benötigt als physikalisch vorhanden ist, geht das auch in die Hose. Das muss aber nicht gleich ein Speicherleck sein. So, genug dazu.

Fakt ist: Starwolf und ich meinen das gleiche Verhalten. Ich unterstelle dabei jedoch nicht zu wissen, woran es genau liegt. Das überlasse ich den Entwicklern bei CIG. Und wir beide sind der gleichen Meinung, dass das definitiv ein Blocker ist.

[BelaOkuma]

Das Speicherlecks ist wohl schon beseitigt:

"...und durch die notwendige Behebung der jüngsten Speicherlecks)."

Quelle:

http://starcitizenbase.de/schedule-repo ... mber-2017/

[Starwolf]

Jein...also, nicht so richtig...

JA, es ist besser, der grundsätzliche Speicher-Bedarf ist schonmal deutlich geringer/"realistischer", ABER man kann immer noch zusehen, wie das Spiel anfängt, Speicher zu "fressen".

Eben eingelogt, direkt nach dem "Aufwachen" in Olisar: 7,9 GB
Okay, machbar...also bleiben wir einfach mal still stehen und warten, einfach nur stehen...hm...8,0...8,1....8,2...8,3...8,4...8,5 GB...
Es steigt deutlich langsamer und kontrollierter an, aber wächst und wächst, und wächst weiterhin...


Edit: Sie scheinen aber allgemein gerade was (an den Servern?) zu machen, ich fliege immer wieder mit Error "30007 Network connection error" aus dem Game...
Hm...theoretisch könnte es auch mit am Server hängen, es könnte sein, dass der Server zum Beispiel die ganze Zeit weitere "Objekte" an den Client streamt, obwohl diese einen selbst derzeit gar nicht betreffen, das würde z.B. auch dazu führen, dass der Speicher-Verbrauch dauernd steigt...

[JackTF]

Das Speicherlecks ist wohl schon beseitigt:

"...und durch die notwendige Behebung der jüngsten Speicherlecks)."

Quelle:

http://starcitizenbase.de/schedule-repo ... mber-2017/

Im Originaltext steht aber etwas von "memory corruption". Das ist ein großer Unterschied und auch ein großer Fehler in der Übersetzung. Eine Speicherverletzung tritt dann auf, wenn Speicher geändert wird, der nicht geändert werden darf (https://en.wikipedia.org/wiki/Memory_corruption). Ein Speicherleck dagegen tritt auf, wenn aufgrund Speicher, der nicht mehr benötigt wird, nicht freigegeben wird.

[Rixxis]

Also, wenn ich TS und SC offen habe dann geht mein Speicher bis 12-13GB. Es passiert dann aber immer wieder das die CPU bei sämtlichen Kernen auf 100% geht und das System stehen bleibt (auch TS). Der Speicher bleibt aber konstant und geht nicht bis auf das Maximum.

[KeinEngel]

Also, wenn ich TS und SC offen habe dann geht mein Speicher bis 12-13GB. Es passiert dann aber immer wieder das die CPU bei sämtlichen Kernen auf 100% geht und das System stehen bleibt (auch TS). Der Speicher bleibt aber konstant und geht nicht bis auf das Maximum.

Kann ich genau so bestätigen

Gesendet von meinem FEVER mit Tapatalk

[JackTF]

Neuer Patch ist raus: https://robertsspaceindustries.com/spec ... ild-status

Damit sind die CPU-Spikes bestätigt, aber noch nicht behoben.

[JackTF]

Und hier die Patch Notes: https://www.reddit.com/r/starcitizen/co ... 8_is_live/

[BelaOkuma]

...Damit sind die CPU-Spikes bestätigt, aber noch nicht behoben.

Man soll sie aber drastisch reduzieren können, hab es aber nicht nicht probiert:

https://robertsspaceindustries.com/spec ... lag-spikes

[Speedtrip1]

guter Tip werde ich bei Gelegenheit testen

[Speedtrip1]

brachte nichts, immer noch die Hänger, habe es aber trotzdem nach Levski geschafft ... schööön und dann Code 10002 ... tja wie gewonnen so zeronnen ;(