...ist ja zwei Jahre her. Hast du eine Lösung gefunden?
Hatte jetzt schon 2Mal das gleiche Problem. Das Seltsame ist, daß auf dem selben server noch drei andere CSS Server Problemlos laufen.
ich bekam foglende Meldung:
*** glibc detected *** free(): invalid pointer: 0xb7dc5000 ***
Habe einen Befehl gefunden der angeblich helfen soll:
export MALLOC_CHECK_=0
soll den pointer wieder freigeben, hat aber nicht funktioniert.
Musste in beiden Fällen CSS komplett neu installieren
Das er nur einen Kern nutzt ist mir klar, aber laut "stats" Abfrage müsste einer eigentlich reichen.
gerade eben zeigt er zB. folgendes an:
CPU In Out Uptime Users FPS Players
18.00 105593.21 178664.36 400 8 249.94 21
gestern mit 42 Playern war CPU auch nur, je nach Map, zwischen 30 u. 60.
Es läuft nur ein so großer Server darauf. Die anderen haben max 20 slots und waren zu dem Zeitpunkt auch komplett leer.
Könnte es nicht eher ein Problem mit der Anbindung sein?
Mir wurde gesagt, daß der Unterschied zwischen VServer u vollem Root nur 10 - 15% Leistung beträgt.
entschuldigt, diese oder ähnliche Fragen sind bestimmt schon mehrere hundert mal gestellt worden:
Wir haben einen Root Server: VServer, Xenon 5420, 4 GB RAM, debian etch 4.0 minimal. Unter anderem läuft ein CSS 42 Slot public Server darauf.
Wir hatten ihn jetzt länger auf Tick66 laufen, die perfomance war, sagen wir mal, akzeptabel, aber es kamen immer wieder Beschwerden, dass man schlecht trifft. Haben ihn daher jetzt mal auf Tick100 umgestellt. Wenn wenige (<30) Players drauf sind ist auch alles wunderbar. Aber darüber fallen die Server FPS teilweise unter 100. Bei D2 mit 42 playern hatten wir heute beim Rundenstart teiweise 35 FPS. Die CPU last liegt dennoch meist unter 50%, Speicher ist genug. Ist das schon die Grenze der Hardware oder wo könnte das Problem liegen?
Hier ein Auszug aus der Server.cfg:
ZitatAlles anzeigensv_downloadurl "xxx"
sv_allowupload "1"
sv_allowdownload "1"
mp_autoteambalance "1"
mp_flashlight "1"
mp_freezetime "3"
sv_pure "0"
sv_aim "0"
sv_cheats "0"
sv_logbans "1"
pausable "1"
sv_maxspeed "320"
mp_buytime "0.5"
mp_timelimit "20"
mp_friendlyfire "1"
mp_friendly_grenade_damage "1"
mp_lowlag "1"
mp_roundtime "3"
mp_c4timer "35"
mp_limitteams "1"
mp_autokick "0"
mp_chasecam "0"
mp_forcechasecam "1"
mp_logfile "0"
mp_logecho 0
mp_logdetail 3
mp_tkpunish "0"
mp_hostagepenalty "50"
decalfrequency 10
sv_send_resources "1"
sv_unlag "1"
sv_maxunlag "0.50"
sv_unlag_debug "0"
sv_unlag_fixstuck "0"
host_framerate "0"
sv_enableoldqueries "1"
sv_alltalk "0"
mp_forcecamera 1
net_maxfilesize 256
sv_maxrate 30000
sv_minrate 5000
sv_mincmdrate 40
sv_maxcmdrate 101
sv_minupdaterate 20
sv_maxupdaterate 101
sv_client_interpolate "1"
sv_client_max_interp_ratio "1.0"
sv_client_cmdrate_difference "40"
fps_max "300"
...bis zu 30 Playern schafft er auch einstellungsgemäß die 250FPS, darüber bricht es bei einigen Maps völlig ein. Außerdem geht der Choke dann enorm hoch (teilweise bis über 40).
Wäre sehr dankbar für irgendwelche konstruktive Vorschläge.
Ich habe das Problem jetzt soweit im Griff. Es ist allerdings etwas aufwendig. Aus mir unerfindlichen Gründen stimmt nach dem übertragen der *.bsp auf den Server die MD5Sum ab und an nicht mehr mit der Quelldatei überein (habe mehrere FTP Clients getestet). Da es in 8 von 10 Fällen funktioniert, überprüfe ich jetzt jede Datei nach dem übertragen und überschreibe sie gegebenenfalls. Es lag also nicht an bzip2 oder den Dateien auf dem Fastdownload - diese haben bisher auch immer gestimmt nach der Übertragung. Ich vermute bei unserem Root Server ist irgendwie das FTP-Protokoll "krank".
...auf jedenfall Danke für den Tip mit md5sum - das hat zu diesem Workaround geführt.
Bei einigen unserer Custommaps auf dem Server funktioniert der Download der Textures nicht (sofern sie externe *.vdf files haben), obwohl die Testuren auch in der selben Ornderstruktur auf dem Fastdownload liegen. Nun gibt es den Ordner Downloadlists auf dem Server. Dort ist mir aufgefallen, daß der Server zwar für jede gelaufene Map eine Datei anlegt, bei den fraglichen Maps aber keine zusätzlichen Dateien außer der *nav u *.bsp Datei eingetragen sind. Muss ich diese manuell ergänzen?
habe auch bei Google nichts konkretes gefunden - ist das Problem so selten?
Vielen Dank erst ma....
ich verzweifel bald:
jupp, nen root habe ich, habe sie aber noch nicht auf dem server entpackt. Aber ich denke an den gepackten liegt es nicht. Ich habe jetzt nochmal mit einer map alle mit md5sum verglichen - alle sind identisch, nur die vom client runtergeladene map ist unterschiedlich ?!?! - kann es nicht doch an der Version von bzip2 liegen? welche Version nutzt CS ?
hm, ich habe md5sum checks gemacht - u tatsächlich, obwohl die Größe identisch ist, stimmen die files auf gameserver u die heruntergeladene entpackte im Gameverzeichnis nicht überein. Da die selbe 'Datei gepackt u hochgeladen habe zu beiden Zielen, kann es sich eigentlich nur um ein Fehler bei der FTP-Übertragung handeln !?
Ich bin mir ganz sicher, das die maps auch gepackt auf dem http-Server liegen. Die alten ztmp Dateien habe ich bei der Umstellung definitiv alle gelöscht. Er läd die bz2 Dateien ja auch herunter, auf dem Client liegt dann auch die BSP mit zumindest der selben Byte größe wie auf dem Server - Das habe ich verglichen. Ich werde aber jetzt nochmal einen Check mit md5sum druchführen. Ich benutze zum packen eine win32 Version von bzip2 (ist ja ursprünglich ein Linux Programm) vielleicht liegt es auch daran - nur überprüfe ich die Archive immer, habe sie auch schon wieder entpackt u getestet. Die sv_downloadurl muss ja stimmen, da es bei einigen Maps funktioniert.
Werde nun nochmal mit md5sum vergleichen - ansonsten weiß ich echt nicht weiter...
Ich habe Fastdownload eingerichtet und bei den meisten Maps funktioniert es auch einwandfrei. Auf dem Downloadserver liegen die BSPs als *.bz2 (mit bzip2 gepackt). Nur bei einigen Maps wird beim connecten von den LEuten erst einmal die bz2 Datei heruntergeladen und das kommt die Fehlermeldung: your Map differs from Servers - Disconnect. - Das passiert bei Leuten die diese Map definitiv nicht schon in einer anderen Version drauf hatten (auch bei mir selbst, wenn ich die Map vorher rausgelöscht hatte). Außerdem ist mir aufgefallen, daß der Server immernoch *.ztmp Dateien im Maps Ordner erzeugt wenn Map Downloads stattfinden - Das brauch er doch nicht mehr zu tun bei Fastdownload, oder?
Hat jemand eine Idee - hab etliches probiert.
Bei unserem Root Server Anbieter haben wir die Möglichkeit unter etlichen verschiedenen Linux Distributionen auszuwählen. Welches würdet ihr empfehlen? Im Moment läuft er auf Debian 4.0 Etch minimal mit otimiertem 1000FPS Kernel. Gibt es da wesentliche Performance Unterschiede?
Wie sind eure Erfahrungen?
Vielen Dank schon mal... 
Haben Performance Probleme auf unserem Root Server. Nun haben wir im Moment einen DualCore, nächste Woche werden wir auf einen QuadCore mit fast der selben Taktung umgestellt. Jetzt habe ich gehört, daß CSS Server sowieso nur einen Core nutzt. Wir wollen aber unbedingt mehrere Server laufen haben, sonder einen 42 Slot der richtig gut rennt. Also bringt mir der QuadCore nu was oder nicht?
