Nicht-Erreichbarkeit nach Aufbrauchen des Inklusivtraffics
Auch mit 2.6.38.2'er Kernel schmiert der Server ab. Am aller-schönsten ist es in Verbindung mit
diesem Problem und dem merkwürdigen Verhalten eurer Techniker, den Server im Rescue Modus neuzustarten und einfach dort zu belassen. Ich freue mich schon darauf, den letzten IsGenug Server los zu werden.
Fürs Protokoll: Dieses mal handelt es sich um 101216.
Edit: Wenn der Server mal nicht in den Rescue Modus versetzt wird, dann wird der Traffic null geroutet, da angeblich ein Angriff stattfindet. Ich vermute, dass dies eher im Zusammenhang mit der Bandbreitenbeschränkung liegt.
Kleine Statistik: Um 17:30 wurde der Server gedrosselt. Seitdem wurde er 4x in den Rescue Modus versetzt und 2x wurde ein "Angriff" diagnostiziert und der Traffic für eine Stunde gesperrt. (Jetzige Uhrzeit 24:00)
PhilipM wrote:
> Schaut so aus als wäre um 17:18 die Drosselung angesprungen und um 17:33
> wäre der Reboot erfolgt.
Ja, und zwischenzeitlich wurde wegen zu hoher Last nichts mehr geloggt
vermute ich. Probier vielleicht auch mal einen aktuelleren Kernel
(
ftp://ftp.ovh.net/made-in-ovh/bzImage/2.6.38.2/)
Manche Software (Plesk, bestimmte Java-Applikationen) vertragen sich
auch nicht gut mit dem GRs-Kernel, daher vielleicht testweise mal den
-std Kernel nehmen.
--
Felix
OVH Team
Zitat von
kro
PhilipM wrote:
> Der Server war definitiv down:
Von uns aus ist kein reboot unternommen worden, eventuell mal in den
logs checken ob er sich vor lauter last weggehangen hat?
--
Felix
OVH Team
Auszug aus /var/log/messages:
Code:
Jun 1 15:51:46 ksXXXXXX kernel: e1000e: eth0 NIC Link is Up 100 Mbps Full Duplex, Flow Control: None
Jun 1 15:51:46 ksXXXXXX kernel: 0000:01:00.0: eth0: 10/100 speed: disabling TSO
Jun 1 15:51:46 ksXXXXXX kernel: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun 1 17:18:34 ksXXXXXX kernel: e1000e: eth0 NIC Link is Down
Jun 1 17:18:36 ksXXXXXX kernel: e1000e: eth0 NIC Link is Up 10 Mbps Full Duplex, Flow Control: None
Jun 1 17:18:36 ksXXXXXX kernel: 0000:01:00.0: eth0: 10/100 speed: disabling TSO
Jun 1 17:33:30 ksXXXXXX kernel: imklog 3.18.6, log source = /proc/kmsg started.
Jun 1 17:33:30 ksXXXXXX rsyslogd: [origin software="rsyslogd" swVersion="3.18.6" x-pid="3820" x-info="http://www.rsyslog.com"] restart
Jun 1 17:33:30 ksXXXXXX kernel: Initializing cgroup subsys cpuset
Jun 1 17:33:30 ksXXXXXX kernel: Linux version 2.6.34.6-xxxx-grs-ipv6-64 (root@kernel-64.ovh.net) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #3 SMP Fri Sep 17 16:06:38 UTC 2010
Jun 1 17:33:30 ksXXXXXX kernel: Command line: auto BOOT_IMAGE=Linux ro root=901
Jun 1 17:33:30 ksXXXXXX kernel: BIOS-provided physical RAM map:
Schaut so aus als wäre um 17:18 die Drosselung angesprungen und um 17:33 wäre der Reboot erfolgt.
Beim RTM gibt es auch keinen großartigen Anstieg der Last, jedoch steigt die Memory-Usage während der Server down ist?
http://img20.imageshack.us/img20/7172/loady.png
Der Load-Chart ist da weitaus interessanter, wobei ich vermuten würde, dass der große Ausschlag erst nach dem Reboot mit inklusivem Raid-Resync kam. Der etwas kleinere Ausschlag davor war ein selbst durchgeführter Reboot bei dem kein Resync angestoßen wurde und vor dem großen Ausschlag sieht man blanke Stellen:
http://img17.imageshack.us/img17/6350/loada.pnghttp://img64.imageshack.us/img64/3790/loadlarge.png
PhilipM wrote:
> Der Server war definitiv down:
Von uns aus ist kein reboot unternommen worden, eventuell mal in den
logs checken ob er sich vor lauter last weggehangen hat?
--
Felix
OVH Team
Zitat von
kro
PhilipM wrote:
> Für Server 123041 kam soeben die E-Mail bezüglich Drosselung und
> sogleich war er down.
Er pingt, aber mit hoher Latenz:
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 191.938/216.790/246.855/21.945 ms
das weist eher auf eine akute Ueberlastung aufgrund der
10MBit-Limitierung hin.
--
Felix
OVH Team
Ich habe bereits neuen Traffic bestellt und die Limitierung wurde bereits aufgehoben, weshalb er mit hoher Latenz pingt ist mir ein Rätsel.
Der Server war definitiv down:
Code:
ksXXXXXXX:~# uptime
18:10:38 up 25 min,
Anderer netter Nebeneffekt ist, dass nun wieder ein Raid-Resync durchläuft der den Server stark negativ beeinträchtigt.
PhilipM wrote:
> Für Server 123041 kam soeben die E-Mail bezüglich Drosselung und
> sogleich war er down.
Er pingt, aber mit hoher Latenz:
4 packets transmitted, 4 received, 0% packet loss, time 2999ms
rtt min/avg/max/mdev = 191.938/216.790/246.855/21.945 ms
das weist eher auf eine akute Ueberlastung aufgrund der
10MBit-Limitierung hin.
--
Felix
OVH Team
Für Server 123041 kam soeben die E-Mail bezüglich Drosselung und sogleich war er down.
@Felix: Wie wäre es mit einer Rückmeldung ob ihr dieses "Phänomen" als Bug akzeptiert oder es für Zufall haltet?
Hi Saschilys,
das Ding war definitiv Down:
Code:
ksXXXXXXX:~# uptime
16:32:52 up 22:50
Ich habe keinen Reboot veranlasst, wenn dieser Fall eintritt, kommt der Server nach 1-2 Stunden automatisch wieder.
Frage:
Ist der Server wirklich down?
Also hast du schon definitiv sagen können, das dieser Down ist.
Bsp.: Das er nach Upgrade des InklTraffics nicht erreichbar war, und du ihn per Hard-Reboot wieder starten mußtest?
Hi Saschilys,
meine Server haben eine kontinuierliche Last, die weit von deinen 200MB/s entfernt ist und auch noch weiter besteht, wenn der Server wieder online geht. In diesem Fall kommen weiterhin Pakete durch, jedoch steigt die Latenz auf bis zu 3-4 Sekunden. Die betroffenen Server stammen aus der Isgenug Reihe und haben nur eine 100Mbit/s Anbindung, welche regulär in den Abendstunden voll ausgereizt wird und selbst da ist der Server bei gedrosselter Verbindung noch mit extrem hohen Latenzen zu erreichen.
Das Problem kenne ich, hat aber (bei mir) nichts damit zu tun, das der Server down ist, sondern das das System sich nicht zum Server verbinden kann.
Man kann das vergleichen mit einer Autobahn, die voll befahrbar ist.
Wenn eine Seite abgesperrt ist, staut sich der Verkehr, und auch der Krankenwagen käme nicht direkt durch......
Somit wird dir eine Email geshcickt, das der Server down ist, aber es nicht war.
Bei mir im Fall war es so:
Ich hatte an die 200 MB/sec Traffic.
Als der Inklusivtraffic verbraucht war, wollten aber die 200 MB/s weiter genutzt werden, aber es nur 10 MB/s Bandbreite zur verfügung standen.
Somit war es auch für mich nicht möglich sich zum Server zu verbinden.
Ich bekam auch keine Mail, Server sei down, was aber nicht der Fall war.
Dieser lief weiter, konnte aber keine Anfrage mehr bearbeiten, auch die von dem Monitoringsystem.
Problem ist soebend wieder aufgetreten, Server-Nr: 101216.
17:26 Email bzgl. Traffic-Überschreitung
17:26 Email bzgl. Nicht-Erreichbarkeit (Server Down)
Hallo Felix,
vielen Dank für die Antwort. Ich habe nichts an meiner Netzwerkkarte geändert.
Gerade kam die Mail für die Traffic-Überschreitung von Server 92352 und promt war die Kiste down.
Am 15.05 erhielt ich um 17:22 eine E-Mail, dass sowohl 98708 als auch 92352 den Inklusivtraffic aufgebraucht haben und 20 Minuten später kam die Mail von Monitoring-System, dass beide System down sind.
Das gleiche Schema lässt sich mehrere Wochen zurückverfolgen, es scheint aber nicht jeden Server zu betreffen.
Gruß
Philip
ev. wird die netzwerkkarte so überlastet das deshalb kein ping etc. geht...
installier mal was damit du ne grafische auswertung hast...
dann siehste ob 0 rein raus geht oder doch etwas...
lg
PhilipM wrote:
> Da ich schon länger Kunde bin und auch schon häufiger den
> Inklusivtraffic aufgebraucht habe, wage ich zu behaupten, dass dies ein
> Bug sein muss.
Kannst du dazu Details nennen? (Servernummer)
Hast du (mit ethtool) die autonegotioation deiner Netzwerkkarte
deaktiviert? => wenn ja, wieder aktivieren
--
Felix
OVH Team
Hallo,
seit einiger Zeit sind meine Rootserver nicht mehr erreichbar, sobald der Inklusivtraffic aufgebraucht wurde. Dies äußert sich immer in 1-2 Stunden Nicht-Erreichbarkeit und auch das sofortige Bestellen von Traffic hilft nicht.
Da ich schon länger Kunde bin und auch schon häufiger den Inklusivtraffic aufgebraucht habe, wage ich zu behaupten, dass dies ein Bug sein muss.
