Beiträge von MMax

Zitat von shepart

Es ist genug frei, aber halt gecached, was in meinen Augen nicht schlimm ist.

Genau so ist es.

Zitat von shepart

VCP meckert nur rum das ich den RAM auslaste.

Etwas irritierend, da stimme ich zu. Im netcup Wiki wird dies aber richtig erklärt.

Zitat

RAM Verbrauch
Es handelt sich um eine Statusanzeige ob der vServer seit seinem letzten Neustart (Reboot) bzw. Start seine garantierten RAM Ressourcen mindestens einmal voll ausgeschöpft hat

Zitat von shepart

Jemand eine Idee, oder einfach ignorieren ?

Ja und Nein. Laut Alex kann der RAM insbesondere direkt beim Starten von Diensten vollständig ausgelastet werden.

Dieses Verhalten kann ich zwar bei dem vServer meines Kollegen nicht wirklich bestätigen, allerdings kann gerade ein etwas zeitverzögertes Starten bei mehreren Diensten, voraussichtlich beim vServer starten, dem entgegenwirken.

Edit:
Ein netcup Mitarbeiter könnte noch mal klären ob "cached" irgend einen Einfluss auf die Statusanzeige zum RAM Verbrauch im VCP hat. Da dies in den bisherigen Beiträgen nicht deutlich genug zum Ausdruck kam. Ich tendiere eher dazu zu sagen, es hat keinen Einfluss.

Zitat von vmk

Du pingst also nur zwischen deinem Privatrechner und dem vServer?

Nein, es wird die Latenz zwischen dem vServer und dem Host gemessen, welcher ausgehende Daten als Erster empfängt.

Siehe dazu in meinem Anfangspost:

Zitat von MMax

Code

$ date && traceroute www.traceroute.eu
Thu Jul  5 16:28:53 CEST 2012
traceroute to www.traceroute.eu (88.198.46.60), 30 hops max, 60 byte packets
 1  37.221.192.3 (37.221.192.3)  210.373 ms  210.109 ms  210.338 ms
***

Hier noch mein auf dem vServer eingesetztes Shell-Script - loghighpings.sh:

#!/bin/sh




# Start it with: ./loghighpings.sh & >/dev/null 2>&1
# Kill the process with: pkill -15 -U `whoami` loghighpings.sh




# Save the inet ip
IP="37.221.192.3"




# Send a ping request to the ip every 10s
while true
do
  # Save the relevant line from ping request
  PING_TEXT=`ping -c 1 $IP | grep time=`




  # Ping >= 100 ?
  if [ `echo $PING_TEXT | awk '{print $7}' | awk -F'=' '{print $2}' | awk -F'.' '{print $1}'` -ge 100 ]
    then
      # Log the high ping with load average from the last min
      echo "$(date "+%Y-%m-%d %H:%M:%S") $PING_TEXT | load average: `cat /proc/loadavg | awk '{print $1}'`" >> ping.log
  fi
  sleep 10
done

Seit dem 10. Juli 2012 setzten wir nun ein von mir selbst erstelltes Shell-Script ein, bei dem Ping alle 10 Sekunden ein „Echo-Request“-Paket an den nächstgelegen Host sendet, welchen ich zuvor per Traceroute ermittelt habe.

Erreicht die gemessene Latenz hierbei 100ms, wird dies plus die Load Average der letzten Minute geloggt. Die hierzu erstellte Log-Datei ist über den Webserver einsehbar.

Was kann dieses Phänomen hervorrufen und wie können wir es noch genauer untersuchen

Ein anderes Problem wurde von meinem Kollegen am 07.07.2012 gegen 20.23 Uhr bemerkt. Er befand sich zu diesem Zeitpunkt auf einem der CS: S-Server.

Die Spieler stockten in unregelmäßigen Abständen - für ca. eine bis drei Sekunden - mindestens einmal in der Minute. Nach über 30 Minuten bestand das Problem immer noch, ehe es später wieder verschwand.

