Performance Probleme vServer

  • Hallo zusammen,


    seit ein paar Wochen haben wir immer mal wieder Performance Probleme mit unserem Teamspeak Server, der auf einem netcup vServer installiert ist. Das ist insofern merkwürdig, da der vServer ausschließlich für das Betreiben dieses einen TS Servers genutzt wird und weder was an der Konfiguration des vServers oder TS Servers geändert wurde. Auch sind in letzter Zeit nicht mehr Leute als üblich mit unserem Server verbunden (i.d.R. 2 bis 8 User gleichzeitig). Der Server ist zugegebenermaßen eher schwach von der Ausstattung aber für Teamspeak definitiv ausreichend und in der Zeit von August 2018 bis vor ca. 3 Wochen hatten wir keinerlei Probleme.


    Die Probleme äußern sich i.d.R. dadurch, dass die Stimmqualität enorm abnimmt, sodass man teilweise nur noch verzerrte Laute vernehmen kann und nicht mehr versteht, was der andere sagt. Zusätzlich kommt es dann auch vor, dass das Wechseln des Channels ein relativ hohes Delay (> 3 Sekunden) aufweist oder man kurz komplett die Verbindung zum Server verliert. Die Probleme treten nicht dauerhaft und in keinem bestimmten Muster auf. Teilweise auch bei nur 2 Leuten auf dem Server, zu anderen Zeitpunkten gibt es aber auch mal mit 6-8 Leuten gar keine Probleme. Aber in den letzten Wochen gab es mindestens einmal täglich die genannten Symptome. Betroffen sind dann auch stets alle User auf dem Server unabhängig von ihrem Provider oder Standort (sind über ganz Deutschland, Österreich und Schweiz verteilt), also scheint es nicht auf Seite des Clients zu liegen.


    Ich habe den Server auch schon mal vollständig neugestartet. Auch die Statistiken im Server Control Panel zeigen keine Auffälligkeiten.


    Gibt es möglicherweise von anderen netcup Kunden ähnliche Erfahrungen? Hat jemand eine Idee, woher das Problem kommen könnte?

    Falls noch weitere Informationen benötigt werden, werde ich versuchen, diese nachzureichen.

    Vielen Dank schon mal!


    Viele Grüße

    Henrik

  • Welchen vServer hast du denn? Und ausser TS läuft nichts?

    Es kann schon sein, dass andere Server auf dem gleichen Host deinen etwas ausbremsen.


    Am besten mal ein Monitoring (ich benutze netdata) laufen lassen, das zeigt dann hoffentlich zu den Problemzeiten, wo's klemmt.

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Der vServer ist ein VPS 200 G8. 1 vCore, 2 GB RAM, 20 GB SSD.

    Wir haben den Server Anfang August 2018 mit Teamspeak aufgesetzt und dann seitdem nichts mehr dran verändert. Und wie gesagt, wir hatten bis vor ein paar Wochen auch keinerlei Probleme. Filesharing ist übrigens auch deaktiviert auf dem TS Server.


    Ich installiere jetzt mal netdata und schau mich dort mal um.

    Danke schon mal für den Tipp.

  • Ich hatte mal ein ähnliches Fehlerbild mit anderer Ursache:

    Clients, die sich über die IPv6-Adresse verbunden hatten, hatten deinen Effekt, während ein Verbinden über IPv4 einwandfrei funktionierte.


    Hast du IPv6 laufen? Nutzt du eine Domain, um dich mit dem Server zu verbinden? Ist für diese Domain ein A- und ein AAAA-Record angelegt?

    Evtl. hilft es, sich dann direkt mit dem TS über die IPv4 oder IPv6 zu verbinden...

  • Eine Domain haben wir nicht (außer die automatisch generierte von Netcup vielleicht). Wir verbinden uns direkt über die IPv4 Adresse. Mit IPv6 haben wir noch nie etwas gemacht. Ich bin mir nicht mal sicher ob wir eine haben. Im Control Panel steht nur das IPv6-Subnet.

  • Eine Domain haben wir nicht (außer die automatisch generierte von Netcup vielleicht). Wir verbinden uns direkt über die IPv4 Adresse. Mit IPv6 haben wir noch nie etwas gemacht. Ich bin mir nicht mal sicher ob wir eine haben. Im Control Panel steht nur das IPv6-Subnet.

    Was im CCP/SCP steht, ist nur eine Reservierung. Wenn ein Image von Netcup verwendet wurde, ist diese wohl auch voreingestellt.

    Klär doch bitte einmal ab, ob Ihr Eure IPs und Routen statisch eingetragen habt, oder, ob DHCP zur Anwendung kommt.

    Dasselbe wäre mit IPv6 zu machen - statische Einträge würde ich den dynamischen Zuweisungen vorziehen.


    Außerdem würde ich grundsätzlich für Anwendungen, die ein wenig zeitkritisch sind, keinen Single-Core-Server verwenden. Selbst ein automatisches Update oder Swapping kann die CPU dann eine Weile lang beschäftigen. Auf welchem Betriebssystem läuft den der TS-Server überhaupt?

    Was läuft sonst noch?


    Im servercontrolpanel.de gibt es Statistiken, die die Auslastung anzeigen - schaut die bitte doch auch an.

  • Außerdem würde ich grundsätzlich für Anwendungen, die ein wenig zeitkritisch sind, keinen Single-Core-Server verwenden. Selbst ein automatisches Update oder Swapping kann die CPU dann eine Weile lang beschäftigen.

    Ein einzelner vCore (inkl. 2GB RAM) ist recht schwach auf der Brust, sollte jedoch problemlos für einen Voiceserver mit 2 bis 8 Benutzern gleichzeitigen ausreichen.



    Da die Probleme erst seit kurzem Auftreten, würde ich im ersten die Server-Logs auf Auffälligkeiten/Unregelmäßigkeiten überprüfen.

  • Kannst du über das SCP Ausschläge der CPU-Last und/oder des Netzwerkes feststellen, und hast du eine ordentlich konfigurierte Firewall laufen?


    Es wäre durchaus möglich, dass ihr Oper einer DDoS-Attacke seid, und es aber noch nicht gemerkt habt - mir ist bewusst, dass es dafür sicherlich keine Gründe gibt, aber die Menschen die sowas machen, brauchen meiner Erfahrung nach nicht unbedingt Gründe. :pinch:

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber

  • Danke erstmal für die ganzen Antworten! Eins noch vorweg, ich bin zwar durchaus mit Informatik vertraut, aber Serveradministration und Linux im Generellen sind nicht gerade meine Fachgebiete, also verzeiht mir wenn ich das ein oder andere Mal wie ein Anfänger wirke^^ Das bin ich in dem Bereich nämlich weitestgehend.


    [Blockierte Grafik: https://i.imgur.com/2sZI5hd.png]


    Nicht sonderlich viel los auf der Maschine ;)

    Die Statistiken im SCP hab ich mir schon ein paar Mal angeschaut und konnte nichts außergewöhnliches feststellen, jedoch ist das entsprechende Tool im SCP funktional eher eingeschränkt, deshalb habe ich jetzt mal das von sdellenb empfohlene Netdata installiert. Sobald ich dann das nächste Mal Probleme feststelle, werde ich da mal reinschauen.


    Das Betriebssystem ist übrigens Debian 8. Also quasi so wie der vServer ausgeliefert wurde. Gab bisher keinen Grund das zu ändern.


    An DDoS hab ich auch schon gedacht, auch wenn wir unseren Server extra nicht auf der Public Server List von Teamspeak stehen haben.

    Firewall, äähmm ja....Empfehlungen? :D


    MTR hab ich mir jetzt auch mal heruntergeladen und werde es bei den nächsten Problemen mal laufen lassen.

  • Ein einzelner vCore (inkl. 2GB RAM) ist recht schwach auf der Brust, sollte jedoch problemlos für einen Voiceserver mit 2 bis 8 Benutzern gleichzeitigen ausreichen.

    Im Worst-Case wohl nicht. Swapping, zram, updatedb, womöglich noch Verzicht auf virtio-Treiber kann durchaus alles Latenzen verursachen. Man darf nicht vergessen, dass Voice zeitkritisch ist. Selbst mit Tuning-Maßnahmen wird man da an gewisse Grenzen stoßen. Beim VPS ist der virtuelle CPU-Kern zudem „geteilt“.


    Man wird hier nur helfen können, wenn ein paar harte Fakten bekannt sind. Ich darf zusammenfassen:


    Im SCP die Statistiken anschauen.

    Welches Betriebssystem läuft unter dem Teamspeak Server?

    Wenn Linux - Mittels „top“-Befehl schauen, was die CPU man meisten beansprucht.

    Ebenso schauen, was den RAM konsumiert.

    Wenn Windows - den Taskmanager um Auskunft bemühen.

    Tuning: Swapping optimieren - Linux: swap-Partition kontrollieren.

    Linux: Virtio Treiber für das Netzwerk verwenden. SCSI für die SSD verwenden: pasted-from-clipboard.png

    Dieses SCSI bewirkt, dass ein SCSI-Adapter emuliert wird, der tatsächlich Virtio-SCSI anbietet. Keinesfalls nur auf Virtio stellen!

    Mittels fstrim / regelmäßig (cronjob) im Dateisystem nicht genutzte Blöcke verwerfen.


    Netzwerk:

    Alles statisch machen. IPv6 ggfls abschalten:

    Code
    echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

    (temporär, permanent über sysctl.conf:)

    Code
    net.ipv6.conf.all.disable_ipv6 = 1

    Von Zram-Swapping würde ich im Falle eines Einkerners jedenfalls absehen, falls die Idee aufgekommen wäre. Die Kompression beansprucht die CPU zusätzlich.

  • Wenn es an der grundsätzlichen Konfiguration des Linux Systems liegen würde, verstehe ich nicht warum es 6 Monate kein einziges Problem gab. Zu keinem Zeitpunkt. Und dann in den letzten 3 Wochen fast jeden Tag.


    Die Festplatte läuft bereits auf SCSI.

    Das Netzwerk verwendet bereits den virtio Treiber.


    RAM Auslastung sieht sehr konstant so aus:

    [Blockierte Grafik: https://i.imgur.com/OJgNF4Z.png]


    Also Swapping findet da nicht statt.



    Wie gesagt, mir ist durchaus bewusst dass der Server schwach ist. Aber da er 6 Monate ohne Probleme Teamspeak auch mit Peaks von 15-20 Usern ohne Probleme handlen konnte, würde mich wundern wenn das Problem plötzlich ein RAM/CPU Bottleneck ist.

  • Firewall, äähmm ja....Empfehlungen?


    Ich würde einfach mal sagen iptables. Soweit ich weiß, sollte folgendes Script reichen.


    Das Script musst du konfigurieren und ausführen. Vorher noch das Paket iptables-persistent installieren (apt-get install iptables-persistent), damit die Regeln beim reboot nicht verloren gehen.


    Dann solltest du eine funktionierende Firewall haben, die dir alle TS3 Ports, das ICMP Protokoll und den SSH Port offen hält.

    Ist nach besten Wissen und gewissen dieses Script. Falls ich da selbst Fehler drin hab, lasse ich mich auch gerne korrigieren. ;)

    "Denn der radikalste Zweifel ist der Vater der Erkenntnis."

    -Max Weber