Der optimale Gameroot und Gameserver Kernel

Einleitung

Dieses How To soll erklären, wie man seinen Rootserver zu einem Gameroot macht, der für den Betrieb von Gameservern optimieren ist. Nicht alles ist zwingend. Vieles sind Denkanstöße die man eventuell für sich anpassen muss. Das hier geschriebene wurde mit Linux Debian getestet, sollte aber auch 1:1 mit Ubuntu funktionieren. CentOS mit yum und Suse mit yast2 verwenden andere Paketmanager und die Pakete heißen etwas anders. Hier kann die passenden Namen mit Tante Google, oder dem search Befehl selber herausfinden


Hardware/Leistung bestimmen

Als erstes sollte man sich klar machen, wie viel Leistung und (virtuelle) Kerne man zur Verfügung hat. Diese kann man mit den dem Tool taskset einzelnen Prozessen zuweisen und damit die Prozesse einschränken. Verfügt die Intel CPU über Hyperthreading, wie z.B. bei einem Core i7, hat man doppelt so viele virtuelle Kerne, wie man physische verfügt.
Ruft man das Tool htop auf, kann man sehen, wie viele Kerne vorhanden sind. Falls es nicht verfügbar ist, sollte man es noch installieren

Auf meinem virtuellen Testserver mit drei Kernen sieht es dann so aus, wenn er unter Vollast steht:
htop


Prozesse limitieren

Es ist zwar nicht empfohlen, dass man Gameserver und Webspace auf der gleichen Maschine laufen lässt, für viele ist dies jedoch eine wirtschaftliche Notwendigkeit. In einem solchen Fall kann man die Web- und MySQL bzw. MariaDB Server sowohl in der Anzahl der erlaubten Kerne, als auch in der Priorisierung limitieren.
Gameserver mittels taskset auf einen Kern zu limitieren ist nicht immer förderlich, oft sogar kontraproduktiv.

Zum Einen werden wir mittels taskset die Server auf einen Kern limitieren, zum Anderen werden sie mit nice und ionice unterpriorisiert. Dabei ist zu beachten, dass taskset bei 0 mit dem Zählen beginnt. Man hat also bei vier verfügbaren Kernen die Kerne 0,1,2,3 zu vergeben.

Um einen Prozess mit niedrigster Priorität auf dem vierten Kern zu starten, stellt man Folgendes vor den eigentlichen Startbefehl

Wir bearbeiten nun die Startskripte im /etc/init.d/ Ordner und fügen den obigen Befehl ein. Bei MySQL bzw. MariaDB ist es das Skript /etc/init.d/mysql, in der man folgende Zeile

mit dieser austauschen muss

Das gleiche Vorgehen mit Apache2. Hier nennt sich das Startskript /etc/init.d/apache2 und die zu ändernde Zeile ist

Nach dem Editieren sollte sie so aussehen

Sobald man mit dem Editieren fertig ist startet man die Server neu

Nun kann man mittels ps die PIDs herausfinden

Und dann mit taskset überprüfen, ob die Änderungen erfolgreich waren. Die affinity list solte den Kernen entsprechen, die man in den Startskripten eingetragen hat.


Netzwerkbandbreite limitieren

Ein weiteres Problem kann die Bandbreite der Netzwerkkarte werden. Die meisten Rootserver verfügen über eine Anbindung von 100Mbit an das Internet. Wenn nun mehrere Leute auf den Seiten Surfen und ggf. auch noch ein Fast Download, oder ähnliches über den Webspace läuft, kann es vorkommen, dass mehr Netzwerkbandbreite angefragt wird, als dem Rootserver zur Verfügung steht.

Um diesen Konflikt von vornherein auszuschließen, kann man beim Apache2 Server die insgesamt zulässige Bandbreite mit dem Modul mod-bw limitieren. Das Modul muss erst installiert werden

Dann aktiviert man es

Als letztes geht man daran, die Bandbreite global zu limitieren. Dazu erstellt man die Datei /etc/apache2/conf.d/throttle-bandwidth und trägt Folgendes ein

Je nach Last können 1000kb und 500kb bereits zu viel sein. Hier gilt es, selber auszuprobieren und den passenden Wert zu finden.

Wenn man die Änderung vorgenommen hat, muss man die Config für den Apachen neu laden


Eigener Gameserver Kernel

Wer sich nicht zutraut, einen eigenen Kernel zu erstellen, der kann sich hier fertige downloaden.

Als erstes bringen wir das System auf den neuesten Stand.

Dann installieren wir die zum Kompilieren notwendigen Pakete:

Durch Abhängigkeiten wird dies eine weit größere Anzahl von Paketen installieren

Wir erstellen ein neues Verzeichnis und wechseln in dieses

Dann werden die aktuellen Kernel Sourcedateien gedownloaded. Hier NICHT Copy & Paste machen, sondern auf kernel.org nachschlagen, was das neueste Stable Release ist.

Die heruntergeladene Datei entpacken und in das Verzeichnis wechseln

Nun weichen wir von den meisten HowTo´s/Tutorials ab und verwenden den make Parameter localmodconfig. Dadurch werden nur die aktuell verwendeten Module und Treiber für den neuen Kernel übernommen. Wer den Kernel ohne Modul Support bauen möchte, der verwendet den verwandten Parameter localyesconfig. Ich bevorzuge die Modulvariante.
Man wird sehr wahrscheinlich eine Vielzahl von Fragen angezeigt bekommen, die man alle mit Enter bestätigen sollte.