Im Netgraph waren im Spiel während dieser Zeit keine ungewöhnlichen Werte zu erkennen, ebenso blieben Load Average und die Arbeitsspeicherauslastung des vServers wie gewohnt.

Mit dem Programm Top hatte ich mir dann die Auslastung der einzelnen CPU-Kerne etwas näher angeschaut, wobei mir einige Kerne mit Wait-Werten über 5-17% aufgeführt wurden.

Würde dies die Ruckler erklären, auch wenn die Angabe „wait“ für den eigenen vServer niedriger angezeigt wurde

Mein Kollege hatte sich bereits mit diesem Problem an den Support gewand, welcher darauf aber nicht näher einging und ihn stattdessen u. a. bzgl. möglicher eigener Konfigurationsfehler in dieses Forum hier verwies.

Zitat von [netcup] Alex

Naja, aber in beiden Fällen waren falsche RAM- und Swap-Werte am 29.06.2012 nach 16 Uhr bemerkt worden.

Auch trat das Problem damit auf, dass der Node ohne Ankündigung im "stabilen 2.6er-Kernel" neu gestartet wurde.

Nach jeweiliger Anfrage an den Support konnte das Problem mit einem erneuten Neustart sowie Update des "stabilen 2.6er-Kernel" behoben werden.

Beides zu unterschiedlichen Zeiten, somit auf unterschiedlichen Nodes und gestartet wurden die vServer jetzt wieder mit dem "stabilen 2.6er-Kernel".

Ich dachte mir, es wäre vlt. ganz hilfreich auf diesen Umstand hinzuweisen.

Jedenfalls traf es so, wie es in der Überschrift steht, auch auf den vServer meines Kollegen zu und nach einem Neustart dieses mal mit Warnung sind die Ram-Werte wieder wie gewohnt.

Ich möchte noch Anmerken, dass dieser Zwischenfall sonst keinerlei Auswirkungen auf die Verfügbarkeit der von uns genutzten Dienste hatte, von daher war das hier von mir vorgetragene eher rein informativ.

Ein Einzellfall war das worauf der Thread-Ersteller hinweisen wollte aber jedenfalls nicht.

Das kann ich so mal wieder bestätigen.

$ date && uname -va
Thu Jul  5 19:02:41 CEST 2012
Linux v***.yourvserver.net 2.6.36.4-vs2.3.0.36.39-nc #3 SMP Thu Jun 28 07:58:40 UTC 2012 x86_64 GNU/Linux

$ date && free -m
Thu Jul  5 19:03:13 CEST 2012
             total       used       free     shared    buffers     cached
Mem:          2048        611       1436          0          0        373
-/+ buffers/cache:        237       1810
Swap:         2048          0       2048

Nach vorheriger Ankündigung per E-Mail an meinen Kollegen erfolgte der Neustart des Nodes gegen 12.09 Uhr.

Ich hatte mich ja bereits in diesem Thread hier zu dem Problem geäußert.

Nun war heute wieder von ca. 16.18 bis 16.41 Uhr eine Latenz beim vServer von teilweise weit über 200ms - was für Spieler auf einem CS: S-Server nicht zumutbar ist.

Für die hohe Latenz, die direkt vom vServer ausgehen muss, konnte ich selbst keine Ursache finden.

2012-07-05 16:21 Tracroute von traceroute.eu

traceroute to 88.198.182.44 (88.198.182.44), 30 hops max, 60 byte packets
1 	  	  	  	*	*	*
2 	hos-tr1.juniper1.rz13.hetzner.de 	213.239.224.1 	  	0.136 ms 	0.148 ms 	 
	hos-tr4.juniper2.rz13.hetzner.de 	213.239.224.97 	  	0.132 ms
3 	hos-bb2.juniper1.rz6.hetzner.de 	213.239.240.143 	  	4.099 ms 	4.119 ms 	4.118 ms
4 	gw01-hetzner.netcup.net 	78.47.244.254 	  	3.120 ms 	3.125 ms 	3.121 ms
5 	static.88-198-182-44.clients.your-server.de 	88.198.182.44 	  	212.119 ms 	212.091 ms 	212.107 ms

