PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Komplettes Interface ist phasenweise nicht erreichbar



IkeV3
10.05.07, 12:54
Hallo miteinander,

ich habe einen dedizierten Server bei Hetzner für ein Communityportal gebucht. Installiert ist ein aktuelles Debian 4 mit Lighttpd, MySQL etcpp...
Es sind relativ viele Zugriffe auf die Seite (ca. 1,5GB Traffic am Tag).
Allerdings gibt es immer wieder, ohne erkennbare Regelmäßigkeit, komplette Verbindungsabbrüche, sprich alle Verbindungen, sei es HTTP, SSH oder FTP brechen auf einen Schlag ab und sind erst einige Minuten bis einer halben Stunde später wieder erreichbar.
Laut MTR ist die Verbindung tatsächlich am Server weg... Ansonsten ist die Verbindung absolut schnell.

Ich habe sämtliche mir bekannte Logs gecheckt und nichts gesehen, soll heißen zu den bestimmten Zeiten gibt es keinerlei Einträge.

Die Load liegt im Normalbetrieb zwischen 3 und 5 und geht nach einem solchen Verbindungabbruch natürlich runter, da sich der Lighttpd und die MySQL auf einen Schlag langweilen.

Kann es sein, dass das Interface (eth0) einfach bei einem bestimmten Schwellwert an "Verkehrsaufkommen" pausiert? Oder irgendwas in der Art? Gibt es da Logs für oder lassen sich welche aktivieren?

Habt ihr irgendeinen Ansatz, wie ich das Problem weiter eingrenzen könnte?

Schönen Gruß

IkeV3

$kuLL
10.05.07, 16:36
Poste mal die Ausgabe von

ifconfig eth0

IkeV3
10.05.07, 16:40
Bitteschön... (leicht zensiert)



eth0 Link encap:Ethernet HWaddr 00:19:DB:32:05:XX
inet addr:88.198.65.XXX Bcast:88.198.65.XXX Mask:255.255.255.224
inet6 addr: XXXX::219:dbff:fe32:557/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2316124 errors:39 dropped:0 overruns:0 frame:39
TX packets:2842751 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:562474663 (536.4 MiB) TX bytes:2743224903 (2.5 GiB)
Interrupt:10 Base address:0x8000

IkeV3
10.05.07, 16:55
Mittlerweile hat sich herausgestellt, dass es wohl ein Zwischending aus suboptimalen SQL-Statements und subsubsuboptimaler MySQL-Konfiguration zu sein scheint, das die Load in dermaßene Spitzen hochtreibt, dass auch der TCP/IP-Stack keine CPU-Zeit mehr hat...

Hoff ma' mal dass dem tatsächlich so ist...