Definiere deine Ziele
Bevor Sie beginnen, sollten Sie sich bewusst sein, welche Ziele Sie erreichen möchten. Dieses Handbuch wurde in erster Linie entwickelt, um die bestmögliche Qualität eines Spieleservers zu optimieren. Dies erfordert, dass Sie die Anzahl der Server gering halten, dh nicht mehr als ein oder zwei Server pro CPU/Kern betreiben. Dennoch werden einige Hinweise für diejenigen gegeben, die so viele Server/Slots wie möglich auf ihrer gegebenen Hardware betreiben möchten.
Außerdem müssen Sie klarstellen, was einen guten Server für Sie ausmacht. Sicherlich sind möglichst hohe FPS nicht das richtige Kriterium. Wenn Sie hlds-Server betreiben, möchten Sie stabile 1000 fps erreichen - aber lassen Sie sich nicht täuschen: hlds zeigt beim stats-Befehl niemals Werte über 1000 fps an. Wenn Sie es also geschafft haben, perfekt konstante 1000fps zu haben, haben Sie in der Realität wahrscheinlich FPS etwas größer als 1000fps. Dadurch wird der Server nicht besser, im Gegenteil: er läuft (etwas) zu schnell. Wenn du manchmal FPS etwas unter 1000 hast, sind deine (echten) FPS wahrscheinlich so stabil wie früher, der Server läuft nicht mehr zu schnell und du hast immer noch ein perfektes "LAN-Feeling" oder was auch immer. Sie können den Befehl host_speeds verwenden, um die echten FPS zu erhalten (aber nur, wenn Sie ihn direkt an der Serverkonsole ausführen, nicht über RCON).
Wenn Sie (orangebox) srcds-Server betreiben, sind sogar 1000fps zu hoch (und jetzt hat Valve eine Art Limit auf 500fps eingeführt). Die Engine läuft am besten, wenn die FPS genau der Tickrate entsprechen (standardmäßig 66 und für CS:S nicht änderbar). Verwenden Sie keine etwas höheren FPS, da Ihr Server unter dem sogenannten Aliasing-Effekt leidet . Im Zweifelsfall etwas tiefer fahren. Wenn Ihre FPS nicht perfekt stabil sind, können "viel" höhere FPS helfen, den Aliasing-Effekt zu vermeiden. "Viel" bedeutet in diesem Fall etwa 300fps, nicht mehr! Höhere FPS verbrauchen nur zusätzliche Ressourcen und helfen nicht bei der Serverqualität. (Auf der anderen Seite schaden hohe FPS nicht wirklich, also weine nicht, wenn jemand noch mit 1000fps läuft. Aber das ist völlig unnötig!)
Die richtige Verteilung wählen
Es wird sehr kontrovers diskutiert, welche Distribution für Gameserver am besten funktioniert. Die meisten Linux-Distributionen basieren entweder auf Debian (zB Ubuntu) oder Red Hat (zB CentOS, Fedora). Obwohl die Leute mit allen Distributionen Erfolg hatten, scheint es, dass Debian-basierte Distributionen out-of-the-box besser funktionieren und daher weniger Aufwand erfordern. Wenn Sie sich noch nicht entschieden haben, welche Distribution Sie verwenden möchten, verwenden Sie die neueste Ubuntu-Desktop-Version.
Außerdem müssen Sie sich entscheiden, ob Sie 32 Bit oder 64 Bit verwenden möchten. Wenn Sie viel RAM verwenden möchten (das Limit beträgt normalerweise 3 GB für 32 Bit, da der Kernel etwas Adressraum reserviert), benötigen Sie ein 64-Bit-System. Bitte beachten Sie, dass selbst hartes 32-Bit-Linux auf mehr als 3 und 4 GB zugreifen kann. Wenn der Kernel richtig konfiguriert ist, wird dringend empfohlen, diese Funktion nicht für den Betrieb von Spieleservern zu verwenden, da der Zugriff auf den Speicher oberhalb der 3-GB-Grenze zusätzliche Zeit in Anspruch nimmt . Normalerweise laufen srcds-basierte Server auf jeden Fall besser auf 64 Bit. Nur für HLDs müssen Sie sich zwischen 32 und 64 Bit entscheiden. Es scheint immer noch gängige Praxis zu sein, 32 Bit für HLDs-basierte Server zu verwenden, aber die Unterschiede werden kleiner, sodass Sie wahrscheinlich auch mit 64 Bit ein sehr gutes Ergebnis erzielen werden.
Wenn Sie wissen möchten, ob Ihr installiertes System ein 32- oder 64-Bit-System ist, führen Sie Folgendes aus:
uname -m
Wenn es x86_64 druckt , ist Ihr System 64-Bit. Wenn es i686 (oder i586 oder sogar i486 für sehr alte Systeme) druckt , ist es 32 Bit. Dies bedeutet nicht, dass Ihre CPU nicht in der Lage ist, ein 64-Bit-System auszuführen. Alle modernen CPUs, die für das Hosten von Hochleistungs-Gameservern geeignet sind, unterstützen 64 Bit.
Vorbereitung des Systems
Abhängig von Ihrer Distribution müssen Sie zunächst einige Tools installieren. Bei den meisten Distributionen sollte die Installation der folgenden Pakete/Programme ausreichen (die tatsächlichen Paketnamen können je nach Distribution leicht abweichen):
- gcc (das ist der Compiler)
- make, gmake oder gnu-make (die gnu-Version des Dienstprogramms make)
- ncurses und ncurses-dev (das Entwicklungspaket für die ncurses-Bibliothek, genannt ncurses-devel auf CentOS, RHEL und Fedora, libncurses5-dev auf Debian und Ubuntu)
- chrt (Paket könnte schedutils oder schedtool heißen)
- zlib1g-dev (benötigt auf Debian und Ubuntu)
- Patch (muss für einige Debian-Benutzer manuell installiert werden)
- vixie-cron oder ein anderer Cron-Dämon
Eigenen Kernel bauen
Obwohl neuere Kernel bereits out-of-the-box eine gute Performance bieten, empfiehlt es sich dennoch, einen eigenen Kernel zu kompilieren, wenn man die maximal mögliche Performance erreichen möchte. Wenn Sie nicht wissen, welche Kernel-Version Sie haben, führen Sie Folgendes aus:
uname -r
Es wird etwa 2.6.35-24-generic ausgeben . Wenn Ihr Kernel 2.6.32 oder neuer ist (wie in diesem Beispiel), können Sie tatsächlich versuchen, Ihren aktuellen Kernel zu verwenden und danach immer noch Ihren eigenen Kernel bauen, wenn das Ergebnis nicht ausreicht. Für ältere Kernel wird dieser Schritt auf jeden Fall dringend empfohlen.
Da das Kompilieren eines Kernels recht komplex ist, wurde dieser Schritt in einem separaten Artikel, dem Linux Kernel Compilation Guide, zusammengefasst .
Einrichten Ihrer Server für den Betrieb mit Echtzeitplanung
Für maximale Leistung muss das Betriebssystem wissen, welche Prozesse zeitkritisch sind und welche nicht. Standardmäßig wird nicht jeder Prozess als zeitkritisch angesehen. Am einfachsten ist es, einen kleinen Cron-Job zu erstellen und ihn etwa alle 5 Minuten ausführen zu lassen. Fügen Sie zB in /usr/local/sbin/resched.sh Folgendes ein :
#!/bin/sh
PROCESS_NAMES="srcds_linux srcds_i686 srcds_i486 srcds_amd hlds_i686 hlds_i486 hlds_amd"
für Namen in $PROCESS_NAMES; tun
PIDS=`pidof $name`
für p in $PIDS; tun
chrt -f -p 98 $p
fertig
fertig
# Dies ist nur für die RT-Patches, es tut nichts auf anderen Kerneln
PIDS=`ps Axt | grep sirq-hrtimer | grep -v grep | sed -e "s/^ *//" -e "s/ .*$//"`
für p in $PIDS; tun
chrt -f -p 99 $p
fertig
PIDS=`ps Axt | grep sirq-timer | grep -v grep | sed -e "s/^ *//" -e "s/ .*$//"`
für p in $PIDS; tun
chrt -f -p 51 $p
fertig
die Datei ausführbar machen:
chmod 755 /usr/local/sbin/resched.sh
und lege es in /etc/crontab :
# mh dom mon dow Benutzerbefehl
[…]
*/5 * * * * root /usr/local/sbin/resched.sh > /dev/null 2>&1
Vergessen Sie nicht, Ihren Cron-Dämon neu zu starten, zB unter Debian:
/etc/init.d/cron neu starten
Hinweis: Die Verwendung von chrt zum direkten Starten der Server mit der richtigen Zeitplanung funktioniert für die orangebox nicht, daher wird diese generische Methode hier beschrieben.
Bindung von Prozessen an die CPU
In manchen Umgebungen kann es hilfreich sein, einen Server einer bestimmten CPU (bzw. Core) zuzuordnen. Dies kann mit dem Befehl taskset erfolgen, zB
Aufgabengruppe -c 0 ./srcds_run ...
Dadurch wird der Gameserver gezwungen, auf der ersten CPU zu laufen. Ersetzen Sie die 0 zB durch 1, um den Server auf der zweiten CPU zu betreiben (die CPU wird bei 0 gezählt).
Achtung, obwohl Sie den Server zwingen, auf einer bestimmten CPU zu laufen, hindern Sie andere Prozesse nicht daran, auf derselben CPU zu laufen. Aus diesem Grund verschlechtert dies wahrscheinlich den Server in den meisten Fällen. Wenn Sie den Server nicht an eine CPU binden, wählt der Kernel automatisch eine freie CPU aus, auf der der Server ausgeführt wird. Dies kann dazu führen, dass der Server zwischen den CPUs hin und her springt, aber normalerweise schadet dies nicht. Auf Systemen, bei denen der Cache nicht zwischen CPUs geteilt wird (zB AMD-CPUs und physisch getrennten CPUs) oder mit einer CPU-abhängigen Taktquelle (zB tsc, siehe unten, wie man sie ändert), kann dies helfen, die FPS zu stabilisieren.
Probiere es also aus, wenn du magst, aber damit solltest du nicht anfangen!
Beseitigen Sie kleine Variationen mit "Idler"
Bei einigen Installationen bleiben kleine FPS-Variationen, nachdem Sie diesem Wiki gefolgt sind. In diesem Fall kann es hilfreich sein, einen Prozess mit niedriger Priorität laufen zu lassen, der 100 % CPU beansprucht. Erstellen Sie eine Datei namens " ider.c", die die folgenden Zeilen enthält:
int main() {
während(1);
}
Kompilieren Sie dann dieses Programm mit dem folgenden Befehl:
gcc leerlauf.c -o leerlauf
Sie sollten das Programm mit niedriger Priorität ausführen, um eine Verlangsamung Ihres Systems zu vermeiden:
schön ./Leerlauf &
Das kaufmännische Und-Zeichen (&) führt den Idler im Hintergrund aus.
Selbst auf Systemen mit 2 oder mehr Kernen sollte nur ein Idler laufen (auch wenn Sie mehrere Gameserver betreiben).
Die Variationen sollten als Protokoll verschwinden, während der Idler läuft.
Auf einigen Systemen kann es erforderlich sein, auf jedem Kern einen Idler auszuführen, dh:
schönes Taskset -c 0 ./idler &
nice taskset -c 1 ./idler &
nice taskset -c 2 ./idler &
nice taskset -c 3 ./idler &
Hinweis: Dies kann funktionieren oder nicht. Probieren Sie es aus, wenn es die Situation für Sie verbessert. Wenn nicht, verwenden Sie die Spannrolle nicht. Es werden dann nur CPU-Ressourcen weggenommen.
Ändern der Taktquelle
Ein moderner PC verfügt über verschiedene Uhren, die er für das Timing von Gameservern (und allem anderen) verwenden kann. Normalerweise wird standardmäßig die TSC-Taktquelle verwendet, die sich in der CPU befindet. Diese Uhr könnte sehr gut sein, und sie könnte sehr schlecht sein. Es hängt stark von deiner CPU ab. Auf jeden Fall hat es den großen Vorteil, dass es schnell ist, da es direkt ausgelesen werden kann, ohne auf eine andere Hardware zugreifen zu müssen.
Wenn Sie mit der Stabilität Ihres FPS nicht zufrieden sind, können Sie versuchen, verschiedene Taktquellen zu verwenden, um ein besseres Ergebnis zu erzielen. Um alle verfügbaren Uhren Ihres Servers aufzulisten, führen Sie Folgendes aus:
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
Sie können dann einen der aufgelisteten Uhrennamen auswählen, z. B. "hpet", und mit diesem Befehl als Systemtaktquelle festlegen:
echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource
Ich empfehle, mit hpet zu beginnen, aber Sie können auch alle anderen aufgelisteten Taktquellen ausprobieren.
Fehlerbehebung / FAQ
- Für srcds: Überprüfen Sie, ob Sie fps_max 0 in Ihrer Konfiguration haben, wenn Sie 1000 fps haben möchten. Verwenden Sie stattdessen nicht fps_max 1000. Aber besser jetzt, benutze fps_max 66.66 um 66.66fps zu bekommen, da FPS jetzt der Tickrate entsprechen sollte (seit dem Orangebox-Update)!
- Auch für srcds: Laufen Sie nicht mit anderen Tickraten als 66, auch wenn Ihr Spiel dies unterstützt. CS:S (das neueste, das auf die Orangebox portiert wurde) tut dies nicht, und das hat seinen Grund. Höhere Tickraten werden Ihr Gameplay nicht verbessern, sondern verschlechtern. Leute, die es nach dem Orangebox-Update nie wirklich probiert haben!
- Für HLDs: Überprüfen Sie, ob Sie sys_ticrate > 1000 (zB 2500) in Ihrer Konfiguration haben. Überprüfen Sie auch, ob Sie mit -pingboost 2 oder 3 . arbeiten
- Auch für HDs: Achten Sie darauf, dass Ihre tatsächlichen FPS nicht höher als 1000 fps sind. stats zeigt Ihnen nie Werte über 1000 fps an, daher müssen Sie host_speeds (direkt an der Serverkonsole, nicht über rcon) verwenden, um die tatsächlichen FPS herauszufinden. FPS von mehr als 1000 beschleunigen Ihr Spiel. Aufgrund der Begrenzung der Statistiken werden sie den Server auch so aussehen lassen, als hätte er ultrastabile FPS, aber das ist eine Lüge. Kein Server kann absolut stabile FPS haben, kleine Abweichungen sind normal. Das Ausblenden dieser Variationen verbessert die Qualität nicht.
- Überprüfen Sie, ob Ihre Server (und auf RT-Kernels die sirq-hrtimer-Prozesse) wirklich das richtige Scheduling haben, indem Sie chrt -p <pid> ausführen
- Verwenden Sie niemals Bots zum Testen. Sie sind kein echter Test, Sie können in beide Richtungen sehr unterschiedliche Ergebnisse erzielen (sie verwenden nicht die Netto-Engine, sondern erhöhen die CPU-Last)!
- Das Erreichen von nur ~950 FPS statt 1000,0 ist kein Problem. Den Unterschied von 50 Mikrosekunden (0,05 Millisekunden!) kann wohl niemand bemerken.