stats Befehl per rcon bei 88.198.182.44:27015

16:23:26 CPU    In (KB/s)  Out (KB/s)  Uptime  Map changes  FPS      Players  Connects
         0.00   8.44       26.75       239     6            66.83    3        120

stats Befehl per rcon bei 88.198.182.44:27045

16:23:56 CPU    In (KB/s)  Out (KB/s)  Uptime  Map changes  FPS      Players  Connects
         0.00   23.29      56.36       239     7            66.70    5        116

$ date && traceroute www.traceroute.eu
Thu Jul  5 16:28:53 CEST 2012
traceroute to www.traceroute.eu (88.198.46.60), 30 hops max, 60 byte packets
 1  37.221.192.3 (37.221.192.3)  210.373 ms  210.109 ms  210.338 ms
 2  static.253.245.47.78.clients.your-server.de (78.47.245.253)  210.341 ms  210.338 ms  210.327 ms
 3  hos-bb2.juniper1.rz13.hetzner.de (213.239.240.133)  212.784 ms hos-bb2.juniper2.rz13.hetzner.de (213.239.240.134)  212.827 ms hos-bb2.juniper1.rz13.hetzner.de (213.239.240.133)  218.396 ms
 4  hos-tr2.ex3k12.rz13.hetzner.de (213.239.224.45)  215.181 ms  215.279 ms hos-tr3.ex3k12.rz13.hetzner.de (213.239.224.77)  215.312 ms
 5  faces.eu (88.198.46.60)  212.832 ms  212.815 ms  212.822 ms

$ top
top - 16:30:15 up  4:14,  1 user,  load average: 0.59, 0.36, 0.34
Tasks:  22 total,   1 running,  21 sleeping,   0 stopped,   0 zombie
Cpu(s):  6.9%us,  6.0%sy,  0.0%ni, 59.9%id, 25.8%wa,  0.0%hi,  1.4%si,  0.0%st
Mem:   2097152k total,   588676k used,  1508476k free,        0k buffers
Swap:  2097152k total,        0k used,  2097152k free,   371876k cached




***

Auf das Problem hatte mein Kollege den Support erst gestern noch mal aufmerksam gemacht, hierzu aber bisher noch keine konkrete Antwort erhalten.

Für Vorschläge zur Lösung des Problems wären wir daher sehr dankbar.

Bei meinem Kollegen handelt es sich, wie bereits in dem anderen Beitrag erwähnt, um einen vServer 2000. Der Arbeitsspeicher wird auch in unserem Fall mit free/top etc. als doppelt soviel ausgewiesen.

Zitat von vmk

update? Scheinbar ist das Editieren der eigenen Beiträge gerade kaputt

1. das und 2. bleib ich über https nicht angemeldet und muss die Seite extra noch mal ohne Verschlüsselung als http neu laden, um überhaupt angemeldet zu bleiben.

Ich vermute mal, dass das hier auch auf dich zutrifft.

- vServer Neustart ohne Warnung - Uralter Kernel, RAM-Werte anders

Das kann ich so bestätigen.

Kernel-Version und free -m bei meinem Beitrag Anfang diesen Jahres.

$ date && uname -va
Sat Jun 30 21:31:14 CEST 2012
Linux v***.yourvserver.net 2.6.33.1-vs2.3.0.36.30.4-netcup #1 SMP Mon Mar 29 15:02:52 UTC 2010 x86_64 GNU/Linux

$ date && free -m
Sat Jun 30 21:31:42 CEST 2012
             total       used       free     shared    buffers     cached
Mem:          4096        642       3453          0          0        433
-/+ buffers/cache:        209       3886
Swap:       137431          0     137431

Das erklärt evtl. auch den vServer-Neustart bei meinem Kollegen am 29.06.2012 gegen 16.09 Uhr.

Also ein Kollege und ich nutzen zusammen einen vServer 2000 und bei uns kam es ebenfalls in letzter Zeit zu unerklärlichen Neustarts sowie zeitweise erhöhten Latenzen.

