Warum antwortet der Server nicht?

Warum antwortet der Server nicht?

Unser Server weigert sich gelegentlich, eine einfache HTML-Seite bereitzustellen.

Dies passiert bei einer relativ hohen Anzahl von Anfragen. Der Prozessor ist jedoch nicht stark ausgelastet und es ist viel freier Speicher vorhanden. Der Fehler scheint im Durchschnitt bei 1 von 50 Anfragen aufzutreten, abhängig von der Serverauslastung.

Ich muss die Ursache des Problems finden und die entsprechenden Maßnahmen ergreifen, um es zu beseitigen.

Ich vermute, dass die Ursache des Problems eine große Anzahl eingehender Netzwerkpakete ist. Im Durchschnitt sind es 5000 Pakete pro Sekunde. Datenverkehr – 2 MBit/s. Kann das die Fehlerursache sein?

Interessant ist dabei, dass die Anforderungszeichenfolge von Apache nicht in access.log protokolliert wird, falls der Server nicht antwortet.

Der Fehler ist von mehreren Client-Rechnern aus reproduzierbar. DNS ist nicht beteiligt, da ich den Server über die IP aufgerufen habe.

Ich habe den Problemfall mit dem Dienstprogramm tcpdump profiliert. Dies sind die guten und schlechten Sitzungen, die von tcpdump verfolgt werden. Die Anfrage ist in beiden Experimenten dieselbe. Gut – Server gibt Antwort zurück. Schlecht – keine Antwort, Timeout-Fehler.

---- Bad ----
12:23:36.366292 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:23:39.362394 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:23:45.365567 IP 123.45.67.890.61749 > myserver.superbservers.com.www: S 2125316338:2125316338(0) win 8192 <mss 1460,nop,nop,sackOK>
--------

---- Good ----
12:27:07.632229 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:27:10.620946 IP 123.45.67.890.63914 > myserver.superbservers.com.www: S 3581365570:3581365570(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK>
12:27:10.620969 IP myserver.superbservers.com.www > 123.45.67.890.63914: S 2654770980:2654770980(0) ack 3581365571 win 5840 <mss 1460,nop,nop,sackOK,nop,wscale 6>
12:27:10.838747 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 1 win 4380
12:27:10.957143 IP 123.45.67.890.63914 > myserver.superbservers.com.www: P 1:213(212) ack 1 win 4380
12:27:10.957152 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 213 win 108
12:27:10.965543 IP myserver.superbservers.com.www > 123.45.67.890.63914: P 1:630(629) ack 213 win 108
12:27:10.965621 IP myserver.superbservers.com.www > 123.45.67.890.63914: F 630:630(0) ack 213 win 108
12:27:11.183540 IP 123.45.67.890.63914 > myserver.superbservers.com.www: . ack 631 win 4222
12:27:11.185657 IP 123.45.67.890.63914 > myserver.superbservers.com.www: F 213:213(0) ack 631 win 4222
12:27:11.185663 IP myserver.superbservers.com.www > 123.45.67.890.63914: . ack 214 win 108
--------

Hoster: SuperbHosting

Betriebssystem: Ubuntu

Serverparameter: E6300 CONROE 1,86 GHz 2 x 1 MB CACHE 1066 1 GB DDR2 667 MHz

Dies ist ein Link zur von uns verwendeten Apache-Konfigurationsdateihttp://repkin5.snow.prohosting.com/apache.txt

Dies ist ein Server-Statusbericht, der direkt nach dem Timeout-Fehler erstellt wurde.http://repkin5.snow.prohosting.com/server-status.htmEs werden nur 10 von 120 untergeordneten Servern ausgeführt, also genügend Platz für neue Anfragen.

VMSTAT

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0   8900 725900   8468  65684    0    0     5    18   11   33  4  3 92  1

Antwort1

  • Interessant ist dabei, dass die Anforderungszeichenfolge von Apache nicht in access.log protokolliert wird, falls der Server nicht antwortet.

Das klingt nach einem Netzwerkproblem. Der Server sollte alle eingehenden Anfragen protokollieren, auch wenn er aus irgendeinem Grund nicht antworten kann. Sie sollten überprüfen, ob auf dem Webserver kein Paketverlust auftritt.

Antwort2

Es besteht eine kleine Chance, dass Sie sich in einer Situation befinden, in der die verfügbaren Kernelpuffer für TCP-Verbindungen niedrig sind. Ich würde davon ausgehen, dass eine Protokollierung erfolgt (melden Sie sich beim Server an, testen Sie, bis Sie eine „keine Antwort“ erhalten, führen Sie es dann aus dmesgund prüfen Sie, ob etwas anwendbar erscheint).

Um das Netzwerk-Setup zu optimieren,Dies könnte ein Ausgangspunkt sein.

Wie Chris Nava sagte, sollten Sie sicherstellen, dass es sich nicht nur um Paketverluste im gesamten Netzwerk handelt. Beginnen Sie also unbedingt mit der Prüfung per Ping (das Antworten auf einen Ping ist leider nicht ganz dasselbe wie der Umgang mit einem TCP-Paket).

verwandte Informationen