Die ungeklärte Forumsfrage würde mich allerdings auch interessieren.
Vielleicht kann Bloodyrain ja mal Stellung nehmen.
Des Weiteren habe ich mir heute den Client heruntergeladen und musste leider feststellen, dass Flyff sich kurz nach dem Starten schließt... hängt dies mit dem Forum zusammen? Irgendwelche Ideen?
Wenn ja, dann könnte eventuell folgende Erkenntnis helfen:
Da ihr meine Homepage nutzt, an der es vermeintlich liegt, frage ich: Nutzt ihr das "Hardcore/PVP/Normal"-System?
Mir wurde nämlich übereinstimmend berichtet, dass dieses System unabhängig von der Homepage bereits ab 7 Spielern extrem viele derartige Fehler hervorruft, SapphireFlyff nutzte das ebenfalls. Deswegen liegt die Vermutung nahe, dass das dran schuld ist und nicht (allein) die Homepage (wenn dem so wäre, wäre eine Entschuldigung einer gewissen Person fällig - wobei, das würde Aufrichtigkeit erfordern, die ich traurigerweise nicht erwarten kann).
Wenn ja, dann könnte eventuell folgende Erkenntnis helfen:
Da ihr meine Homepage nutzt, an der es vermeintlich liegt, frage ich: Nutzt ihr das "Hardcore/PVP/Normal"-System?
Mir wurde nämlich übereinstimmend berichtet, dass dieses System unabhängig von der Homepage bereits ab 7 Spielern extrem viele derartige Fehler hervorruft, SapphireFlyff nutzte das ebenfalls. Deswegen liegt die Vermutung nahe, dass das dran schuld ist und nicht (allein) die Homepage (wenn dem so wäre, wäre eine Entschuldigung einer gewissen Person fällig - wobei, das würde Aufrichtigkeit erfordern, die ich traurigerweise nicht erwarten kann).
Da kann ich dir gerade sagen, das, dass nicht stimmt mit dem Hardcore System.
Summer Paradise hat einen Userpeak von 190, fast 200, und hat keinen einzigen Deadlock.
Die haben alle Systeme die ich besitze.
Der Code kann diese Deadlocks garnicht hervorrufen, da dieses System mit allen gleichen Funktionen wie der normale Source arbeitet.
@ Final Core
Man hört garnichts mehr von FC was da los?
XxBlubbs das ist auch meine vermutung ich habs mal getestet und es crasht nur mit dem System .. ohne dem System entstehen vieeeel weniger Deadlocks.
Sag mal, seit wann crasht den der Server wenn er Deadlocks hat?
Ich dachte immer Deadlocks wären massive Speicherprobleme.
Korrigiert mich bitte, wenn ich falsch liege.
Sag mal, seit wann crasht den der Server wenn er Deadlocks hat?
Ich dachte immer Deadlocks wären massive Speicherprobleme.
Korrigiert mich bitte, wenn ich falsch liege.
Deadlocks sind "Hänger", die entstehen, wenn 2 Prozesse (das können 2 Programme oder 2 Instanzen eines Programmes sein) auf ein Datenbankobjekt zugreifen wollen - also einer Prozedur, Table, View, Function, etc...
Ist ein Deadlock in einem Node (Knotenpunkte in der Programmstruktur) vorhanden, wird ein "Victim" (also Opfer) des Deadlocks ausgesucht.
Das hängt davon ab, welche Priorität die Objekte haben - das mit der niedrigeren Priorität wird "gedropt" - also fallen gelassen, bzw zurückgesetzt und die Query wird nicht ausgeführt. Haben beide Objekte dieselbe Priorität, entscheidet SQL Server nach Speicherbedarf - der geringere hat Vorrang.
Man kann die Prioritäten in den Prozeduren einstellen (SET DEADLOCK_PRIORITY). Hilft das nicht, sollte man sich mit nem Profiler die Deadlocks genauer anschauen - dafür sind SQL Kenntnisse zwingend von Nöten.
Um es mal so zu sagen - ich weiß nicht, was dieses Hardcore/XXX/XXX System ist - SQL Server ist verdammt leistungsfähig, Deadlocks entstehen nur bei schlampigem Code. Wobei selbst bei schlechtem Code noch Deadlocks verhindert werden können. Aber spätestens bei mehreren Spielern sollte man darüber nachdenken, wie man Statistiken z.B. auf Homepages verwendet.
Und eins kann ich sagen: Die Queries direkt von der Homepage laufen zu lassen, das kann man direkt mit "das eigene Grab schaufeln" vergleichen. Am besten man baut sich eine Statistik-DB, die nur alle 10 Minuten (nur als Beispiel) aktualisiert wird - die Homepage nimmt sich dann die Infos von hier.
Das ist wesentlich weniger schädlich für den laufenden Serverbetrieb und der Offi macht das mit den Rankings im Übrigen genauso (zudem verwenden die Prozeduren und nicht direkte Queries). ;-)
Deadlocks sind "Hänger", die entstehen, wenn 2 Prozesse (das können 2 Programme oder 2 Instanzen eines Programmes sein) auf ein Datenbankobjekt zugreifen wollen - also einer Prozedur, Table, View, Function, etc...
Ist ein Deadlock in einem Node (Knotenpunkte in der Programmstruktur) vorhanden, wird ein "Victim" (also Opfer) des Deadlocks ausgesucht.
Das hängt davon ab, welche Priorität die Objekte haben - das mit der niedrigeren Priorität wird "gedropt" - also fallen gelassen, bzw zurückgesetzt und die Query wird nicht ausgeführt. Haben beide Objekte dieselbe Priorität, entscheidet SQL Server nach Speicherbedarf - der geringere hat Vorrang.
Man kann die Prioritäten in den Prozeduren einstellen (SET DEADLOCK_PRIORITY). Hilft das nicht, sollte man sich mit nem Profiler die Deadlocks genauer anschauen - dafür sind SQL Kenntnisse zwingend von Nöten.
Um es mal so zu sagen - ich weiß nicht, was dieses Hardcore/XXX/XXX System ist - SQL Server ist verdammt leistungsfähig, Deadlocks entstehen nur bei schlampigem Code. Wobei selbst bei schlechtem Code noch Deadlocks verhindert werden können. Aber spätestens bei mehreren Spielern sollte man darüber nachdenken, wie man Statistiken z.B. auf Homepages verwendet.
Und eins kann ich sagen: Die Queries direkt von der Homepage laufen zu lassen, das kann man direkt mit "das eigene Grab schaufeln" vergleichen. Am besten man baut sich eine Statistik-DB, die nur alle 10 Minuten (nur als Beispiel) aktualisiert wird - die Homepage nimmt sich dann die Infos von hier.
Das ist wesentlich weniger schädlich für den laufenden Serverbetrieb und der Offi macht das mit den Rankings im Übrigen genauso (zudem verwenden die Prozeduren und nicht direkte Queries). ;-)
Das "Hardcore Sys", sendet eine Abfrage beim Join "Select m_nDiMode blabla.." ( genau wie wenn man sich einloggt, und der Name etc auch aus der Datenbank gelesen wird. ), und beim Character Create, "Update CHARACTER_DBF set m_nDiMode bla bla und so weiter.." ( genau so wie der Name, Job etc gespeichert wird. )
Und mehr hat das System nicht mit der Datenbank zutun :q
Mal davon abgesehn, hält es auf Summer Paradise konstant mit 200 User'n aus, ohne ein Deadlock.
Bei Sapphire und Final Core waren die Deadlocks nach einem User Peak von 100 schon vorhanden.
Vobei ich auch sagen muss, das Summer Paradise v14 ist.
Final Core | Highrate | Gw | V19 | ... 09/16/2012 - Flyff PServer Advertising - 115 Replies http://img5.fotos-hochladen.net/uploads/finalcorey pdr6ceg42.png
•Homepage | Forum | Client | Register•
• 122 Player Peak von 16.09.2012 •
• Teamspeak 3: 62.141.38.35 •
http://final-core.de:53080/status.php?cnt
Hallo liebe e*PvP-Community,
Ich möchte euch einen neuen Guildwar Server vorstellen.
Final Core | Highrate | Gw | V19 | ... 09/15/2012 - Flyff PServer Advertising - 1 Replies http://img5.fotos-hochladen.net/uploads/finalcorey pdr6ceg42.png
•Homepage | Forum | Client | Register•
• 74 Player Peak von 11.09.2012 •
• Teamspeak 3: 62.141.38.35 •
http://final-core.de/script.php
Hallo liebe e*PvP-Community,
Ich möchte euch einen neuen Guildwar Server vorstellen.
Final Core | Highrate | Gw | V19 | ... 07/25/2012 - Flyff PServer Advertising - 40 Replies http://img5.fotos-hochladen.net/uploads/finalcorey pdr6ceg42.png
•Homepage | Forum | Client | Register•
• 10 Player Peak von 22.07.2012 •
• Teamspeak 3: 62.141.38.41 •
Hallo liebe e*PvP-Community,
Ich möchte euch einen neuen Guildwar Server vorstellen.
Es befindet sich in OpenBeta-Phase