Einmal endeten die Logs der zwei ausgeführten CS: S Dienste am 21.06.2012 gegen 11.52 Uhr, wobei alle anwesenden 20 Spieler kurz zuvor wegen „timed out“ oder zu hohen Ping durch den Einsatz eines Plugins vom Server geworfen worden. Da der vServer danach nicht mehr lief, wurde dieser gegen 13.05 Uhr im VCP per Eingabe wieder neu gestartet.

Am 22.06.2012 erreichte der vServer zwischen 2.48 Uhr und 3.05 Uhr erneut eine ungewöhnlich hohe Latenz. Alle anwesenden 12 Spieler auf den CS: S-Servern verließen in dieser Zeit den Server oder wurden wegen zu hohen Ping vom Server geworfen. Ein ausgeführter Traceroute zu diesem Zeitpunkt vom vServer zu google.de bestätigte meinen Verdacht, dass das Problem direkt beim vServer lag.

Eine Anfrage an den netcup Support ergab, dass hierfür einer unserer ausgeführten Dienste verantwortlich sein soll, der "die Bandbreite entsprechend" auszulasten scheint. Auch sollen unsere eingesetzten Dienste "offenbar des öfteren durch Peaks die gesamten Ressourcen des vServers" auslasten.

Am 29.06.2012 dann der nächste Zwischenfall. Diesmal endeten die Logs gegen 16.09 Uhr und gegen 16.43 Uhr startete der vServer automatisch neu.

Mein Kollege erhielt zu den hier genannten Fällen keine Benachrichtigung seitens netcup.

Eine genaue Messung der genutzten Bandbreite des vServers erscheint mir leider nicht möglich, da hierfür geeignete Programme wie iptraf durch die hier eingesetzte Virtualisierung nicht unterstützt werden und ein Analysieren des Traffics über die Schnittstelle eth0 nicht zum gewünschten Ergebnis führt, da diese den gesamten Traffic des Nodes verarbeitet.

Eine Analyse der einzelnen Dienste ist hingegen möglich. Bei CS: S kann man hierzu den Befehl stats verwenden.

Bei einem vollen CS: S Server sieht die Ausgabe über das Tool HLSW so aus:

18:32:43 CPU    In (KB/s)  Out (KB/s)  Uptime  Map changes  FPS      Players  Connects
         24.90  70.18      185.16      1548    42           66.85    12       714

Das in etwa mal zwei plus anfallende Verbindungen zum Apache Server bzgl. "MOTD-Seiten" und "Fast Download" stellt unsere gängige Auslastung der vServer-Bandbreite dar.

Mit dem Programm top liegt load average bei etwa 0.30-0.55 und der Arbeitsspeicher wird zu weniger als 10-20% ausgelastet.

Wir können uns die bei uns aufgetretenen Vorkommnisse vorerst nicht erklären, evtl. kann der Support hierzu auch genauere Angaben machen, wann diese auftreten und unter welchem Port z.B. erhöhte Bandbreitenauslastung stattfindet.

Somit wäre es wohl auch in deinem Fall ratsam den Support zu kontaktieren und ihm deine Beobachtungen zu schildern.

Zitat von nubtwo

Hab dem Server mal nen reboot gestattet, nun sieht es so aus:
Mem: 1048576k total, 58940k used, 989636k free, 0k buffers

verstehe das mal einer, jmd ne Idee?

Die Sache mit der Arbeitsspeicherauslastung wurde hier im Forum schon mehrfach thematisiert (u. a. hier).

Entscheidend für dich ist was deine Prozesse an physikalischen Arbeitsspeicher belegen.

Da auch die Festplatte Daten zum schnelleren Zugriff im Arbeitsspeicher auslagert (cached), wird hierdurch mehr Arbeitsspeicher verwendet, der allerdings jederzeit wieder freigegeben werden kann.

