Lieber Besucher, herzlich willkommen bei: sourceserver.info. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Canc3lL0g0ut« (7. Mai 2011, 11:52)
könnte am RAM liegen. wie ist die auslastung?
Zitat
Kann man da irgendwas machen, außer sich nen "richtigen" Root zulegen?
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Impact« (7. Mai 2011, 16:00)
kann ich dir sagen das über 85% der Personen die Gameserver auf einem Vserver betreiben ähnliche Probleme mit der Leistung haben.
Möglicherweise hat es in deinem Fall auch andere Zusammenhänge (Plugins, Mods bla bla)
Jedoch sollte man dazu sagen das auf manchen vServern man eben Gameserver hosten kann
und auf manchen nicht
Benutzerinformationen überspringen
Administrator
Wohnort: Hagen
Beruf: Mechatroniker (didaktische Systeme)
Rootserver vorhanden: Nein
Also RAM - technisch gesehen haben wir 512 MB zur Verfügung. Frei davon sind 9 MB, gepuffert sind 12 MB und gecached sind ca. 200 MB - RAM würde ich persönlich ausschliessen.
Was ist das HostOS und welches OS hat die VM? Als Gast würde ich generell Linux bevorzugen. Schont die Ressourcen.
Mit dem prozessor und mit XEN "sollte" es bei 20 spielern eigentlich keine probleme geben. was für ein kernel läuft denn auf dem gast?
Ist es denn so unwahrscheinlich, das mit den aktiven Slots auch der Verbrauch steigt? Schau einfach mal auf die Konsole, wie es mit dem Ram aussieht, wenn die Slotzahl erreicht wird, bei der es anfängt zu droppen.
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Canc3lL0g0ut« (8. Mai 2011, 19:51)
Der ist meistens rappelvoll , wenn ein großes Update rauskommt, da Cancel unsern Server immer relativ zügig wieder zum Laufen bekommtCancelL0g0ut:
... "Unserer kanns, aber eben nur bis zu einem Gewissen Maße ... Wichtig ist das es sonst Lagfrei läuft - und wann haben wir schonmal alle Slots belgt ... ist eher ma ne Ausnahme ... "
Benutzerinformationen überspringen
Meister
Wohnort: Schwelm
Beruf: Immobilien-Verwalter / Serveradministrator
Rootserver vorhanden: Nein
Benutzerinformationen überspringen
Administrator
Wohnort: Hagen
Beruf: Mechatroniker (didaktische Systeme)
Rootserver vorhanden: Nein
Das Host OS ist CentOS in er aktuellsten Version. Das wurde deswegen gemacht - so wurde es mir gesagt - weil CentOS nen aktuelleren Kernel haben sollte und wohl auch der Hypervisor XEN ne neuere Version haben soll. Wir selbst setzen (noch) Debian 5 ein, würde aber gern auf Debian 6 aufrüsten. Problem ist hier, das bei der Grundinstallation schon 71 Tasks laufen, bei Debian 5 sinds nur 45. Und bei 512 MB RAM mach ich mir da Gedanken das es dann nicht mehr für unsere beiden GS reicht
was ist denn das für ein Xeon? das ist wirklich keine eindeutige cpu-angabe, alle Intel server cpus heißen Xeon seit fast 10 jahren oder so. gib mal den output von "cat /proc/cupinfo". plötzliche fps-einbrüche ab eine gewissen player-zahl sind ein klares indiz für eine zu langsame cpu. dagegen bist du dann einfach machtlos.
die virtualisierung wird euch vielleicht nie auch nur annähernd 100% CPU power zuweisen, sondern vielleicht eher nur 30%. das hängt sehr von den einstellungen eures providers ab. ihr habt schon großes glück, dass es überhaupt halbwegs läuft. i.d.R. hat man eher lags selbst bei leerem server, weil einfach die cpu-zuweisung auf 1/10s-basis passiert...
die cpu an sich sollte ohne virtualisierung jedenfalls bequem ausreichen.
Quellcode |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
// Minimale Bandbreite 0=unlimited sv_minrate "15000" // Maximale Bandbreite 0=unlimited sv_maxrate "100000" // Minimum Updates pro Sekunde zum Client 66 ist Maximum sv_minupdaterate "40" // Maximum Updates pro Sekunde zum Client 66 ist Maximum sv_maxupdaterate "66" // Minimum Updates vom Client pro Sekunde 66 ist Maximum sv_mincmdrate "40" // Maximum Updates vom Client pro Sekunde 66 ist Maximum sv_maxcmdrate "66" // maximaler Unterschied zwischen cmd und updaterate sv_client_cmdrate_difference "30" // Minimaler Wert von cl_interp_ratio sv_client_min_interp_ratio "0" // Maximaler Wert von cl_interp_ratio sv_client_max_interp_ratio "1" |
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Canc3lL0g0ut« (26. Mai 2011, 11:38) aus folgendem Grund: Informationen hinzugefügt