|
|
|
|
|
|
|
jo, wurde wieder auf "major outage" hochgestuft. Denen fliegt grad die gesamte DB um die Ohren.
Im PTU warens wohl meist nur um die 900 User, hier waren 10.000 on plus die, die nicht reinkamen. So geil skaliert das PES-System wohl nicht... wundert eigentlich niemanden, der viel. mit verteilten Datenbanken macht.
|
|
|
|
|
|
|
|
|
|
|
|
Also klingt als müsste man die Architektur nochmal überdenken und es dauert noch ein halbes Jahr ;D
|
|
|
|
|
|
|
|
|
|
|
Wie kann das passieren. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [WHE]MadMax
jo, wurde wieder auf "major outage" hochgestuft. Denen fliegt grad die gesamte DB um die Ohren.
Im PTU warens wohl meist nur um die 900 User, hier waren 10.000 on plus die, die nicht reinkamen. So geil skaliert das PES-System wohl nicht... wundert eigentlich niemanden, der viel. mit verteilten Datenbanken macht.
| |
Wobei GDB Handler sollten doch gerade da ihre Stärken haben oder nicht?
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von NTGhost
| | Zitat von [WHE]MadMax
jo, wurde wieder auf "major outage" hochgestuft. Denen fliegt grad die gesamte DB um die Ohren.
Im PTU warens wohl meist nur um die 900 User, hier waren 10.000 on plus die, die nicht reinkamen. So geil skaliert das PES-System wohl nicht... wundert eigentlich niemanden, der viel. mit verteilten Datenbanken macht.
| |
Wobei GDB Handler sollten doch gerade da ihre Stärken haben oder nicht?
| |
Jaein, ich glaub die haben schlicht die Datenmengen unterschätzt. Gibt ja Leute die 30 Seiten oder mehr an Inventar haben, wenn die sich das erste Mal einloggen wird der ganze Scheiss erstmal in die DB übertragen. Wenn das jetzt tausende auf einmal machen, und dann zumindest beim Logout immer der aktuelle Stand aller Infos über den Char, was er hat, was er wo gebunkert hat usw... sauber mit der zentalen DB abgeglichen sein muss, dann sind das nicht zu unterschätzende iops.
Und scheinbar wird ja ALLES aus der PES-DB abgerufen, auch so Kram wie Positionen von Aufzügen, Missionsstatus usw... weshalb ja am Anfang auch noch alles ging, nur teils mit 10-15min Verzögerung, wenn die ausstehenden Logs halt in die DB nachgeschrieben wurden.
Irgendwann wurde das Log an unerledigten Transaktionen aber zu groß, vor allem weil Leute dauernd ihren Char resetten wollten, weil das ja auf einige n Seiten als Login-Hilfe gepriesen wurde... und weil das gegen den Verlust von Pledge-Items half.
Ich hab den Eindruck, dass das AWS-Backend für richtig große DB-Operationen die auch schnell ausgeführt und repliziert werden müssen, nicht unbedingt geeignet ist.
|
|
|
|
|
|
|
|
|
|
|
Warum hat man das Spiel nicht für 7 Tage lahmgelegt und die Datenbank so migriert?
Oder halt einen Wipe machen und gucken wie es sicht entwickelt.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Bregor am 13.03.2023 22:59]
|
|
|
|
|
|
|
|
|
Ich frag mich die ganze Zeit wie sie es vorher gemacht haben. ich denke das die NO SQL DB vorher einfach ne Riesen queue hatte die das Abfangen konnte.
Was mir mit der GDB aufgefallen ist zu füher:
Früher™ hast du die Aktion anfangen und abschließen können, mit dem hohen Risiko das die Aktion verworfen wurde, du konntest aber zumindest weitermachen.
Heute habe ich das Gefühl das der GDB Handler das DIREKT in die DGS GDB schreibt. Und sobald du nun irgendwas machtst das auf die separate Masterkopie zugreifen will oder irgendwas das nicht stumpf DGS <-> Client ist, passiert gar nichts mehr weil der Servies dafür am sterben ist.
Was mir über Graphen erzählt wurde ist das du anders als bei "normalen" Datenbanken, nicht mehr Entrys schreiben und verifizieren mußt, sondern einfach nur noch das entsprechende Borderflag umschreibst, den Rest aber nicht anfaßt solange du den zustand der Entität nicht änderst. Das sollte eigentlich in einem MASSIVEN Drop der Schreib und lese zugriffe resultieren. und im PTU hat das ja auch wunderbar funktioniert.
Mein Eindruck ist mehr das der Graphen interpreter mist macht und beim versuch die alten SQL DB einträge der Weibseite in Graphen einträge im Spiel um zu wandern (entitlement processing) massiv verkackt. Das hat imho nichts mit der Rechenleister der Server zu tun sondern damit das irgendwer mit der flachen Hand programmiert und sich nicht an naming Standards hält was zu massiven Fehlern beim Interpreter und deren Stall führt.
/¤: Das kann son Scheiß sein die ne Orientierung in Grad:
0 bis 359 So n anderer macht aber jetzt 1 bis 360 oder noch besser 0-360.
Interpreter sieht nur item x Orientierung 360.
ein zweiter Interpreter hat aber keine 360 sondern 0 an dessen stelle. sieht also ne differenz und will ne kopie machen, dublettenchcker gibt alarm und hält die Aktion an. der erste interpreter besteht aber auf die 360 weil das ist was er bekommem hat und er keinen Werte validierung hat (360 wird zu 0) zack Stall.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von NTGhost am 13.03.2023 23:10]
|
|
|
|
|
|
|
|
|
| | Zitat von Bregor
Warum hat man das Spiel nicht für 7 Tage lahmgelegt und die Datenbank so migriert?
Oder halt einen Wipe machen und gucken wie es sicht entwickelt.
| |
Weiß keiner ich mein, Graphen sind frickelscheiß aber warum man dann unbedingt noch ne konverter LIVE laufen lassen muss bei so viel freigeister rei der Programmierer weiß ich auch nicht.
|
|
|
|
|
|
|
|
|
|
|
Was ich nicht in meinen Kopf reinbekomme.
Wie die das machen wollen, das alles, wirklich alles im Universum existiert bleibt. Jede fucking leergetrunkene Getränkedose bleibt erhalten. Bleibt auch jedes explodiertres Schiff und jede nicht abgelieferte Box erhalten?
Das schreit doch nach überfüllter, immer langsamer werdenden Datenbanken.
E: von Schiffwracks in Hangars will ich nicht Mal denken.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von pesto am 14.03.2023 0:02]
|
|
|
|
|
|
|
|
|
| | Zitat von pesto
Was ich nicht in meinen Kopf reinbekomme.
Wie die das machen wollen, das alles, wirklich alles im Universum existiert bleibt. Jede fucking leergetrunkene Getränkedose bleibt erhalten. Bleibt auch jedes explodiertres Schiff und jede nicht abgelieferte Box erhalten?
Das schreit doch nach überfüllter, immer langsamer werdenden Datenbanken.
E: von Schiffwracks in Hangars will ich nicht Mal denken.
| |
Mit Graphen geht das.
Uff wenn ich blos den alten Hellion Staion Builder wiederfinden könnte. der hat auch mit nem Graphen funktioniert da konnte man das wunderbar zeigen was ein Graph ist.
okay lass das mal so probieren:
du ordnest einem Objekt eine Zahl zu:
(Die Größe der Nummer ist immer festgelegt, NICHTS an der ganze Zahl ist zufällig)
"1234" = Schiff x
"0100" = Schranknummer 1 Zustand leer (00)
"111" = Dein Bounty Hunter Anzug
"666" = Deine Waffe
"66" = Ammo magazin deiner Waffe (66 Schuß)
Eine Waffe wird nun mit der Leadnummer dargestellt danach folgt die Munition und anzahl der Patronen im Magazin und dann eventuelle Anbauten es sind keine Anbauten vorhanden demnach werden alle diese Stellen mit 00 gefüllt Deine Waffe als Graph sieht dann so aus: (66666000000)
Dasselbe mit der Rüstung, deine Rüstung hat 5 Fächer deine Waffe ist im vierten Fach (1110000006666600000000)
Deine Rüstung ist im zweiten Schrank und die Waffe in der Rüstung
Für das Schiff existiert nun die Festgelegte Reihenfolge wie Sachen dargestellt werden:
"SchiffStorage01Storage02Storage03PositiondesSchiffesinXYZZustand"
123400111000000666660000000000010101001
Das ist nun das Schiff mit deiner Rüstung im zweiten Fach wo im vierten Fach dieser Rüstung deine Waffe mit 66 Schuß drinsteckt.
So weit so einfach. Nun beginnt der eigentlich Spaß...der Interpreter der die Sachen nun auseinander zuzeln muß und eventuell die Sachen woanders reinschrieben muß.
und ich hab selbst bei diesem kleinen Beispiel schon ineffiziente Scheiße gebaut. Den wenn du das richtig strukturierst musst du NUR EINE EINZIGE ZAHL ÄNDERN und die Waffe wandert von deiner Rüstung in deine Hand oder in Schiff Schrank Nummer drei.
Der Interpreter bekommt nun eine Einsprungsflag und fängt von dort an die Zahl einzulesen und zu interpretieren "1234" spawnt dir das Schiff an die Position die in der Nummer steht plus das ganze Geraffel das er in den Schränken findet.
die einzelne Zahl die ich genannt hatte nennt man "Border" frag mich nicht wie die genau strukturiert sein müssen damit das funktioniert. Das ist hier das maximale an Brainfuck das ich bereit bin zu ertragen zum Thema Graphen. Aber man kann durch das einzelne neuschreiben einer einzigen "border" ganze Sachen aus Schränken rausnehmen und reintun, zustände ändern etc. und die Clientseite den Rest der Physikarisierung machen lassen. Nun ballert man da noch nen Haufen an validierungen rein um Cheaten oder Unssiinigkeiten zu verhindern fertig ist deine Graphen Daten Bank...so und nun stell dir Vor das in den definitionslisten einer 0-360 schreibt und der interpreter aber nur 0-359 kennt...willkommen im 3.18 Patch 
Das ist mehr Mathe als ich bereit bin zu ertragen...
/¤²: Streng genommen ist eine Festplatte auch nichts weiter als ein großer Graph der auf eine Magnetscheibe geschrieben wurde und wo der Interpreter Hardgecoded im Controller sitzt und dem BIOS ne Teil Nummer durchschiebt. 386 ASM ist in der Beziehung einfacher weil die Strukturen festgelegt sind.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von NTGhost am 14.03.2023 0:58]
|
|
|
|
|
|
|
|
|
Ah, sowas hab ich damals in meiner Ausbildung in COBOL! gehabt.
Du legst im Prinzip über nen String eine Information was an welcher Position mit wie vielen stellen steht.
hat Vorteile mein ich wegen Schnelligkeit. Nur die Übersicht geht schnell verloren. Und es kann halt, wie du beschrieben hast, sehr schnell sehr viel Scheiße passieren.
Dennoch bleibt meiner Meinung nach sehr viel "Datenmüll und Objektmüll im PU" über.
Oder man guckt nach Objekten, die keinen "Nutzen mehr haben" und löscht diese.
Naja...werden die bei dem Bugdet und Entwicklungszeit bestimmt bedacht haben.
Grad reingeschaut. aufstehen in Orison (hab mich auf Port Olisar ausgeloggt) und Schiff im ASOP nicht verfügbar. aufm Nachbarbildschirm geguckt. irgendwas von "Request kann im Moment nicht ausgeführt werden" *auslogg und Statusseite weiter beobachten.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von pesto am 14.03.2023 7:29]
|
|
|
|
|
|
|
|
|
| | Zitat von pesto
Naja...werden die bei dem Bugdet und Entwicklungszeit bestimmt bedacht haben.
| |
|
|
|
|
|
|
|
|
|
|
|
@NTGhost: Sehr schön aufgedröselt 
Mein Gedanke geht dahin, dass auf dieses Konstrukt jetzt ja nicht nur ne handvoll Clients zugreifen, sondern eben zehntausende. Und entweder repliziert man die gesamte DB in Echtzeit, oder aber man macht z.B. solchen Kram wie gewisse Zugriffe priorisieren - z.B. könnte man wenn sich jemand ausloggt die States in ein Transaction log packen, was dann weggeschrieben wird, wenn grad Zeit dafür ist.
Nur ist bei der Last, die derzeit anliegt, halt nie Zeit...
Hab selbst das Problem gesehen was bei Datenbanken mit extrem langen Queries und Einträgen entstehen kann. Ging da konkret um nen Fall, wo jede Nacht mehrere TB an Daten verarbeitet werden mussten. Wir haben das Serversystem dafür von schnellen SAS-Platten auf SATA-SSDs umgebaut, einfach weil schon rein die iOPS von denen hier eine Rettung waren. Die Leistungssteigerung war zwar enorm (Zeitersparnis 12 Std->7Std), aber danach waren dann CPU (48 Kerne mit Hyperthreading also 96 virtuelle), und Ram (384GB) die Bottlenecks.
Dazu kommt dann ein Problem, was viele wohl unterschätzen: Client-Verbindungen und deren Latenz. Jeder Client hat ja ne unterschiedlich schnelle Anbindung an die Server, und der Server muss u.U. auf ne Antwort bei ner Datenübertragung warten. Das kann dann dazu führen, dass diese Wartefenster sich doof überlappen, und noch mehr "Lag" in das ganze Konstrukt eingeführt wird. Die Idee wäre ja jetzt Load Balancer vor das Ganze zu schalten, die die Client-Connects handlen, aber wie man damit das dann hinbekommt dass man noch immer eine konsistente DB ohne inhaltliche Fehler hat, ist mir ein Rätsel.
Auch eine gute Frage wäre: Nimmt der Server einfach das an, was ihm vom Client gemeldet wird? Wo werden Sachen wie z.B. Erlöse aus Transaktionen berechnet und gehandhabt?
Weil sonst könnte der Client ja einfach behaupten: Ey, der Verkauf grad hat mir 200 Millionen UEC gebracht, und der Server sagt: Jo, ich schreibs in die DB.
Siehe die Cheats, die derzeit im Umlauf sind, die Schiffs-Daten manipulieren, und so Teleports an beliebige Punkte ermöglichen, absurde Feuerraten mit Waffen, die sich nie entladen, oder Manöver mit 50g.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von [WHE]MadMax am 14.03.2023 9:13]
|
|
|
|
|
|
|
|
|
@Madmax:
Parallel Zugriff unpriorisiertzem Schreiben und beim Lesen einfach nen Snapshot dem Interpreter geben. Zumindest für die Master DB im Background sollte das funktionieren. Was im DGS passiert kann ich nicht sagen aber gegeben das da mehr und in Echtzeit passiert denke ich dass man da auch nicht mit queues arbeiten kann, deswegen hat man doch überhaupt auf GDB umgestellt.
Jo wenn jemand die Struktur entschlüsselt hat und nun weiß wie die Graphen aufgebaut sind und der Server, aus Last gründen, keine validieren vornimmt, yay mehr cheating. 
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von pesto
Ah, sowas hab ich damals in meiner Ausbildung in COBOL! gehabt.
Du legst im Prinzip über nen String eine Information was an welcher Position mit wie vielen stellen steht.
hat Vorteile mein ich wegen Schnelligkeit. Nur die Übersicht geht schnell verloren. Und es kann halt, wie du beschrieben hast, sehr schnell sehr viel Scheiße passieren.
Dennoch bleibt meiner Meinung nach sehr viel "Datenmüll und Objektmüll im PU" über.
Oder man guckt nach Objekten, die keinen "Nutzen mehr haben" und löscht diese.
Naja...werden die bei dem Bugdet und Entwicklungszeit bestimmt bedacht haben.
Grad reingeschaut. aufstehen in Orison (hab mich auf Port Olisar ausgeloggt) und Schiff im ASOP nicht verfügbar. aufm Nachbarbildschirm geguckt. irgendwas von "Request kann im Moment nicht ausgeführt werden" *auslogg und Statusseite weiter beobachten.
| |
genau so nur ist bei ner GDB das eben alles virtuell und du hast quasi keine Begrenzung wie du das bauen willst.
Und der Daten müll ist erstmal nur eine strukturierte Zahl Die tut nicht wirklich weh. wenn du dann noch für gewisse unwichtige Sachen ein pruning einführst kannst du die Zahl im Rahmen halten.
Das Pruning wird in zwei ebenen Stattfinden einmal schlicht stuff despawnen wie zb. leere Flaschen und Munitionsclips und zum anderen mit Quantas die zb Schiffswracks weg salvagen wenn keiner schaut.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Ich hab auch keine Schiffe. Aber ich kann mich auch nicht einloggen
|
|
|
|
|
|
|
|
|
|
|
Posten wir doch mal was sinnvolles für später...
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Noch_ein_Kamel
Ich hab auch keine Schiffe. Aber ich kann mich auch nicht einloggen
| |
japp..jetzt ist wohl wieder die verbindung zum account weg
egal.
e: aaaha!
| | The Live Service will be temporarily inaccessible while the team continues to isolate and fix issues. We currently do not intend to keep the environment completely inaccessible for any longer than is necessary but will provide additional updates here as they become available.
[2023-03-14 Updates]
1710 UTC - Maintenance in-progress. | |
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von pesto am 14.03.2023 18:42]
|
|
|
|
|
|
|
|
|
1855 UTC - Data collected, Maintenance complete.
Dafür kommt jetzt der nächste Fehler bei "Join PU" ...
|
|
|
|
|
|
|
|
|
|
|
sooo..pappa hat jetzt nen trick gemacht um sein schiff zu bekommen.
hat sich ne aurora gemietet und tadaa. nach ein paar sekunden war meine 315p im asop drin
jemand hat da wohl salvaging dran gemacht.
reparieren brauch ich aber nicht. :shrug:
e: ah Star Citizen...never change
"fix" ne Deliverymission mal testen. Die Kiste lag natürlich 9 m unterhalb der Erde. Zurück nach Port Olisar. alles voll mit Wracks ATC konnte man nicht anfunken. Bestimmt noch drölfzig tausend request, die vor mir abgearbeitet werden müssten. also impunded
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von pesto am 15.03.2023 8:32]
|
|
|
|
|
|
|
|
|
|
Ist Charakter Reset nicht mehr möglich? Das war doch immer bei den Einstellungen.
|
|
|
|
|
|
|
|
|
|
|
Einloggen klappt inzwischen, rumfliegen ist auch kein Problem.
Die Terminals dazu zu überreden ein Schiff rauszurücken braucht etwas Geduld.
Leider ist Mining noch kaputter als es in 3.17 war. Die Hälfte der Asteroiden lassen sich nicht scannen, wenn man mal welche findet die interessant sind stehen die Chancen hoch, das der Asteroid keine 0 Mass, 0 Instability, und keine Zusammensetzung hat. Man kriegt keine Charge-Leiste, er explodiert trotzdem wenn man ihn überlädt.Leider kann das Problem sogar bei den Brocken nach dem ersten splitten auftreten. D.h. gerade erstmal kein Mining.
Mal noch ein paar Tage warten
|
|
|
|
|
|
|
|
|
|
|
Gestern war schön. Erst n paar Missionen gemacht, dann bei einer n Schiff von meinem "Vorgänger" gefunden, komplett mit seiner Leiche mit seltener Rüstung und waffen. Gelootet, und dann die Mission gemacht, und dann 30K.
Nach dem Wiedereinstieg hatte ich den gelooteten Kram noch an, aber mein Schiff mit all dem Loot drin stand nicht mehr bei dem Missionsgebiet, das hat der Server nicht synchronisiert. War dann nochmal da, plötzlich spawnen Gegner ballern mich um - und dann nochmal 30K - also absolut alles bis auf Credits von dem Tag verloren, weil ich nach dem Wiedereinstieg keinen Leichenmarker hatte.
Aber egal. Lief flüssig, machte Spaß
|
|
|
|
|
|
|
|
|
|
|
Moment, haben die aktuell ne graphenDB die in realtime übers ganze Univesum gehen soll?
Sowas macht man doch skaliert.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Lunovis
Moment, haben die aktuell ne graphenDB die in realtime übers ganze Univesum gehen soll?
Sowas macht man doch skaliert.
| |
Sicher nicht übers ganze PU aber über gewisse Teile. Die Masterkopie läuft afaik seperat und die DGS Schicht zieht sich daraus die relevanten Teile und kreiert die jeweiligen Entity assets. Die DGS Schicht ist aber a.) viel zu klein skaliert (ich spekuliere hier wegen den Private Servern die CR immer noch versucht möglich zu machen) und b.) wahrscheinlich "Flachhandprogrammirung"
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von NTGhost am 17.03.2023 14:21]
|
|
|
|
|
|
|
|
|
Reicht nicht einfach eine DB pro System?
Durch die Jump-Points zwischen den Systemen gibt es doch quasi Ladescreens währenddessen die Items von einer DB in die andere migriert werden können
|
|
|
|
|
|
|
|
|
|
|
|
Warum nicht direkt pro Celestial Body oder so?
|
|
|
|
|
|
|
|
|
|
|
|
oh noez...suddely entitlement processing again.
|
|
|
|
|
|
|
|
|
|
|
Hatte heute mal wieder reingeguckt und an vielen Orten ausgezogene Leichen herumliegen gesehen, was hat es damit auf sich?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Klages am 17.03.2023 18:55]
|
|
|
|
|
|
| Thema: Star Citizen & Squadron 42 X ( Carrack Edition ) |