Eine Anzeige des freien Arbeitsspeichers abzüglich cached kannst du mit dem Befehl free –m ermitteln, allerdings scheint mir diese Berechnung da nicht sehr zuverlässig zu funktionieren.

OK, danke für den Hinweis Martin. Das letzte Update erschien am 10. März 2012, weswegen wir dann auch bald umsteigen werden.

Wenn das Shellscript srcds_run mit dem Parameter –autoupdate gestartet wird, so wird der Prozess srcds_linux, wenn nicht mehr vorhanden, erneut gestartet. Dies erfolgt nach einem Crash oder bei einer Updatemeldung, bei welcher der Prozess beim nächsten Kartenwechsel beendet wird.

Bei uns gibt es in diesem Zusammenhang zwar kein Problem, aber es könnte eine mögliche Fehlerquelle sein.

Ein Problem was ich allerdings selbst schon mehrfach feststellen konnte, ist, dass sich srcds_linux nach einiger Zeit mit über 100% CPU-Last aufhängen kann und dann von Hand neu gestartet werden muss.

Wir haben noch die vorhergehende Debian-Version installiert, aber daran sollte es vermutlich nicht liegen.

Bei uns ruft ein selbst erstelltes Start-Script das Shellscript srcds_run in einem extra Fenster per screen auf. Je nachdem wie umfangreich das Start-Script ist (im Internet werden bereits einige angeboten), kann man dann den CSS-Server nach belieben darüber starten, stoppen oder weitere Aktionen ausführen.

Sollte es wieder vorkommen, dass sich der oder die Prozesse weder über ein solches Start-Script, noch über den Fenstermanager Screen beenden lassen, so hilft in diesem Fall der Befehl kill weiter.

Wie startest du denn deinen CSS-Server und welche Linux-Distribution hast du installiert?
Von alleine passiert bei mir so etwas jedenfalls nicht.

Gruß
MMax

Stimmt, das steht dort.
Ich hätte vermutet entgegen zur Meldung wird dort der aktuelle Status ausgegeben.
Doch da lag ich wohl falsch. Da hätte ich mich natürlich besser im Wiki informieren können.

Wie der RAM so stark ausgelastet sein soll, das weiß ich zwar immer noch nicht, dennoch ist das Thema damit hier vorerst beendet.

Vorhin viel mir auf, dass einer unserer CS: S-Server nicht mehr erreichbar war, da er sich aufgehängt hatte. Das Verhalten hatte ich bereits bei #5 geschildert.

Zitat von MMax

Nicht ganz. Der 2. CS: S-Server läuft erst seit dem 15.01.2012. Bei dem anderen Server hatte sich seit November 2011 ein paar mal der srcds_linux Prozess mit über 100% Last aufgehängt.

top

top - 01:05:13 up 12 days, 15:52,  1 user,  load average: 1.01, 1.05, 1.07
Tasks:  19 total,   2 running,  17 sleeping,   0 stopped,   0 zombie
Cpu(s): 10.4%us,  2.0%sy,  0.0%ni, 87.4%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   2097152k total,  1238868k used,   858284k free,        0k buffers
Swap:  2097152k total,        0k used,  2097152k free,  1004040k cached




  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
15*** ********  20   0  284m 129m  18m R  102  6.3 801:16.67 srcds_linux
25*** ********  20   0  272m 121m  18m S    8  5.9 359:01.22 srcds_linux

Laut Log-Eintrag muss sich der entsprechende CS: S-Server mit 102% CPU-Last gegen 21:30 Uhr aufgehängt haben. Den Prozess habe ich dann gegen 01:08 Uhr neu gestartet.

top

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12*** ********  20   0  228m  79m  19m S    6  3.9   3:08.13 srcds_linux
25*** ********  20   0  272m 116m  17m S    4  5.7 362:57.22 srcds_linux

free -m

total       used       free     shared    buffers     cached
Mem:          2048       2048          0          0          0       1873
-/+ buffers/cache:        174       1873
Swap:         2048          0       2048

Sieht auch soweit ok aus, dennoch steht im netcup VCP:

Zitat