Nachdem das Grundgerüst steht, rufen wir die grafische Konfiguration des Kernels auf

Dort folgende Einstallungen vornehmen:
General setup —>
Timers subsystem —>

  • Timer tick handling (Full dynticks system (tickless)) —>
  • [*] Full dynticks system on all CPUs by default
  • [*] Detect full-system idle state for full dynticks system
  • [*] Old Idle dynticks config
  • [*] High Resolution Timer Support

-*- Enable the block layer —>
IO Schedulers —>

  • <*> Deadline I/O scheduler
  • <*> CFQ I/O scheduler
  • [*] CFQ Group Scheduling support
  • Default I/O scheduler (Deadline) —>

Processor type and features —>

  • Processor family (Generic-x86-64 für AMD, Core 2/newer Xeon für Inetl)
  • Preemption Model (No Forced Preemption (Server)) —>
  • Timer frequency (100 HZ) —>
  • Default I/O scheduler (Deadline) —>

Wer möglichst viel auf einer Maschine laufen lassen möchte wählt bei Preemtion Model No Forced Preemption (Server) aus. Wer den genausten Server für z.B. wenige 128 Tick Warserver haben möchte, der nimmt Preemptible Kernel (Low-Latency Desktop). Das Gleiche gilt für Timer frequency. Je genauer der Kernel sein soll, desto mehr HZ sollten eingestellt werden. Große CSS Public Server werden sich hier über den geringeren Overhead von 100HZ freuen, 128 Tick CS:GO Warserver eher über die 1000HZ.

Power management and ACPI options —>
CPU Frequency scaling —>

  • [ ] CPU Frequency scaling

-*- Networking support —>
Networking options —>

  • [*] Network packet filtering framework (Netfilter)
  • [*] QoS and/or fair queueing

Netfilter sind die IPtables. Diese braucht man nicht zwingen. Jedoch wird man als Betreiber von Gameservern früher, oder später von einem DOS, oder sogar DDOS betroffen sein. Während man gegen letzteres auf dem eigenen Root nicht viel machen kann, kann man einen DOS mittels IPtables filtern. Dafür muss der Support dann im Kernel compiliert sein.
Mittels QoS (Quality of Service) kann man Traffic kategorisieren und priorisieren. Man kann Down und Uploads hinter Gameservertraffik hinten an stellen.

Nachdem alle Einstellungen vorgenommen sind, beenden und speichern wir die Konfiguration und machen uns an das eigentliche Kompilieren.

Wenn der Compiler erfolgreich durchgelaufen ist, sollte sich im Order /root/kernel/ der fertige Gameserver Kernel samt Header Dateien als .deb Pakete befinden. Diese installieren wir mit dem Tool dpkg. Auch hier bitte gucken, dass man nicht einfach Copy & Paste betreibt, sondern vorher schaut, wie der Kernel eigentlich heißt.

Nachdem der Kernel installiert ist, bleibt nur noch das Rebooten:

Je nach Leistungsstärke des Servers, sollte dieser in einer, oder etwas mehr Minuten wieder erreichbar sein. Mit dem Tool uname kann man überprüfen, ob der neue Kernel geladen wurde


IPTables/Firewall

In meinem Github Repository befindet sich ein fertiges Skript für die IPTables. Je nachdem, welche Ports man belegt hat, muss man es noch anpassen.
Es sollte in der Lage sein, gängige Arten von DOS Angriffen abzufangen.

Teamspeak 3 Ports werden an dieser Stelle aufgelistet

Gameserver sind hier zu finden

Je nach Traffikaufkommen, kann das Syslog sehr schnell anwachsen. In diesem Fall folgende Zeilen auskommentieren

12 Gedanken zu “Der optimale Gameroot und Gameserver Kernel

  1. Guten Tag

    Vielen Dank für die Anleitung.

    Es kleines Problem habe ich noch:

    Power management and ACPI options –> CPU Frequency scaling –> -*- CPU Frequency scaling

    -*- CPU Frequency scaling kann icht nicht deaktivieren! Zusammenhang mit welchen Konfiguration?

    Vielen Dank

    Dave

  2. Cool, dass ihr hier ein full dynticks system empfiehlt, obwohl sogar von den Kernel-Entwicklern explizit davon abgeraten wird.
    Noch cooler, dass ihr nicht erwähnt, dass die Option nohz_full=… notwendig ist, damit das ganze überhaupt etwas anderes als schlechtere Performance bewirkt.
    Alles nachzulesen in der Kernel-Doku.

    Den Deadline-FIFO scheduler als default zu wählen ist auch nicht gerade sinnvoll.

  3. Hello, can anyone please help me put a custom kernel on my Debian 8 Jessie server? I am having huge performance issues while running a game server.

  4. Hello, can anyone please help me put a custom kernel on my Debian 8 Jessie? I am having huge problems with running a gameserver…..

  5. Processor type and features —>

    Default I/O scheduler (Deadline) —>

    Bin ich blind auf die Ogen? Ich finde diesen Eintrag einfach nicht.

    Kernel Linux 4.0.5
    Debian 8.1 Jessie

    Hilfe :)

  6. Bei deinem Beispiel:
    apt-get install kernel-package libncurses-dev wget bzip2 make build-essential
    fehlt noch ‚bc‘, dadurch wurde das kompilieren heute bei mir abgebrochen.

    Fehlermeldung war: bc not found

  7. Pingback: Gameserver Kernel Update

  8. Pingback: Gameserver Kernel Updates und Tutorial | Ulrich Block

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.