Ich habe eine Maschine, auf der Debian seit langer Zeit (vielleicht 7 Jahre) rund um die Uhr läuft. Vor zwei Wochen habe ich beschlossen, den Standort des Servers zu ändern und auf Debian Jessie zu aktualisieren (lief mit Wheezy).
Alles lief prima, außer dass der Server alle 5 oder 6 Minuten für etwa 20 Sekunden nicht auf Verbindungen reagierte.
Ich habe ein Skript erstellt, um zu prüfen, wann das passiert. Hier sind die Zeiten:
2017-01-12 16:16:05 TIMEOUT!
2017-01-12 16:21:49 TIMEOUT!
2017-01-12 16:27:32 TIMEOUT!
2017-01-12 16:33:13 TIMEOUT!
2017-01-12 16:39:01 TIMEOUT!
...
2017-01-12 17:07:59 TIMEOUT!
2017-01-12 17:13:47 TIMEOUT!
2017-01-12 17:19:25 TIMEOUT!
Auf dem Server läuft eine virtuelle Maschine, und die Pakete erreichen sie ohne Verzögerung. Ich habe verschiedene Ports auf dem Server getestet, etwa 80, 443, 9000 usw., und alle haben eine Zeitüberschreitung. Wenn ich beispielsweise auf dem Server SSH ausführe und während der Zeitüberschreitung einen Befehl ausprobiere, z. B. dreimal „ls“ eingebe, empfängt es nach der Wiederherstellung die drei „ls“ und führt es aus.
Ich habe die Protokolle auf dem Server überprüft, konnte jedoch keine diesbezüglichen Informationen finden.
BEARBEITEN: Wenn der Ping laufen gelassen wird, wird kein Timeout angezeigt.
EDIT2: Ok, noch eine seltsame Sache. Wenn ich per SSH auf den Server zugreife und Ping 8.8.8.8 (oder wahrscheinlich jeden beliebigen Befehl, der Text ausgibt) ausführe, wenn das Timeout beginnt, kann ich die Textausgabe des Pings immer noch problemlos anzeigen. Wenn ich STRG+C drücke, um ihn abzubrechen, sehe ich den Min./Durchschnitt./Max.-Status des Pings, aber wenn ich einen Befehl eingebe (zum Beispiel „ls“), wartet er, bis der Server wieder verfügbar ist, um die Dateiliste anzuzeigen.
EDIT3: Es könnte also etwas mit der Festplatte zu tun haben. Die SDA ist eine Samsung SSD 840 Pro 120 GB.
iostats zeigen Folgendes:
Normales Verhalten:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-0 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-1 0.00 0.00 0.00 2.00 0.00 20.00 20.00 0.00 0.00 0.00 0.00 0.00 0.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Timeout-Verhalten:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.00 0.00 136.00 0.00 69124.00 1016.53 127.69 1053.93 0.00 1053.93 7.35 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc 0.00 16.00 0.00 18.50 0.00 540.00 58.38 0.10 5.51 0.00 5.51 1.19 2.20
dm-0 0.00 0.00 0.00 1.00 0.00 4.00 8.00 521.34 363490.00 0.00 363490.00 1000.00 100.00
dm-1 0.00 0.00 0.00 1.00 0.00 4.00 8.00 521.35 363492.00 0.00 363492.00 1000.00 100.00
dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Antwort1
Nach dem GebrauchiostatUndiotopZur Diagnose habe ich festgestellt, dass das Problem beim Redis-Server lag, der die Datenbank persistent auf der Festplatte speicherte. Aufgrund des Datenbankwachstums blockierten die auf die Festplatte geschriebenen Daten aus irgendeinem Grund den Netzwerkverkehr, was die Ursache für das Timeout war (Massenschreibvorgänge auf die Festplatte).
Da ich keine Persistenz auf der Festplatte benötige, habe ich sie deaktiviert und jetzt funktioniert es wieder einwandfrei, aber ich weiß nicht, warum sich der Redis-Server so verhält.