Seit dem letzten Start hat Ihr VServer mindestens einmal sein RAM Limit ausgeschöpft.

Außerdem wird der RAM Verbrauch dort mit rot angegeben.

Müsste unter diesen Bedingungen der RAM Verbrauch nicht eigentlich mit grün angegeben werden?

Wie ist diese Ausgabe nun zu interpretieren?

Also sind die Angaben unter "free -m" nicht verwertbar und ich muss mich auf die der einzelnen Prozesse verlassen.

top

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 21** ********  20   0  272m 123m  19m S   29  6.0 275:24.41 srcds_linux
 26** ********  20   0  254m 105m  19m S   12  5.2 137:06.66 srcds_linux

Die sind im Vergleich zu denen vor 7h nahezu unverändert.

Nachtrag von 20:24 Uhr:
Mein Kollege teilte mir eben noch mit, dass er gestern früh eine E-Mail von netcup erhalten hat bzgl. Wartungsarbeiten am Node.
Das erklärt nun auch die Unterbrechung, da diese Arbeiten für die Zeit zwischen 8 und 9 Uhr angesetzt waren und ein Update des Kernels beinhalteten.

Der vServer verwendet nun die folgende Kernel-Version: uname –r

3.0.18-vs2.3.2.2-nc

Dragon
Wenn ich das dort richtig verstehe, dann wird das hier dargestellte Verhalten mit diesem Trick nachgestellt.
Aber was kann ich jetzt damit anfangen

Inzwischen ist der Wert des verwendeten Puffer noch weiter gesunken.

free -m

total       used       free     shared    buffers     cached
Mem:          2048       2048          0          0          0       2041
-/+ buffers/cache:          6       2041
Swap:         2048          0       2048

Nach 20 ½ Stunden Laufzeit habe ich jetzt noch einmal die RAM-Auslastung kontrolliert. Im netcup VCP erscheint bisher "kein neuer Status vorhanden" bzw. ist die Meldung seit gestern nicht mehr erschienen.

free -m

total       used       free     shared    buffers     cached
Mem:          2048       2048          0          0          0       2024
-/+ buffers/cache:         23       2024
Swap:         2048          0       2048

Was mich hierbei verwundert sind die nur ca. 23 MB die derzeitig vom System auch tatsächlich verwendet werden.

top

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 21** ********  20   0  271m 122m  19m S    8  6.0 222:32.06 srcds_linux
 26** ********  20   0  254m 105m  19m S    3  5.1 113:44.00 srcds_linux

Die beiden Prozesse belegen ca. 227MB (122MB+105MB) des physikalischen Arbeitsspeichers.

Sind dann die ca. 23 MB des verwendeten Puffer nicht zuwenig oder wie muss ich diese Ausgabe interpretieren

Zitat von [netcup] Alex

Wenn einer der Gameserver nicht stabil funktioniert und dort ggf. auch Plugins / Erweiterungen verwendet werden, kann dies schon eine Ursache sein.

Der erste CS: S-Server war lange Zeit über mehrere Tage und Wochen ohne Unterbrechung durchgelaufen. Als so genannte Addons verwenden wir MetaMod: Source v1.8.7 und SourceMod v1.4.1. Dabei handelt es sich um die neusten stabilen Versionen. Der Fehler der beim ersten Server seit November auftritt äußerte sich bisher anders.
Das CS: S-Server insbesondere nach neuen Updates fehlerhaft laufen können, ist bekannt, allerdings halte ich das in dem Fall für etwas unwahrscheinlich, da das letzte Update schon etwas zurückliegt und wohl auch andere ein derartiges Problem melden würden.

Zitat von [netcup] Alex

Auch ist es durchaus normal das ein vServer mit einem Webserver und 2 Gameservern beim Start viel RAM verbrauchen kann.

Die 2 GB an verwendetem RAM kommen mir in diesem Fall dennoch etwas seltsam vor, zumal ich vor längerer Zeit auch schon mal einen weiteren Server zum Testen im Autostart hatte und diese Meldung währenddessen nicht erschien.