Server-Probleme

[DragonGuard]

Kann es sein dass der / die Server von Stellwerksim langsam an ihre Grenzen kommen?
Nachmittags wird es zeitweise unspielbar, ladezeiten von 5 Minuten für Stellwerke, unterbrochene Datenabgleiche, Minutenlange Ladezeiten der Website sowie des Forums und Probleme beim Speichern würden zumindest dafür sprechen...

Gruß Henning

[js]

Dabei ist der Datentransfer gar nicht mal das Problem. Müßte man mal genauer analysieren, denn vor allem der Zug-Editor ist da eine Quelle für Leitungseinbußen.

[DragonGuard]

Mir erscheinen die Zugscripte ziemlich kompliziert in der Umsetzung. Denn viele Scripte laufen ja einfach den ganzen Tag lang durch, was natürlich rechenkapazität benötigt. Und auch eine Server-CPU ist irgendwann ja mal an der grenze angelangt. Frage nun, was tun. Entweder die Art und Weise,wie Züge erzeugt werden komplett umstellen, was aber sehr viel Zeit an Entwicklung und ähnlichem benötigt. Oder man begrenzt die laufzeit eines Templates auf 3 stunden ab Zuganfangsbahnhof auf 3 Stunden, sodass nach 3 Stunden das alte Template nicht mehr geladen sein muss, sondern ein neues in Kraft tritt. Dies ließe sich aber auch nicht überall realisieren, da die Simulation ja ständig größer wird und zusamemn wächst, wo mehrere Regionen übergreifend einen Zug fahren... Wie dies dort zu realisieren wäre, vermag ich nicht zu wissen.

MFG Henning

Ps: Wäre es nicht das einfachste ne 2. CPU einzubauen?

[js]

Nur zum Verständnis: Zugscript läuft nicht ständig, sondern nur 1x wenn man es als Editor startet.

Das System hat bereits eine Dual CPU drin.

[Moosmutzel]

Ich würde eher auf die Datenbank als Flaschenhals tippen Ein vServer hat eigentlich genug Hardwarekapazität. vServer haben eine garantiere Rechnenleistung die jeder abgebildete Server bekommt. Außerdem können zwischendurch zusätzliche Resourcen genutzt werden, wenn diese frei sind. Genauso werden diese aber wieder entzogen, wenn ein anderer Server sie braucht (und eine Garantie drauf hat). Ich schätze das könnte eine weitere Problemstelle sein. Man weiß ja nie, was die anderen User mit ihren Servern so machen...

[js]

Ich wollte mir die Tage mal einen 3-Tage-Testvserver nehmen und dort mal die Datenbank alleine laufen lassen. Mal sehn, ob das was bringt. Wichtig dabei ist vor allem, daß die Verbindung der beiden Systeme eine schnell ist.

[Moosmutzel]

Dann sollten die im gleichen RZ stehen und am Besten noch am gleichen Switch hängen.

[js]

Eben.

[js]

Das versteh ich nun auch nicht: die Last ist irre hoch, aber die Reaktionszeiten sind trotzdem super.

[js]

So, aktueller Stand: ich hab das Grafikzeugs mal auf einen 2. Server geschaltet. Außerdem läuft nun massives Monitoring der Datenbank. Das könnte diese zwar etwas bremsen, aber dafür sehe ich dann mal, wo es klemmt.

Die Grafiken waren da am einfachsten umzuziehen und es scheint durchaus was zu bringen.

[gelbhut]

So, aktueller Stand: ich hab das Grafikzeugs mal auf einen 2. Server geschaltet. Außerdem läuft nun massives Monitoring der Datenbank. Das könnte diese zwar etwas bremsen, aber dafür sehe ich dann mal, wo es klemmt.

Die Grafiken waren da am einfachsten umzuziehen und es scheint durchaus was zu bringen.

Zugscript Lauf um: 1:20, 5:40, 10:50, 14:20, 18:40, 22:50 Uhr finde ich nicht so toll. warum lagert Ihr den Zugscript nicht auf einen eigenen Server? So macht das keinen Spass. Wenn ich hier an einem Stellwerk arbeite will ich die Züge sfort Testen....

[js]

Wie soll man die Daten, die für die Simulation gebraucht werden zu deren Erzeugung auf einen anderen Server auslagern? Das geht nicht. Zu dem Thema wurde gestern eine Diskussion geführt und es wurde festgestellt, daß ZugScript nicht per Trial&Error erzeugt wird.