mSP mit debian Abstürze
Würde nenn etwas älteren SP gegen nenn mSP mit Intel NIC Tauschen wenn jemand Interesse hat, bin Mit dem sehr zufrieden nur habe die Schnauze voll noch länger mich Verarschen zu lassen, denn warte bei dem älteren SP jetzt schon 4 Monate auf die Versprochene Umstellung auf das 1GB Netzwerk!
Falls jemand seinen mSP Server los werden, just mail me!
Zahle die volle Laufzeit in bar.
Danke
Nach 2 Monate wieder der erste Absturz und 5 Minuten keine IE Verbindung und auch das Monitoring Funktionierte nicht ich Hoffe nicht das das jetzt wieder Anfängt!
Bei mir ist das zum Schluss Aufgetreten wie es wollte, mal wenn der Server etwas mehr Ausgelastet war und manchmal auch wo fast keine Auslastung war da reichte es dann wenn der Speed mal ganz kurzfristig etwas höher gegangen ist musste dann aber noch nicht mal über 100MB sein, da reichten dann auch nenn Speed von 40-50MB, dass einzige was man wirklich fest sagen kann das es bei überhaupt keiner Netzwerk Auslastung überhaupt nicht Auftritt! Wirkliche dauerhafte Beseitigung unter Windows Brachte wirklich nur ein anderer NIC(Intel)
Zitat von
TF_SChw@rZl!cht
ab wann trat der Fehler bei euch eigentlich auf?
Mein XenServer hat zwar mehrere VMs durch die öfter mal Peaks von um die 100 Mbit gefahren werden aber bei mir ist der so noch nicht eingefroren oder muss da länger bzw. mehr Last liegen als nur immer so ca. 5 - 10 min?
Hast Du beim XenServer einen Pool definiert, oder arbeitest Du mit einzelnen Servern. Bei mir kommt es in unsystematischen Abständen zu Abstürzen (Netzwerk weg, auf Console wäre er wohl errechbar) des Pool Masters (und nur des Masters). Habe es jetzt immer weiter eingegrenzt, aber da es unsystematisch ist, ist es eine blöde Sache. Nur einen neuen Treiber einzusetzen hat nicht gereicht.
Zu Deiner Last Frage: Bei mir trat es nach einer knappen Stunden voller Auslastung auf, und erzeugte auch einen normalen Crash-Report. Mit dem Bios Update kam das nicht wieder.
TF_SChw@rZl!cht
07.11.13, 08:08
ab wann trat der Fehler bei euch eigentlich auf?
Mein XenServer hat zwar mehrere VMs durch die öfter mal Peaks von um die 100 Mbit gefahren werden aber bei mir ist der so noch nicht eingefroren oder muss da länger bzw. mehr Last liegen als nur immer so ca. 5 - 10 min?
Unter Linux wars Bios update, und passender aktueller Netzwerkkartentreiber.
Zitat von
panda
Bei mir scheint das auch geholfen zu haben, Support hatte das echt schnell erledigt.
(wobei ein Server irgendwie immer noch nicht 100% stabil ist, wird aber eher eine Softwaresache sein, muss ich beobachten.)
Hatte das bei mir auch erst Gedacht das das Bios Update Geholfen hatte da der Server danach 4 oder 5 Tage durch Lief und dann ging es wieder Los, aber wie schon erwähnt unter Win Server!
Zitat von
F4RR3LL
bei mir wars das Bios update. dann war alles wieder schick
Bei mir scheint das auch geholfen zu haben, Support hatte das echt schnell erledigt.
(wobei ein Server irgendwie immer noch nicht 100% stabil ist, wird aber eher eine Softwaresache sein, muss ich beobachten.)
bei mir wars das Bios update. dann war alles wieder schick
Also bei mir allerdings unter Windows Server 2008 hatte ein Austausch des Boards mit Intel NIC das Problem Gelöst, alles andere brachte nichts!
Ich habe jetzt leider auf einem Server (Xenserver mit 2.6.32.43-0.4.1.xs1.8.0.839.170780xen) auch den Absturz unter Netzwerklast erlebt. Ereignete sich zufällig, nach ca. 1 Stunde voller Netzauslastung (intern mit anderem OVH Server). Die anderen Server zeigten keine Auffälligkeiten. Den automatischen Xenserver Crashdump habe ich, weiss aber nicht was ich dort finden sollte, was mir jetzt weiterhilft, ausser das genau vor dem Crash irgendwelche Netzverbindungen abrissen.
Ich habe jetzt mal den aktuellen r8168 Treiber genommen und kompiliert, aber der Absturz ist unschön. Mit den Super Micros aus dem KS24G hatte ich nie Abstürze, welche ich nicht selbst zu verantworten hatte.
Oder gibt es neben Treiberwechsel noch andere Ansatzpunkte?
edit: scheint nicht geholfen zu haben, lasse jetzt die Hardwaretests im Rescue laufen und "hoffe" auf einen Hardwaredefekt.
edit2: die beiden stabilen Server haben ein neueres Bios... Werde mal den Support anfragen
Crashuncle
10.10.13, 05:32
Habe meinen Server mit der beschriebenen "Problem Hardware" seit einem Monat mit dem "Stock Kernel" (Linux xxxxxxxServer 3.2.0-53-generic #81-Ubuntu SMP Thu Aug 22 21:01:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux) im Einsatz und bisher weiterhin keine Probleme.
Bei den Lüftern ist das klar, wegen der Wasserkühlung ist überhaupt kein Lüfter verbaut.
Daher ist die Drehzahl natürlich 0 und das löst die Alarm-anzeige aus.
Die Temp2 kann fehlerhaft ausgelesen sein, kenne ich von meinem PC @home (OVH verbaut Desktop-Mainboards)
Intrusion-Alarm ist nicht angeschlosen darum da der Alarm.
Die Volt-zahlen sehen für mich I.O aus, da kann ich dir den Alarm nicht erklären.
LG
KS16G
Zitat von
derbroti
Bei dem Angebot steht bei RPN aber "--".
Damit der Beitrag nicht ganz unsinnig ist:
@Knasti Wie sieht denn die CPU Temperatur aus? Andere auffällige Temperaturen (Mainboard)? Stürzt der Server auch im Rescue Modus ab? Wie lang lief denn der Ram test? Also: eher 5 min oder ne Stunde. (Hab den von OVH noch nicht getestet aber manche Ram Fehler sieht man nur bei ganz bestimmten Pattern... die nicht immer alle durchgetestet werden.)
Der Ram test war wirklich sehr lange, ne Stunde bestimmt. Im Rescure ist er nicht abgestürzt. Netzwerktest ergab kein Ende zwischen OVH und Server. Server und Borwser ging sehr flott von statten.
Aber momentan
Server gestartet seit: 22 Stunde(n) 12 Minute(n) 46 Sekunde(n)
es ist Rekordverdächtig.
Temperaturen
/dev/sda: TOSHIBA DT01ACA050: 28°C
Adapter: ISA adapter
Core 0: +33.0°C (crit = +100.0°C)
Core 1: +25.0°C (crit = +100.0°C)
w83627dhg-isa-0290
Adapter: ISA adapter
Vcore: +1.14 V (min = +0.00 V, max = +1.74 V)
in1: +1.02 V (min = +1.30 V, max = +0.16 V) ALARM
AVCC: +3.38 V (min = +2.98 V, max = +3.63 V)
+3.3V: +3.38 V (min = +2.98 V, max = +3.63 V)
in4: +1.02 V (min = +0.73 V, max = +1.81 V)
in5: +1.52 V (min = +1.26 V, max = +0.49 V) ALARM
in6: +1.09 V (min = +1.98 V, max = +2.01 V) ALARM
3VSB: +3.39 V (min = +2.98 V, max = +3.63 V)
Vbat: +3.26 V (min = +2.70 V, max = +3.63 V)
fan1: 0 RPM (min = 1110 RPM, div = 64) ALARM
fan2: 0 RPM (min = 1506 RPM, div = 64) ALARM
fan3: 0 RPM (min = 727 RPM, div = 64) ALARM
fan4: 0 RPM (min = 1110 RPM, div = 64) ALARM
fan5: 0 RPM (min = 781 RPM, div = 64) ALARM
temp1: +33.0°C (high = +58.0°C, hyst = -38.0°C) sensor = CPU diode
temp2: +110.5°C (high = +80.0°C, hyst = +75.0°C) ALARM sensor = CPU diode
temp3: +34.5°C (high = +80.0°C, hyst = +75.0°C) sensor = CPU diode
cpu0_vid: +0.000 V
intrusion0: ALARM
Kann mir jemand erklären warum dort ALARM steht?
Knasti Denke mal auch das es ein anderes Prob als wie auf dem mSP ist und mit gra1 hat das auch nichts zutun, denn der mSP mit den ich Probleme hatte steht auch in gra1 und Läuft seit Motherboard Wechsel wirklich Top!
Zitat von
EvilMoe
2. Kostenlos 2.NIC für Privates Netzwerk.
Bei dem Angebot steht bei RPN aber "--".
Damit der Beitrag nicht ganz unsinnig ist:
@Knasti Wie sieht denn die CPU Temperatur aus? Andere auffällige Temperaturen (Mainboard)? Stürzt der Server auch im Rescue Modus ab? Wie lang lief denn der Ram test? Also: eher 5 min oder ne Stunde. (Hab den von OVH noch nicht getestet aber manche Ram Fehler sieht man nur bei ganz bestimmten Pattern... die nicht immer alle durchgetestet werden.)
Hardwaretest werde ich später in Angriff nehmen.
So Hardwaretest im Rescure Modus ist beendet. Festplatte, Processor und Ram ok.
Temperatur ist auch ok
194 Temperature_Celsius 0x0002 214 214 000 Old_age Always - 28 (Min/Max 19/29)
evtl. doch das gleiche Problem?
Schon mal einen Hardwaretest durchgeführt?
Das Mainboard ist von Intel!!!
Ich habe nur vergessen wo mein zurück gegebener stand. dieser steht in gra1. Könnten dort die Probleme liegen?
Solangsam glaube ich nicht mehr daran das es an der Netzwerkkarte bzw Board liegt.
Das Problem bei deinem KS2G ist 100% nicht das gleiche wie bei den problematischen mSPs, dort treten die Probleme ja nur bei den Asus Boards mit Realtek NIC auf.
@Knasti: Das DN2800MT Mainboard macht eigentlich keine Probleme.
Habe das schon lange bei OVH, sowohl als mKS als auch bei den neuen KS2G.
Nie Abstürze gehabt.
Ein Hitzeproblem kann ich zumindest für meine Kisten ausschliessen, aber kannst du ja mittels sensors und smartctl leicht selber verifizieren:
Code:
Core 0: +29.0°C (crit = +100.0°C)
Core 1: +26.0°C (crit = +100.0°C)
194 Temperature_Celsius 0x0002 214 214 000 Old_age Always - 28 (Min/Max 25/38)
bei einem KS2G in GRA.
Es könnte natürlich sein, dass evtl. dein Mainboard einen Defekt hat, weil eben eigentlich sind die Dinger unproblematisch...
Mein K2G macht die gleichen Probleme, Er ist vor 3 Stunden ebenfalls neugestartet.
CPU
Typ: Intel(R) Atom(TM) CPU N2800 ...
Geschwindigkeit: 1862.000 MHz
Cache: 512 KB
Anzahl: 4
PCI Geräte
-8086:0bf2 Intel Corporation Unknown device: 0bf2
-8086:0be2 Intel Corporation Unknown device: 0be2
-8086:27d0 Intel Corporation 82801G (ICH7 Family) PCI Express Port 1
-8086:27c8 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1
-8086:27c9 Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2
-8086:27ca Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3
-8086:27cb Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4
-8086:27cc Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller
-8086:2448 Intel Corporation 82801 Mobile PCI Bridge
-8086:27bc Intel Corporation Unknown device: 27bc
-8086:27c1 Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller
-8086:27da Intel Corporation 82801G (ICH7 Family) SMBus Controller
-8086:10d3 Intel Corporation 82574L Gigabit Network Connection
Mainboard
Typ: DN2800MT
http://www.intel.de/content/www/de/d...-dn2800mt.html
Das Mainboard ist von Intel!!!
Ich habe nur vergessen wo mein zurück gegebener stand. dieser steht in gra1. Könnten dort die Probleme liegen?
Solangsam glaube ich nicht mehr daran das es an der Netzwerkkarte bzw Board liegt.
könnte ein Hitzeproblem sein?
http://s14.directupload.net/images/130929/ndd33qbo.jpg
meiner ist unten rot umkreist, nur wo ist er oben in der liste?
Nein, aber ein anderes Mainboard, welches dann eventuell von Intel ist, und somit auch eine Intel NIC hat.
Zitat von
SlashRose
BIOS Update bringt in der Regel auch nichts, was aber auf jeden Fall was bringt ist ein anderer NIC!
Kann OVH denn beim mSP eine andere NIC (Intel) einbauen?
Versuche ich es mal
EDIT: Funktioniert sofort
Code:
Delivery: 2013-09-28
Expiration: 2013-10-01
Zitat von
EvilMoe
Stimmt, beim Auslaufdatum steht nun 2013-11-01.
Genau, so wurde mir auch vom Support bestätigt, das früher kündigen nicht geht.
Ich hab dann einfach bei Paypal das Abo storniert, und 1 stunde später stand dann plötzlich 2013-10-01 bei Expiration.
Zitat von
marius
Aber wenn du kündigst, steht da bei Expiration als Datum das Ende vom Folgemonat.
Und am 1. des nächsten Monat kommt die Rechnung.
Stimmt, beim Auslaufdatum steht nun 2013-11-01.
Zitat von
E4sTsId3
Upgrade auf den Kernel 3.11 hat nichts gebracht.
Die Crashes sind nach wie vor vorhanden.
Hardware-Checks haben nichts gezeigt.
Soll ich ein BIOS-Update anfragen?
BIOS Update bringt in der Regel auch nichts, was aber auf jeden Fall was bringt ist ein anderer NIC!
Aber wenn du kündigst, steht da bei Expiration als Datum das Ende vom Folgemonat.
Und am 1. des nächsten Monat kommt die Rechnung.
Ein Trick? Ich habe einfach einen bestellt und der wurde per PayPal nur bis zum 01.10 bezahlt.
Zitat von
EvilMoe
Interessant das man dort für nur einige Tage einen Server mieten kann, und OVH regt sich über Turnpver auf
Kann man da auch nur mit Tricks, offiziell nicht.
Interessant das man dort für nur einige Tage einen Server mieten kann, und OVH regt sich über Turnpver auf
EDIT: Vom Preis her kann man echt nicht meckern.
1. Server wurde in 5 min geliefert.
2. Kostenloser Hardware Raid.
2. Kostenlos 2.NIC für Privates Netzwerk.
3. 300 Mbit Flat (QUalität kann ich noch nichts sagen)
Zitat von
Master_of_SKT
bitte bescheid sagen wegen Speed
OVH:
100%[====================================>] 1.073.741.824 76,1M/s in 13s
Leaseweb:
100%[====================================>] 1.000.000.000 58,0M/s in 17s
Hetzner:
100%[======================================>] 104.840.234 20,1M/s in 5,5s
Upgrade auf den Kernel 3.11 hat nichts gebracht.
Die Crashes sind nach wie vor vorhanden.
Hardware-Checks haben nichts gezeigt.
Soll ich ein BIOS-Update anfragen?
Master_of_SKT
28.09.13, 14:32
bitte bescheid sagen wegen Speed
Das sieht doch schon mal gut aus, da werde ich auch mal einen Testen da man ja bei OVH keine mehr Bestellen kann!
danke ich habe es gefunden, mal sehen was da auf einem zu kommt.
Zitat von
ich123
Einfach mal nach "4 coeurs @3.5Ghz cache L3 8Mo, x64, VT" googlen. Solltet ihr dann finden
Den gleichen Server habe ich derzeit zum Testen auch, ist aber schon längst wieder gekündigt zum 01.10.
Netzwerkqualität ist einfach zu schlecht, kann man für nichts produktiv einsetzen.
Von den garantierten 300mbit/s kommen hier bei meinem Anschluss daheim wenn es gut läuft 2,5mbit/s an.
Kein Wunder, die einzigen Uplinks sind Level3, Tata und Free.
Einfach mal nach "4 coeurs @3.5Ghz cache L3 8Mo, x64, VT" googlen. Solltet ihr dann finden
Kannst es ja auch hier rein schreiben. Mich würde es auch interessieren.
Es gibt hier leider keine PM :/
Zitat von
ich123
Geht mir genauso.
Ich habe einfach einen Server bei nem anderen Anbieter bestellt.
Xeon E3 2x1TB 8GB RAM 1Gbit/s, läuft wunderbar, und das ganze für 35€.
kannst du mir sagen wo du den bestellt hast?
Zitat von
Knasti
es wurde alles versucht bis meine Haare grau wurden, ich wollte mich nicht mehr damit rumärgern.
Geht mir genauso.
Ich habe einfach einen Server bei nem anderen Anbieter bestellt.
Xeon E3 2x1TB 8GB RAM 1Gbit/s, läuft wunderbar, und das ganze für 35€.
es wurde alles versucht bis meine Haare grau wurden, ich wollte mich nicht mehr damit rumärgern.
Es besteht bei sowas aber immer auch die Möglichkeit, dass es sich um ein anderes Hardwareproblem handelt, z.B. Ram defekt oder so.
Ich hätte da Interesse halber zumindest mal einen Check im Rescue Pro gemacht.
Zitat von
Crashuncle
Also alle 3 Server sind identisch und nutzen die selbe Software, aber einer schmierte immer ab?
2 waren es, der eine mit dem Board -P8H77-M-, der war bzw ist ok. Der andere mitdem Board P8H77-M PRO, der hatte wenigstens einmal am tag einen komplett absturz, sprich neustart. Der sollte jetzt verlängert werden aber das habe ich nicht gemacht.
P.S. es sind K16ner
Crashuncle
24.09.13, 20:38
Zitat von
Knasti
Ich hatte keinen Plan mehr, ich denke das ich und ein bekannter alles versucht hatten den Server stabil zu bekommen.
Er wurde leider nix drauß. Er stürzte weiter ab. Ich habe in heute zurück gegeben, so erspare ich mir vieleeeeeeeee graue Haare.
Meine anderen beiden laufen wie ein Uhrwerk, die behalte ich auch.
Also alle 3 Server sind identisch und nutzen die selbe Software, aber einer schmierte immer ab?
Ich hatte keinen Plan mehr, ich denke das ich und ein bekannter alles versucht hatten den Server stabil zu bekommen.
Er wurde leider nix drauß. Er stürzte weiter ab. Ich habe in heute zurück gegeben, so erspare ich mir vieleeeeeeeee graue Haare.
Meine anderen beiden laufen wie ein Uhrwerk, die behalte ich auch.
Zitat von
Felix
felix3103 wrote:
> Ich hatte nun auch schon mehrere Abstürze und kann nicht auf den
> Standard Kernel wechseln, weil ich Proxmox installiert habe, was seinen
> eigenen Kernel hat. Heißt das für mich, ich kann den mSP mit Proxmox
> vergessen?
Hast du dazu ein Ticket? proxmox benutzt an sich ja immer recht aktuelle
Treiber für r8168, so das es nicht daran liegen sollte.
Nachdem ich Proxmox geupdated hab scheint es mit dem dort installierten Kernel bisher zu laufen. Ist zwar 3 Stunden danach down gewesen, allerdings laut Ticket mit Begründung "electric connector"... Vielleicht läufts ja jetzt, ich meld mich dann nochmal!
Zitat von
EvilMoe
Java und GRSec vertragen sich nicht, eventuell naechstes mal einfach mit dem
"STD"-Kernel (ohne GRSec) ausprobieren.
Wer hätte das gedacht, JAVA und die Sicherheit schließen sich tatsächlich aus
gemacht, er läuft momentan ca. 24 std ohne probleme mit Ubuntu
Ich hatte mich wohl zu früh gefreut, er ist wieder abgestürzt.
Das war kein Beschweren, denn für mich gibt es sich in diesem Punkt nichts zu Beschweren da ich ein anderes Board mit Intel NIC Bekommen habe und der Server seit dem Perfekt Läuft, dass war nur ne Feststellung die ich Persönlich nicht Verstehe, denn dieser Markt ist hart umkämpft, da macht man mit seinen Kunden nicht solch Eiertanz, oder möchtest Du wenn du einen Server Geliefert bekommst dich dann erst mit Hausgemachten Probs rumärgern müssen bevor Du denn Server dann irgendwann mal richtig Nutzen kannst? Sicherlich nicht.
Zitat von
SlashRose
Wer hier die Konstruktiven Postings bringt ist hier wohl die Frage!
Du sicher nicht, außer sich beschweren machst du nichts.
Zitat von
EvilMoe
Und was machen die dann mit den restlichen Boards?
Du bist hier nur groß in Sprüche klopfen, mehr hast du anscheinend nicht zu bieten. Überlege Dir doch erstmal was du da für ein quatsch zusammen reimst, bevor du hier was schreibst.
Wer hier die Konstruktiven Postings bringt ist hier wohl die Frage!
Java und GRSec vertragen sich nicht, eventuell naechstes mal einfach mit dem
"STD"-Kernel (ohne GRSec) ausprobieren.[/QUOTE]
Wer hätte das gedacht, JAVA und die Sicherheit schließen sich tatsächlich aus
Zitat von
SlashRose
die Lösung so einfach ist, anderes Board Verbauen Glückliche Kunden!
Und was machen die dann mit den restlichen Boards?
Du bist hier nur groß in Sprüche klopfen, mehr hast du anscheinend nicht zu bieten. Überlege Dir doch erstmal was du da für ein quatsch zusammen reimst, bevor du hier was schreibst.
Zitat von
Knasti
bei mir ist es bei dem 16G, ich habe 2 davon einen mit Raid einen ohne.
beide haben den Realtek an Board, nur das eine Board ist ein P8H77-M welches keine Probleme macht. Nur das P8H77-M PRO hängt sich jeden Tag einmal auf.
Er stürzt mit aktuellem und alten Kernel ab. Ich nutze Ubuntu.
Sowie dieses nette Board Verbaut ist sind Probleme Vorprogrammiert, aber wie gesagt es wird immer munter von OVH weiter ignoriert und fleißig weiter Verbaut, so eine Ignoranz von einem Anbieter habe ich noch nie Gesehen, obwohl die Lösung so einfach ist, anderes Board Verbauen Glückliche Kunden!
bei mir ist es bei dem 16G, ich habe 2 davon einen mit Raid einen ohne.
beide haben den Realtek an Board, nur das eine Board ist ein P8H77-M welches keine Probleme macht. Nur das P8H77-M PRO hängt sich jeden Tag einmal auf.
Er stürzt mit aktuellem und alten Kernel ab. Ich nutze Ubuntu.
felix3103 wrote:
> Ich hatte nun auch schon mehrere Abstürze und kann nicht auf den
> Standard Kernel wechseln, weil ich Proxmox installiert habe, was seinen
> eigenen Kernel hat. Heißt das für mich, ich kann den mSP mit Proxmox
> vergessen?
Hast du dazu ein Ticket? proxmox benutzt an sich ja immer recht aktuelle
Treiber für r8168, so das es nicht daran liegen sollte.
Ich hatte nun auch schon mehrere Abstürze und kann nicht auf den Standard Kernel wechseln, weil ich Proxmox installiert habe, was seinen eigenen Kernel hat. Heißt das für mich, ich kann den mSP mit Proxmox vergessen?
Crashuncle wrote:
> Ich habe wie gesagt sofort auf das normale Ubuntu Kernel gewechselt da
> ich bereits auf MG/EG Servern damit Probleme hatte -(u.a Java
> Abstürze)-.
Java und GRSec vertragen sich nicht, eventuell naechstes mal einfach mit dem
"STD"-Kernel (ohne GRSec) ausprobieren.
debian 7
ntpd ohne faults gestartet
ja ich habe etwas aus c++ kompiliert. ohne probleme aber ich hatte eine load average von 26!!!! (edit: eben nochmal getestet jetzt 48!
http://demo.ovh.eu/de/c6a7fad72c15fcacc95bff7e484aec68/)
Zitat von
ivybridge
Hast Du Ubuntu 12.04.3 LTS ? Wenn ja, versuche mal mit dem OVH Kernel den NTP Daemon zu starten. Das wird vermutlich dort enden:
Code:
kernel: ntpd[2285]: segfault at 8 ip 0000002765b30e5e sp 000003ffe30f38a0 error 4 in ntpd[2765b13000+97000]
Beim Compilieren kommt's noch drauf an, was Du compilierst.
Beide beschriebenen Segfaults gibts mit dem Ubuntu Kernel nicht.
Gruß, Klaus
ich habe sofort den 3.10.11-r8168-grs-ipv6-64 installiert konnte bisher aber noch nichts testen aber segmentation faults habe ich auf jedenfall nicht beim kompilieren.
der kernel ist aber auch nicht die lösung
http://forum.ovh.co.uk/showpost.php?...9&postcount=70
Crashuncle
17.09.13, 07:48
Ich habe den Server seit 2 Tagen online und seit mehr als 24h unter hoher Netzwerklast, mehrere hundert Torrent Benutzer laden Tag und Nacht Linux Distros, freie Filme/Musik und andere Dinge herunter. Nebenher läuft Speedtest.net sowie einige Pings, bisher läuft alles einwandfrei. Nur Transmission schmiert manchmal ab, andere Programme jedoch nicht deshalb ist das wohl ein Bug oder eine falsche Einstellung.
Ich habe wie gesagt sofort auf das normale Ubuntu Kernel gewechselt da ich bereits auf MG/EG Servern damit Probleme hatte
(u.a Java Abstürze).
Für Windows Benutzer ist das ganze natürlich bitter, da sollte OVH nur Server mit Intel NICs ausliefern bzw. generell nur noch Boards mit Intel NICs ausliefern um solchen Ärger zu vermeiden. Ich persönlich würde sogar gern 0,50€ mehr monatlich für einen Intel NIC zahlen.
Zitat von
marius
...
Und in Zukunft wird sich das durch den Treiber verursachte Problem eh erledigt haben, da im 3.11 Kernel eine neuere Version von dem Treiber vorhanden ist, die das Problem nicht mehr hat.
Auf dem OVH FTP gibt es mittlerweile auch den OVH Kernel mit dem Patch:
ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.11/
Meine Server laufen mittlerweile alle seit 23 Tage ohne Abstürze (auch mit vielen Verbindungen)
Das bestätigt ja meine Vermutung mit dem OVH "Problemkernel", OVH sollte jedem Kunden eine E-Mail senden mit dem Link zum neuen Kernel.
Nochmal zurück auf die massenhaften segmentation faults mit dem OVH Kernel - Ich habe seit 6 Uhr heute morgen auf den Ubuntu Standard Kernel 3.2.0 gewechselt, alles, was vorher gecrashed ist (vor allem der cc1plus compiler) funktioniert problemlos. Auch der NTP Daemon läuft.
In dem Zusammenhang sollten sich die Kernel-Freaks von OVH vielleicht nochmal die Konfig des OVH Kernels ansehen. Wenn Progamme zur Laufzeit segfault haben, mag das nicht so schlimm sein, deutet aber schon auf Probleme mit der Speicherverwaltung hin. Geraten Teile des Kernels unter solche Probleme, kann ich mir durchaus vorstellen, dass die Kiste einfach stehen bleibt...
Gruß, Klaus
Marius das Betrifft Windows leider auch, nur das man bei OVH immer noch nicht Weiß warum und wenn du Googelst findest du so einiges im Zusammenhang mit Windows was bis Mitte 2012 zurück geht wo außer das Board jegliche Hardware Ausgetauscht wurde und auch die Verschiedensten Treiber durch Probiert wurden und das von Experten und Usern die es wirklich drauf haben und sowie zu guter Letzt ein anderes Board Genommen wurde oder gar eine andere Netzwerkkarte peer PCI auf dem Asus Gesteckt wurde Liefen die Verschiedensten Windows Versionen, ich habe 14 Tage jeden Tag nach Arbeit bis spät Nachts das Internet Abgesucht und habe nichts Gefunden wo auch nur irgend jemand das Problem Gelöst hat unter Windows! Marius ich habe mit nicht einem Wort Gesagt das ich im Eng sowie Franz.OVH Forum Windows User Gelesen habe, ich Weiß das es sich dort um Linux Handelte da ich ja genau wie du auch Lesen kann, ich habe mich aber auch weiter im Netz wegen diesem Prob Umgesehen und wie ich schon sagte findest du im Netz und den Verschiedensten Foren Genug Windows User mit diesem Prob und nicht nur User mit Windows Server OS sondern den Verschiedensten Windows OS bis wie schon erwähnt Mitte 2012!
Das Problem mit dieser Realtek NIC, das schon so lange bekannt ist, ist ein Linuxproblem.
Bzw. mit dem Treiber der dort Standartmäßig vorhanden ist.
Das hat mit Windows überhaupt nichts zu tun, und wenn du dich ordentlich umgesehen hättest, hättest du auch gesehen dass die anderen im .co.uk und im .fr Forum die das Problem haben auch alle Linux verwenden.
Und in Zukunft wird sich das durch den Treiber verursachte Problem eh erledigt haben, da im 3.11 Kernel eine neuere Version von dem Treiber vorhanden ist, die das Problem nicht mehr hat.
Auf dem OVH FTP gibt es mittlerweile auch den OVH Kernel mit dem Patch:
ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.11/
Meine Server laufen mittlerweile alle seit 23 Tage ohne Abstürze (auch mit vielen Verbindungen)
Unter Linux kann man eventuell mit den Richtigen Treiber und Kernel Glück haben, aber unter Windows Hilft nur ein anderes Board mit anderem NIC! OVH Weiß das und trotzdem kann man mit Windows Server um ein anderes Board förmlich drum Kämpfen, habe 14 Tage Gebraucht bis ich endlich ein anderes Board mit Intel NIC Bekommen habe und seit dem es sind jetzt 7 Tage Läuft der Server Top so wie es auch sein soll, würde gerne sowie die mSP wieder in Frankreich Verfügbar sind weitere mSP Bestellen nur Frage mich ob ich dann wieder ein 14 Tägigen Kampf um ein anderes Board mir Intel NIC vor mir habe, denn so wie ich das Mitbekomme wird dieses nette Asus Board immer noch Verbaut obwohl diese Fehler seit Mitte 2012 Bekannt sind, ich Verstehe dieses Verhalten nicht, denn wenn man im Englischen und auch im Französischen OVH Forum Liest gibt es immer noch genug User die auch unter Linux das Problem immer noch nicht Behoben Bekommen!
Crashuncle
16.09.13, 18:16
Ja das sollte mal jeder mit den Abstürzen ausprobieren, auf das "Standard Kernel" zu wechseln dauert ja keine 5 Minuten
("apt-get install linux-image-server" -> "mv /etc/default/grub/06_OVHkernel /etc/default/grub/25_OVHkernel" -> "update-grub").
Bisher sieht bei mir weiterhin alles in Ordnung aus, auch die Verbindungen selbst sind stabil:
41369 packets transmitted, 41368 received, 0% packet loss, time 41399636ms
rtt min/avg/max/mdev = 18.347/19.248/44.598/0.914 ms
(Einer von 20 Pings zu verschiedenen Servern, höchstens 1 Paket ging nach Stunden verloren)
Habe auch keine Probleme mit der NIC bis jetzt, und habe den Standard Kernel drauf wegen Virtualisierung
Zitat von
Crashuncle
"segfault at 0 ip xxx sp xxx error 4 in libcurl-gnutls.so.4.2.0..."
Hm, vorab: Ich habe wohl ebenfalls das "Problem Board" mit der "Problem Realtek Nic". Das Ding läuft aber bei mir so ziemlich störungsfrei (keinerlei Abstürze).
Auf der Maschine läuft ein Gameserver mit schönen vielen variablen Verbindungszahlen, allerdings UDP (wie bei Spielen halt so üblich) zwischen 20 und 120 Verbindungen. Uptime: 11:27:56 up 5 days, 20:17, 7 users, load average: 0.20, 0.15, 0.21
Allerdings (deswegen mein Zitat mit dem Segmentation Fault):
Diverse Dinge, die auf einem älteren 64Bit KS Server mit identischer Installation reibungslos funktionieren, funktionieren hier nicht.
OS: Ubuntu 12.04.3 LTS, Kernel 3.10.9-xxxx-grs-ipv6-64 #1 SMP Wed Aug 21 11:51:59 CEST 2013 x86_64 x86_64 x86_64 GNU/Linux
Probleme z.B.:
Code:
kernel: cc1plus[1617]: segfault at 2531d4eea38 ip 0000000000bfcdf0 sp 000003ff02bf31c8 error 4 in cc1plus[400000+b8b000]
beim compilieren (funktioniert auf dem anderen System problemlos)
Code:
kernel: ntpd[2285]: segfault at 8 ip 0000002765b30e5e sp 000003ffe30f38a0 error 4 in ntpd[2765b13000+97000]
Auf der Suche dazu im Netz stieß ich auf den Satz:
If any of you use a custom linux kernel (for example ovh), use unmodified linux kernel.
Ich werde also wohl bei nächster Gelegenheit mal einen Standard-Kernel ausprobieren, denn irgendwie vermute ich, dass der OVH Kernel für meine Zwecke wohl nicht so geeignet ist...
Gruß, Klaus
Crashuncle
16.09.13, 09:22
Zitat von
EvilMoe
Dann hast du aber immer nur eine Verbindung.
Ja, natürlich nur für legale Zwecke.
Falls sich nichts geändert hat.
Verstehe, ich habe jetzt mal Transmission installiert und ein paar Linux Distros und freie Filme/Musik zu Testzwecken geladen. Im Moment sind 387 Verbindungen aktiv, Peak beim Download liegt bei 800Mbit~ und der Upload bei 150Mbit~.
Sehe bisher keine Probleme, nur Transmission ist einmal abgeschmiert:
"segfault at 0 ip xxx sp xxx error 4 in libcurl-gnutls.so.4.2.0..."
Nebenher läuft weiterhin Speedtest.net, 20 Pings~ sowie ein Download von Wikipedia.
Dann hast du aber immer nur eine Verbindung.
Ja, natürlich nur für legale Zwecke.
Falls sich nichts geändert hat.
Crashuncle
16.09.13, 08:11
Zitat von
EvilMoe
Du nutzt auch kein Windows und kein OVH Kernel
Versuche es mal mit einem großem Torrent.
Ich lasse im Moment permanent Speedtest.net in Schleife laufen
(Mit kleiner Pause zwischen jedem Test).
Code:
#!/bin/bash
#
# Written by Cxxxxx to test random Speedtest.net servers
#
echo "Infinite speedtest started, stop with CTRL+C!"
MINTIME=4 # Minimum amount of time a test normally needs
MAXID=4000 # Maximum known server ID
for (( ; ; ))
do
START_TIME=$SECONDS
ranid=$((RANDOM % $MAXID))
echo "Checking server $ranid..."
/root/speedtest-cli --server $ranid --share
ELAPSED_TIME=$(($SECONDS - $START_TIME))
if [ "$ELAPSED_TIME" -lt "$MINTIME" ]
then
echo "Probably failed ($ELAPSED_TIME secs), using different server..."
sleep 1
else
echo "Done in $ELAPSED_TIME seconds."
sleep 180
fi
done
Das Script wird keinen Coding Wettbewerb gewinnen aber es funktioniert, die headless Version vom Speedtest gibt es unter
https://github.com/sivel/speedtest-c...the-way-it-was
Ist es bei OVH überhaupt erlaubt Torrent zu nutzen?
Du nutzt auch kein Windows und kein OVH Kernel
Versuche es mal mit einem großem Torrent.
Crashuncle
16.09.13, 07:25
Ich habe bisher keine Probleme/Abstürze, die Daten von meiner mSP lauten:
OS: Ubuntu 12.04.3 LTS
Kernel: Linux nsxxxxx.ovh.net 3.2.0-53-generic #81-Ubuntu SMP Thu Aug 22 21:01:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux (Ubuntu stock!)
NIC: Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
Board: (Laut dmidecode)
Manufacturer: ASUSTeK COMPUTER INC.
Product Name: P8H77-M PRO
Version: Rev X.0x
BIOS Revision: 4.6
Gibt es bestimmte Software die diese Abstürze häufiger hervorruft?
Zitat von
ich123
Müßte ich wenn ich von Arbeit komme mal Nachsehen, im Moment kann ich nur sagen das dieses Board ein Intel NIC hat!
Wollte mal wieder nenn Zwischenstand abgeben. Und zwar habe ich Montag Vormittag nach 14 tägiger Rumquälerei mit den Technikern endlich ein anderes Board bekommen und seit dem Läuft es bisher, ich Hoffe das es jetzt auch so bleibt und das Problem damit Behoben ist nur die Zeit um sich dessen sicher zu sein ist noch zu kurz gerade auch weil ich nach dem Board Einbau tierische Probleme hatte das OS Aufzuspielen, habe 2 Stunden gebraucht bis sich endlich das System über dem Manager Aufspielen ließ, ich Hoffe das es das jetzt aber war und ich den Server jetzt endlich normal Nutzen kann!
Zitat von
Crashuncle
Ich denke eine offizielle Stellungsnahme dazu wäre angebracht.
Das wäre mehr als Angebracht, vor allem wäre es endlich mal Angebracht dieses Scheiß Board Auszutauschen um endlich das Problem zu Beheben, aber OVH macht nur eins, die Sache Versuchen Tot zu Schweigen!
Kann ich das Problem auch selber verursachen zum Testen?
Crashuncle
08.09.13, 08:23
Ich denke eine offizielle Stellungsnahme dazu wäre angebracht.
Zitat von
dabla
weil es verhältnismäßig billig ist!
Die müssen doch aber Hardware Verbauen die auch Kompatibel untereinander ist!
Zitat von
SlashRose
Der Treiber Wechsel hat auch nichts Gebracht, erst lief der Server nach Treiber Wechsel etwas über einen Tag und seit heute Stürzt der Server alle 20 Minuten ab und es wird nichts weiter gemacht als ein Hard Reboot von den Technikern und das seit 14 Tagen schon das einzige was von OVH in den 14 Tagen Geschaft hat war ein Bios Update! Ich Glaube so langsam Verliere ich die Nerven, wer Googelt der wird Bemerken das der Fehler schon seit Mitte 2012 im Netz Kursiert also warum Verbaut OVH so ein scheiß Board wo diese Fehler mit Sicherheit Bekannt gewesen ist!
OVH wird nichts tun, mein Ticket ist seit 3 Tagen unbeantwortet.
Viel Glück euch noch.
warum Verbaut OVH so ein scheiß Board wo diese Fehler mit Sicherheit Bekannt gewesen ist!
weil es verhältnismäßig billig ist!
Der Treiber Wechsel hat auch nichts Gebracht, erst lief der Server nach Treiber Wechsel etwas über einen Tag und seit heute Stürzt der Server alle 20 Minuten ab und es wird nichts weiter gemacht als ein Hard Reboot von den Technikern und das seit 14 Tagen schon das einzige was von OVH in den 14 Tagen Geschaft hat war ein Bios Update! Ich Glaube so langsam Verliere ich die Nerven, wer Googelt der wird Bemerken das der Fehler schon seit Mitte 2012 im Netz Kursiert also warum Verbaut OVH so ein scheiß Board wo diese Fehler mit Sicherheit Bekannt gewesen ist!
Zitat von
keving
Wenn es bei dir mit dem neuen klappt, kannst dich ja wieder melden.
Hilfst gewiss sogut wie allen mSP Benutzern
Werde ich machen!
Wenn es bei dir mit dem neuen klappt, kannst dich ja wieder melden.
Hilfst gewiss sogut wie allen mSP Benutzern
Ich Drücke dir auf jeden Fall die Daumen das es bei dir ja vielleicht so hinhaut, ich werde nachher auf jeden Fall mir den neusten Realtek Netzwerk Treiber Raufspielen und vielleicht habe ich ja damit Glück, denn so wie es Aussieht hält OVH das ja nicht für nötig nenn neues Board mit Intel Nick Einzubauen!
Wie gesagt hatte bis jetzt nur Probleme am Anfang von wegen Neuinstallieren, vermutlich krieg ich die Connections anzahl eh nich rein wie bei dir.
Zitat von
keving
Weiß nicht obs bei mir das BIOS war, hab aber glaube ich sowieso ne neuere Version drauf:
Mainboard: P8H77-M PRO, BIOS-Version: 1301
@Keving,
Diese Bios Version wurde mir auch Aufgespielt, dachte damit schon das alles ok ist doch nach fast 5 Tagen ging das Spiel wieder Los das der Server ständig Einfriert! Habe aber heute Gesehen das vor 3 Tagen eine neue Bios Version von Asus Rausgekommen ist was das System Stabilisieren soll und zwar hat es die Nr.14.01!
Weiß nicht obs bei mir das BIOS war, hab aber glaube ich sowieso ne neuere Version drauf:
Mainboard: P8H77-M PRO, BIOS-Version: 1301
Zitat von
ich123
Treiberupdate hat die Abstürze nur verzögert, d.h. Server ist erst nach ~4 Tagen abgestürzt.
Wird unter Windows wahrscheinlich ähnlich sein.
Denke ich mal auch, war nach dem Bios Update auch so, da ist er erst fast 5 Tage Gelaufen und dann plötzlich gingen die Abstürze alle paar Stunden wieder weiter und das Beste ist wie ich ebbend Gesehen habe, der link den ich vom Admin Geschickt bekommen habe wo ich mir den Treiber von Asus Downloaden soll, dass sind die alten Treiber von Realtek vom Januar! Hab Gesehen das von Asus ein weiteres Bios Update gibt, was das System Stabilisieren soll!
Treiberupdate hat die Abstürze nur verzögert, d.h. Server ist erst nach ~4 Tagen abgestürzt.
Wird unter Windows wahrscheinlich ähnlich sein.
Zitat von
ich123
Das keiner antwortet wird an der Priorität liegen.
Geht mir ähnlich, Ticket seitdem 14.08 offen.
Ich werde den Server auslaufen lassen, es bringt einfach nichts, weil OVH nichts unternimmt.
Habe Mittlerweile endlich ne Antwort Bekommen und zwar soll ich es mit nenn Update des Realtek Treiber Versuchen, warum denn auch das Problem mit nenn anderem NIC Sprich Board Beheben, man kann doch noch Wochen den Kunden Testen Lassen, geht doch nur schon 10 Tage das ganze spiel, ich Zahle doch gerne noch Wochen für ein Server ohne ihn Nutzen zu können! Warum einfach wenn es auf Kunden Kosten auch umständlich geht! Und von den alten SP mal ganz zu Schweigen, wo man nun schon ich Glaube 2 Monate auf die Umstellung auf 1GB Anbindung wartet, ja ich Weiß, ist Kulanz!!!
Zitat von
SlashRose
Ich Verstehe das Verhalten von OVH einfach nicht, mein mSP Friert seit Gestern ständig wieder fest, doch das einzige was die Techniker immer machen ist ein Hard Reboot, doch die müssten doch mal Merken das ihr Hard Reboot alle 2-3 Stunden nicht das Problem Behebt und man vielleicht mal andere Schritte Einleiten müsste und auf das laufende Ticket gibt es keine Antwort vom zuständigen Admin, was soll dieses Verhalten bin mit meiner Geduld langsam am Ende!
Das keiner antwortet wird an der Priorität liegen.
Geht mir ähnlich, Ticket seitdem 14.08 offen.
Ich werde den Server auslaufen lassen, es bringt einfach nichts, weil OVH nichts unternimmt.
Also ich hab die volle Bandbreite obwohl im Panel nur 100mbit steht, dies wird aber noch geändert.
Abstürze hatte ich bis jetzt keine, da ich wohl nicht genügend Verbindungen hatte
Kann ich gar nicht verstehen, wo solls denn Probleme geben? Nun haben doch viele ihre Server, dann sollen sie doch damit gluecklich werden.
Mir gehts im Uebrigen auch nicht besser. Aktuell laeuft der Server mit 10mbit/s half-duplex (siehe
http://forum.ovh.de/showpost.php?p=77893&postcount=176), aber nichtmal die kommen an (aktuell ca. ~40 KB/s Down bei v4 und ~15 KB/s bei v6)
So laesst sichs doch arbeiten.
Der OVH-Support leugnet per E-Mail+Telefon, dass es überhaupt ein Problem gäbe.....Was ist hier los?
Ich Verstehe das Verhalten von OVH einfach nicht, mein mSP Friert seit Gestern ständig wieder fest, doch das einzige was die Techniker immer machen ist ein Hard Reboot, doch die müssten doch mal Merken das ihr Hard Reboot alle 2-3 Stunden nicht das Problem Behebt und man vielleicht mal andere Schritte Einleiten müsste und auf das laufende Ticket gibt es keine Antwort vom zuständigen Admin, was soll dieses Verhalten bin mit meiner Geduld langsam am Ende!
Zitat von
strex
Das scheint aktuell wohl alle zu betreffen (MSI, Asus, Asrock,..), auch Hetzner hat damit zu kämpfen und kann die Probleme nicht beheben. Da scheint wohl wirklich ein Wurm in Mainboards zu stecken, obwohl es verschiedene Hersteller betrifft. Hetzner hat auch CPU, Mainboard, RAM, Bios, Driver,.. getauscht ohne das Problem zu beheben.
Meine gekauften Supermicros (v2 ud v3) laufen, seit jeher ohne Probleme, auch wenn LAN1 als eth1 und LAN2 als eth0 erkannt wird.
möglicherweise architekturproblem?
Zitat:
Zitat von ivybridge Beitrag anzeigen
bin seit etlichen jahren kunde. sowas hab ich bisher noch nicht erlebt. qualität hat ovh schon zu bieten nur leider läuft hier was schief. hoffe das meiner keine probleme hat.
quelle?
http://forum.ovh.com/showthread.php?t=90199
thx
Zitat von
ivybridge
bin seit etlichen jahren kunde. sowas hab ich bisher noch nicht erlebt. qualität hat ovh schon zu bieten nur leider läuft hier was schief. hoffe das meiner keine probleme hat.
quelle?
http://forum.ovh.com/showthread.php?t=90199
Das scheint aktuell wohl alle zu betreffen (MSI, Asus, Asrock,..), auch Hetzner hat damit zu kämpfen und kann die Probleme nicht beheben. Da scheint wohl wirklich ein Wurm in Mainboards zu stecken, obwohl es verschiedene Hersteller betrifft. Hetzner hat auch CPU, Mainboard, RAM, Bios, Driver,.. getauscht ohne das Problem zu beheben.
Meine gekauften Supermicros (v2 ud v3) laufen, seit jeher ohne Probleme, auch wenn LAN1 als eth1 und LAN2 als eth0 erkannt wird.
Mit der Geschwindigkeit der SATA Platten wird das nichts zutun haben, denn der Fehler tritt auch auf wenn die SATA Platten mit geringer Geschwindigkeit Laufen! Die sollen wieder die Asus Boards gegen die Alt Bewährten Intel Boards Tauschen und dann Läuft das auch!
bin seit etlichen jahren kunde. sowas hab ich bisher noch nicht erlebt. qualität hat ovh schon zu bieten nur leider läuft hier was schief. hoffe das meiner keine probleme hat.
Zitat von
ich123
Ich glaube nicht dran.
Geschrieben von Oles
Wir hatten eine Probe von einem Client, der versucht,
zu debuggen. Wir haben noch nicht die Quelle des gefundenen
Problem, aber wir wissen, dass es nicht:
- CPU
- RAM
- CM
- das Netzwerk
- der Kern
- die Geschwindigkeit der SATA wir festgestellt, dass, wenn wir das tun, Operationen auf Festplatten> 200Mo/sec (dies ist noch stabil bei 150Me/sec). müssen wir noch testen verschiedene Distributionen und wir werden Seitenscheiben aussehen.
quelle?
Jup so war es, hat auch nichts gebracht, Server direkt wieder abgestürzt.
OVH hat jetzt auf mein Drängen meinen gesamten Vertrag rückabgewickelt. D.h. ich bekomme das Geld für den Server, den RIPE-Block, sowie die Failovers zurück (~ 80 €).
Schade OVH, das wird so leider nichts mit mir und der Qualität. Ich wünsche allen Kunden weiterhin rund laufende Maschinen, ich muss aufgrund eines höheren Qualitätsanspruches etwas tiefer in die Tasche greifen
Also ich kann seit heute ein Techniker irgendwas gemacht, auf jeden Fall schon mal die OS Liste durchgehen und auch installieren.
Zitat von
coresec
So, nun gab es neben dem BIOS noch einen kompletten Umtausch des RAMs. Mal sehen wie es jetzt so laeuft...
Ich glaube nicht dran.
Geschrieben von Oles
Wir hatten eine Probe von einem Client, der versucht,
zu debuggen. Wir haben noch nicht die Quelle des gefundenen
Problem, aber wir wissen, dass es nicht:
- CPU
- RAM
- CM
- das Netzwerk
- der Kern
- die Geschwindigkeit der SATA wir festgestellt, dass, wenn wir das tun, Operationen auf Festplatten> 200Mo/sec (dies ist noch stabil bei 150Me/sec). müssen wir noch testen verschiedene Distributionen und wir werden Seitenscheiben aussehen.
So, nun gab es neben dem BIOS noch einen kompletten Umtausch des RAMs. Mal sehen wie es jetzt so laeuft...
Zitat von
coresec
Das ist schlicht Unfug, da OVH bei meinem mSP mit Virtualisierung auf Basis von ESXi wirbt. Somit bewerben sie ein Produkt was nicht funktionstüchtig ist - period.
Das ist schlicht Unfug hoch 2 Bitte schauen was im Vertrag vereinbart wurde, nur das ist gültig, dort wird kein Betriebssystem garantiert.
Zitat von
dabla
Das ist so nicht richtig. Ich kenne einige Systeme die damit anstandslos funktionieren. In denen ist auch das Asus Board verbaut und auch mit dem Realtek Chip.
Das ist schlicht Unfug, da OVH bei meinem mSP mit Virtualisierung auf Basis von ESXi wirbt. Somit bewerben sie ein Produkt was nicht funktionstüchtig ist - period.
Zitat von
Steve
Die Hardware funktioniert ja offentlich nicht mit dem von OVH bereitgestellten Betriebssystem.
Das ist so nicht richtig. Ich kenne einige Systeme die damit anstandslos funktionieren. In denen ist auch das Asus Board verbaut und auch mit dem Realtek Chip.
Die Hardware funktioniert ja offentlich nicht mit dem von OVH bereitgestellten Betriebssystem.
Und zur Not muss OVH eben eine andere Netzwerkkarte bereitstellen
Wenn die Hardware funktioniert, dann hat OVH alles erfüllt was sie müssen. Für Software, und da gehören auch Treiber dazu, bist du selbst verantwortlich (Ausnahme: BIOS - das kannst du ja schlecht selbst ändern).
Dann schreibe doch Realtek mal an, dass die endlich ihren Misttreiber testen + verbessern sollen
Also das mit dem Mist würde ich weglassen, und die Anfrage natürlich freundlich verfassen
Und zur Not muss OVH eben eine andere Netzwerkkarte bereitstellen (schließlich hat OVH auch diese Hardware ausgesucht und kann nicht alles auf Misttreiber schieben; OVH ist da genauso verantwortlich).
Zitat von
EvilMoe
Dann schalte doch mal deine Torrent ab
Kannst Du auch was konstruktives Beitragen oder kannst Du nur Mist schreiben!
Im übrigen, der Fehler Besteht weiterhin, der Server hat vor kurzem wieder Abgekackt!
Zitat von
SlashRose
So Läuft mein mSP auch ganz Normal auch unter voller Last, nur wenn man Verschiedene Sachen gleichzeitig Laufen hat die aufs Netzwerk Zugreifen, dann merkt man diese merkwürdige Netzwerk Priorisierung, kann natürlich auch am Treiber von Relteak liegen, müsste ich mal Ausprobieren!
Dann schalte doch mal deine Torrent ab
Zitat von
marius
Wie gesagt, bei mir laufen mittlerweile alle 6 Kisten mit dieser NIC einwandfrei, auch unter voller Last.
Heute wurde auch Kernel 3.11 offiziell freigegeben, der hat den neueren Treiber bereits, da muss man dann also zukünftig den Treiber nicht mehr selbst installieren.
So Läuft mein mSP auch ganz Normal auch unter voller Last, nur wenn man Verschiedene Sachen gleichzeitig Laufen hat die aufs Netzwerk Zugreifen, dann merkt man diese merkwürdige Netzwerk Priorisierung, kann natürlich auch am Treiber von Relteak liegen, müsste ich mal Ausprobieren!
Zitat von
SlashRose
Das könnte ich mir auch Vorstellen, der Realtek NIC ist auf jeden Fall der größte Mist, denn nicht nur das der NIC zum Anfang fast gar nicht wollte und erst nach dem Bios Update Lief Priorisiert dieser NIC so Beschissen den Netzwerk Verkehr das ich mich fast Übergeben muss! Ich Benutze im Privaten teilweise auch Realtek aber nicht solchen Mist von Realtek wie ihn OVH da Verbaut hat!
Diese NIC ist auf ziemlichen vielen aktuellen Boards verbaut, da kann OVH nix für.
Wenn dann hat ASUS (der Hersteller von dem Board) Mist gebaut.
In dem Board was ich hier in meinem PC habe, ist zufälligerweise auch diese NIC verbaut
Wie gesagt, bei mir laufen mittlerweile alle 6 Kisten mit dieser NIC einwandfrei, auch unter voller Last.
(mit Kernel 3.10 und dem Treiber von der Realtek Webseite).
Bei meinem 7. mSP wurde ein anderes Board eingebaut.
Heute wurde auch Kernel 3.11 offiziell freigegeben, der hat den neueren Treiber bereits, da muss man dann also zukünftig den Treiber nicht mehr selbst installieren.
Wie sich das unter Windows verhält: keine Ahnung
Zitat von
marius
Ich vermute wegen Lieferproblemen seitens Intel.
Das könnte ich mir auch Vorstellen, der Realtek NIC ist auf jeden Fall der größte Mist, denn nicht nur das der NIC zum Anfang fast gar nicht wollte und erst nach dem Bios Update Lief Priorisiert dieser NIC so Beschissen den Netzwerk Verkehr das ich mich fast Übergeben muss! Ich Benutze im Privaten teilweise auch Realtek aber nicht solchen Mist von Realtek wie ihn OVH da Verbaut hat!
Zitat von
SlashRose
Ich Verstehe nicht warum OVH nicht die Altbewährten Intel Boards bei den mSP Verbaut hat, denn die haben noch nie Probleme gemacht!!!
Ich vermute wegen Lieferproblemen seitens Intel.
Zitat von
panda
Gibt es bislang eine Möglichkeit das Problem künstlich zu reproduzieren? (würde mich auch an einer "Bounty" beteiligen, wenn es unter Linux reproduzierbar wäre)
Wäre euch wirklich dankbar, da ich gerne von den alten KS24G mit Debian auf die mSP mit Xenserver umziehen will und nicht bei Trafficansturm überrascht werden möchte.
Bislang habe ich erst einen mSP und ohne Traffic merke ich keine Probleme.
Bei mir war es reproduzierbar unter Win 2008, immer wenn ich zwischen 40 und 60 gleichzeitige Verbindungen von Verschiedenen IP`s hatte!
Ich Verstehe nicht warum OVH nicht die Altbewährten Intel Boards bei den mSP Verbaut hat, denn die haben noch nie Probleme gemacht!!!
Zitat von
coresec
Heute wieder 2 Abstürze, trotz neuem BIOS.
Kündigung ist raus.
Ich erwarte von OVH an dieser Stelle eine Rückabwicklung des Vertrags (mSP + RIPE Block + Failover = 80 €), denn ich konnte das Produkt nicht einen Tag nutzen.
Also unter Win 2008 scheint das Bios Update Geholfen zu haben, der Läuft jetzt bei mir viereinhalb Tage ohne Absturz!
bei manchen war die lösung scheinbar das bios update, bei anderen ein anderer netzwerktreiber und wieder andere haben gar keine probleme
Mein Ticket wurde selber erstellt.
Gabs eigentlich ne Lösung für das Problem in Gesamt?
Doch, die Mail kam an. Allerdings laesst sich der Server ja pingen und einloggen koennte ich mich auch - wenn ich das Passwort haette. Bevor es dann heisst, dass der Server doch funktioniert, lieber mit Ticket.
EDIT: Wird im VMS nichtmal als "Down" angezeigt. Dann doch lieber sicher mit Ticket.
EDIT2:
Wir moechten Sie darueber informieren, dass unsere Techniker in etwa 15 Minuten auf Ihrem Server eingreifen werden, um folgenden Eingriff durchzufuehren:
Hardware diagnosis
Na also, mit Ticket geht's doch.
Zitat von
Dragon
Wie schoen
Hab nun mal ein Ticket eroeffnet, mal schauen wie lange das nun wieder dauert..
Hast du keine Email bekommen?
Es handelt sich um ein Problem, das die Übernahme von einem
unserer Techniker in unseren Datacenter erfordert. Dieser Eingriff
wird in Kürze erfolgen.
Sie werden per E-Mail über den Beginn das Ende dieses Eingriffs
informiert werden. Sobald das Problem gelöst wurde, wird der
Techniker Ihre Reinstallation so starten, wie von Ihnen gewünscht.
Wie schoen
Hab nun mal ein Ticket eroeffnet, mal schauen wie lange das nun wieder dauert..
Zitat von
Dragon
Auch ich habe einen mSP mit Realtek NIC bekommen. Begeisterung sieht anders aus.
Weiter testen kann ich nicht, da sich der Server nicht ins Installationssystem leiten laesst. Also war das ein kurzes Vergnuegen mit dem Server - nun geht naemlich gar nichts mehr.
Jo hier das gleiche
Der Vorgang für die Reinstallation hat folgenden Fehler gemeldet:
- SSH port stay down while loading install system !
Auch ich habe einen mSP mit Realtek NIC bekommen. Begeisterung sieht anders aus.
Weiter testen kann ich nicht, da sich der Server nicht ins Installationssystem leiten laesst. Also war das ein kurzes Vergnuegen mit dem Server - nun geht naemlich gar nichts mehr.
-- edit: falsch gelesen ---
Du hast keine Intel NIC, sondern Realtek ( die hier bei vielen zum Absturz führt )
Hier mal als kleine Info
00:00.0 Host bridge: Intel Corporation Ivy Bridge DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Ivy Bridge PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation Device 016a (rev 09)
00:14.0 USB Controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation Panther Point MEI Controller #1 (rev 04)
00:1a.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #2 (rev 04)
00:1c.0 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 1 (rev c4)
00:1c.4 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 5 (rev c4)
00:1c.6 PCI bridge: Intel Corporation Panther Point PCI Express Root Port 7 (rev c4)
00:1d.0 USB Controller: Intel Corporation Panther Point USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation Panther Point LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation Panther Point 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation Panther Point SMBus Controller (rev 04)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 09)
04:00.0 SATA controller: Marvell Technology Group Ltd. Device 9172 (rev 11)
Zitat von
EvilMoe
Ich bin aber froh das mein mSP eine Intel NIC hat
Bin zwar kein Linux Profi aber wo sehe ich das?
Abgesichert und co krieg ich die Kiste aber nur zur Info.
Zitat von
Crashuncle
Ich bedanke mich für die Antwort. Das klingt nicht sehr gut, ich habe bereits einen mSP bestellt und habe nun angst das ich ebenfalls Probleme haben werde.
Vielleicht bekommst du ein anderes Mainboard.
Zitat von
coresec
Bei OVH braucht man nichts zu kündigen.
Ich bin aber froh das mein mSP eine Intel NIC hat
Crashuncle
02.09.13, 21:23
Zitat von
ich123
Soll wohl Betriebsystem unabhängig sein
Ich bedanke mich für die Antwort. Das klingt nicht sehr gut, ich habe bereits einen mSP bestellt und habe nun angst das ich ebenfalls Probleme haben werde.
Zitat von
ich123
Hat dein mSP ein P8H77-M Board?
dmidecode sagt "P8H77-M PRO", Bios vom 10/12/2012
Hat dein mSP ein P8H77-M Board?
Gibt es bislang eine Möglichkeit das Problem künstlich zu reproduzieren? (würde mich auch an einer "Bounty" beteiligen, wenn es unter Linux reproduzierbar wäre)
Wäre euch wirklich dankbar, da ich gerne von den alten KS24G mit Debian auf die mSP mit Xenserver umziehen will und nicht bei Trafficansturm überrascht werden möchte.
Bislang habe ich erst einen mSP und ohne Traffic merke ich keine Probleme.
Zitat von
marius
Linux? Wenn ja: Realtek Treiber installiert?
Hat bei mir bei 6 von 7 Servern das Problem dauerhaft gelöst.
Debian 6, nein bisher nicht
Zitat von
Crashuncle
Treten diese Probleme unter Ubuntu definitiv nicht auf?
Soll wohl Betriebsystem unabhängig sein
Zitat von
martn
Wurde bei mir auch gemacht, leider immernoch keine verbesserung
Nur die Abstände der abstürze sind größer geworden.
Linux? Wenn ja: Realtek Treiber installiert?
Hat bei mir bei 6 von 7 Servern das Problem dauerhaft gelöst.
Heute wieder 2 Abstürze, trotz neuem BIOS.
Kündigung ist raus.
Ich erwarte von OVH an dieser Stelle eine Rückabwicklung des Vertrags (mSP + RIPE Block + Failover = 80 €), denn ich konnte das Produkt nicht einen Tag nutzen.
Zitat von
SlashRose
Bei mir sind es jetzt fast 4 Tage seit das Bios Update gemacht wurde und seit dem war kein Absturz, bin sehr zuversichtig!
Wurde bei mir auch gemacht, leider immernoch keine verbesserung
Nur die Abstände der abstürze sind größer geworden.
Crashuncle
02.09.13, 18:01
Treten diese Probleme unter Ubuntu definitiv nicht auf?
Zitat von
coresec
Ich habe nun auch ein BIOS-Update bekommen - bisher läuft er seit 24 Stunden ...
Bei mir sind es jetzt fast 4 Tage seit das Bios Update gemacht wurde und seit dem war kein Absturz, bin sehr zuversichtig!
Mit dem Treiber '8.036.00-NAPI' läuft mein Server ca 4 Tage, dann stürzt er ab.
Ich habe nun auch ein BIOS-Update bekommen - bisher läuft er seit 24 Stunden ...
Zitat von
Mitnick
Welche Netzwerkkarte hast du wenn ich fragen darf? Bei meinem Backup 24T habe ich das gleiche Phänomen.
Bei mir Läuft die Realtek® 8111F, 1 x Gigabit LAN Controller!
Zitat von
OVH_Kunde
Oh man, und ich wollte mir eigentlich die Tage einen mSP bestellen!
Wenn du Glück hast, bekommst du ein anderes Board
Zitat von
OVH_Kunde
Oh man, und ich wollte mir eigentlich die Tage einen mSP bestellen!
Mach doch... meiner läuft ohne Probleme
Oh man, und ich wollte mir eigentlich die Tage einen mSP bestellen!
Welche Netzwerkkarte hast du wenn ich fragen darf? Bei meinem Backup 24T habe ich das gleiche Phänomen.
Nach dem ich den Server von Gestern Mittag bis in die Nacht unter voller Last gehalten habe mit auch vollem Speed und sehr vielen Zugriffen von Verschiedenen IP`s und der Server wirklich Kerzen gerade Gelaufen ist und nicht mal ins Schwitzen dabei kam, würde ich mal sagen das das Problem durch das Bios Update wohl Behoben ist! Wie sieht es bei dir aus coresec?
@coresec,
das sah bei mir bis vor 24 Stunden ganz genauso aus, dann wurde die neueste BIOS Version Aufgespielt und bisher hatte ich keinen weiteren Absturz wobei man das nach 24 Std auch noch nicht Beurteilen kann, nur muss dazu sagen das ich erst heute dazu komme das genauer zu Testen und die Situation herzustellen wo er immer Abstürzte, dass Passierte immer dann wenn ich um die 40 Zugriffe von 40 Verschiedenen IPs hatte, wobei der Speed dann keine Rolle spielte!
Hier mal was bei mir im Moment abgeht. Nur Probleme mit OVH, erst bei der Bestellung und jetzt wird netmal aufs Ticket reagiert.
Habe dann heute morgen angerufen: Die Techniker in FR kümmern sich bereits um das Problem, die wissen auch noch nicht warum bei einigen mSPs es immer und immer wieder zu abstürzen kommt.
Habe den Server jetzt 5 Tage - 50 € Server + 15 € Prof. Nutzung + Failover + Ripe = ~ 75 €. Nutzen konnte ich diesen bislang nicht.
http://img22.imageshack.us/img22/4241/yxuq.png
Zitat von
marius
Warum bist du dir so sicher das es an der Netzwerkkarte liegt?
Du benutzt Windows!
Weil nach meinen Erfahrungen mit Windows und wann das Problem Auftaucht es die Netzwerkkarte sein könnte, ein Treiber Prob Denke ich aber mal eher nicht, denn nicht jeder Fehler unter Win sind Auf fehlerhafte Treiber zurück zu führen!
Zumal OVH da nicht viel machen kann, die werden sicher nicht alle Mainboards wechseln. Treiberproblem ist eben Treiberproblem und ein Problem des Kunden.
Zitat von
SlashRose
Hab dem Techniker ja Geschrieben gehabt das es an der Netzwerkkarte liegt, nur leider ist der anderer Meinung, hatte auch den Link vom Englischen OVH Board Geschickt, nur anscheinend hat er da nicht nachgesehen!
Warum bist du dir so sicher das es an der Netzwerkkarte liegt?
Du benutzt Windows!
Dieses Problem mit der Netzwerkkarte ist ein Treiberproblem unter Linux.
Und scheinbar ist dies auch nicht die Ursache bei allen.
Hab dem Techniker ja Geschrieben gehabt das es an der Netzwerkkarte liegt, nur leider ist der anderer Meinung, hatte auch den Link vom Englischen OVH Board Geschickt, nur anscheinend hat er da nicht nachgesehen!
Einige mSPs haben ja Intel Mainboards, die problemlos laufen.
Eventuell gab es Lieferengpässe, und desewegen wurde auf die Boards von ASUS zurückgegriffen.
Zitat von
SlashRose
Habe heute Morgen eine Mail von den Techniker erhalten und es wird jetzt Versucht das Problem mit einem BIOS Update das zu Beheben, bringt das nichts wird das MB Ausgetauscht! Was meint ihr, könnte ein BIOS Update das Problem Lösen, bin da nämlich etwas Skeptisch!
Wahrscheinlich nicht, bringt auch nichts beim großen H - wobei dort die Lage noch unklarer ist. Es bringt nur etwas auf ein Intel NIC umzusteigen, ich weiß immer noch nicht warum immer noch Realtek verbaut..guter der Preis eben
Und heute wieder 2 Abstürze .. bis jetzt ..
Habe heute Morgen eine Mail von den Techniker erhalten und es wird jetzt Versucht das Problem mit einem BIOS Update das zu Beheben, bringt das nichts wird das MB Ausgetauscht! Was meint ihr, könnte ein BIOS Update das Problem Lösen, bin da nämlich etwas Skeptisch!
Nach dem ich das Problem jetzt wirklich genau Beobachtet habe, bin ich der Meinung das es auch unter Win 2008 R2 mit der Netzwerkkarte oder dem Treiber zutun hat, denn es tritt jedes mal auf wenn so ca. zwischen 40-60 Verschiedene IP Zugriffe auf dem Netzwerk bzw.der Netzwerkkarte sind!
Zitat von
ich123
Den Beitrag hatte ich auch gesehen.
Allerdings hat der Typ den 3.11 Kernel auch erst seit gestern in Benutzung, das es bis dahin noch keinen Absturz gab muss nichts heißen.
Ticket ist seit Gestern offen!
Zitat von
SlashRose
Jetzt ist der Server zum 3mal jeweils im Abstand von 1 Stunde Festgefroren und Abgestürzt und nicht mehr Gebootet so das jedes Mal der Techniker den Server neu Booten musste, ich Frage mich nur wann merken die Techniker das dort ein Fehler vorliegt und jede Stunde den Server neu zu Booten nicht die Lösung ist und Greifen wirklich mal ein und Beheben das Problem und da soll man dann ruhig Bleiben!
Ticket aufmachen, (Hardware)Problem nachweisen, sonst passiert nichts.
Jetzt ist der Server zum 3mal jeweils im Abstand von 1 Stunde Festgefroren und Abgestürzt und nicht mehr Gebootet so das jedes Mal der Techniker den Server neu Booten musste, ich Frage mich nur wann merken die Techniker das dort ein Fehler vorliegt und jede Stunde den Server neu zu Booten nicht die Lösung ist und Greifen wirklich mal ein und Beheben das Problem und da soll man dann ruhig Bleiben!
Aus dem co.uk forum:
I have installed 3.11 kernel it came with the nic latest nic driver and has not crashed since fingers crossed
it was 100 percent a nice problem because the server only crashed when the nic was heavily used
Zitat von
ich123
Mein Server ist gerade mit dem Treiber '8.036.00-NAPI' nach 3 Tagen Uptime abgestürzt.
Ist bei mir mit diesem Treiber auch vorgekommen (und dem Kernel 3.2.0).
Hardwartest hab ich über mehre Stunden laufen lassen, keine Probleme.
Ich teste aktuell den Kernel von hier:
ftp://ftp.ovh.net/made-in-ovh//bzImage/latest-test
Aber wird vermutlich auch nicht helfen...
Mein Server ist gerade mit dem Treiber '8.036.00-NAPI' nach 3 Tagen Uptime abgestürzt.
Ob es an der Hardware liegt kann einfach getestet werden. Ab in den Rescue und dann für 3 bis 5 Tage volle Last auf CPU, HDD und NIC. Wenn das sauber läuft, liegt das an etwas anderes als der Hardware.
Das Verhalten mit dem Verlieren der NIC Verbindung liegt oft an ACPI, wie etwa auch bei Intel NICs. Da hilft ein einfaches "pcie_aspm=off", dass wird bei Windows nicht gehen. Eventuell im Bios ACPI deaktivieren und nochmals probieren.
Zitat von
SlashRose
Habe auf allen Servern Win2008 und überall Läuft es Top, kann mir jemand Verraten was genau der gilles.radmacher made HARD
Reboot ist? Normal gebe ich dir recht EvilMoe das ich für die Software selbst Verantwortlich bin, aber da dieses Prob schon Auftrat obwohl ich nichts am System gemacht hatte da es von Auslieferung an so war sehe ich das anders, denn so würde OVH sich das ja sehr einfach machen!
Und warum setzt du ein veraltetes System ein?
>> gilles.radmacher made HARD
Was? Ein Hard Reboot? Stromzufuhr wird unterbrochen.
>>System gemacht hatte da es von Auslieferung an so war sehe ich das >>anders, denn so würde OVH sich das ja sehr einfach machen!
Wenn das System nun mal den Last test bestanden hat, kann man schon fast ein Hardware Problem ausschließen. Dann liegt es wahrscheinlich an die Software (Treiber was auch immer), das fällt nicht in OVH sein Gebiet. Vielleicht solltest du auch ein aktuelleres Betriebssystem in Erwägung ziehen. Windows 2008 war noch nie wirklich gut.
Warum überhaupt Windows?
Zitat von
EvilMoe
Weil Windows auch nicht getestet wird. Du bist selber für die Software verantwortlich!
Vielleicht solltest du dir ein vernünftiges System anschaffen und nicht mit einem veraltetem Windows 2008 rum eiern.
Habe auf allen Servern Win2008 und überall Läuft es Top, kann mir jemand Verraten was genau der gilles.radmacher made HARD
Reboot ist? Normal gebe ich dir recht EvilMoe das ich für die Software selbst Verantwortlich bin, aber da dieses Prob schon Auftrat obwohl ich nichts am System gemacht hatte da es von Auslieferung an so war sehe ich das anders, denn so würde OVH sich das ja sehr einfach machen!
Weil Windows auch nicht getestet wird. Du bist selber für die Software verantwortlich!
Vielleicht solltest du dir ein vernünftiges System anschaffen und nicht mit einem veraltetem Windows 2008 rum eiern.
Zitat von
marius
Bevor ein Server ausgeliefert wird, wird ein Hardwaretest ausgeführt, das Ergebnis bekommst du sogar als PDF per mail.
Ich Weiß, aber ob dieser Test nun unbedingt so Aussagekräftig ist mag ich zu Bezweifeln, es waren auf dem Ausgelieferten System auch einige Treiber nicht Installiert und so stell ich mir ein korrekt Ausgeliefertes System nicht vor, jetzt hängt der Server seit 10 Minuten und Bootet gar nicht mehr! Mir ist jetzt Aufgefallen das diese hänger immer dann Auftreten wenn der Speed über 50MB hat!
Zitat von
SlashRose
im Rescue Modus mal die Hardware schecken soll, obwohl ich mich ganz ehrlich Frage warum der Techniker das nicht gleich tat, denn schließlich ist der Server ja schon fehlerhaft Ausgeliefert worden!
Bevor ein Server ausgeliefert wird, wird ein Hardwaretest ausgeführt, das Ergebnis bekommst du sogar als PDF per mail.
Zitat von
dabla
Ich habe jetzt mal etliche Verbindungen aufn Indianer losgelassen und keine Probleme
Ich wuerde nun von zwei Dingen ausgehen:
1) Der Xen-Kernel hat das Problem nicht (was ich fuer unwahrscheinlich halte) oder
2) es sind Zugriffe von vielen verschiedenen IPs noetig, um das auszuloesen.
Kontinuierliche Datentransferraten von ~100 MB/s sind gar kein Problem, solange sie nur von einer oder ein paar wenigen IPs kommen.
Ich bin einer von einigen Irren, die ihren Server fuer ein Event zur Verfuegung stellen, das jeden Freitag stattfindet und mehrere hunderttausend User hat. Der Teil davon, der sich im Chat aufhaelt (ca. 1200-1600), landet auf meinem und zwei anderen Servern (jeweils fast baugleich). Da jede Zeile Text an alle User verteilt werden muss, kommt da gerne mal einiges an I/O Last zusammen. Zu Beginn, als es noch unter 1000 waren, traten noch keinerlei Probleme auf. Als wir ueber die Tausend kamen, fing das Problem auf 2 Servern an, je nach dem wie die User verteilt waren. Der 3. macht heute noch keine Macken, obwohl er auch den 8169er Treiber drauf hat.
Warum und wieso das so ist, kann sich von uns keiner erklaeren. Fuer uns ist allerdings Fakt, dass nur der 8168b-Treiber zuverlaessig auf Dauer laeuft.
Zitat von
SlashRose
@Dragon,
danke für den Tipp, werde nach Arbeit mal mit dem Programm Nachsehen ob ich ein BlueScreen hatte, der Techniker schrieb mir heute Morgen das der Server fest Friert und ich im Rescue Modus mal die Hardware schecken soll, obwohl ich mich ganz ehrlich Frage warum der Techniker das nicht gleich tat, denn schließlich ist der Server ja schon fehlerhaft Ausgeliefert worden!
Vermutlich will der Techniker dich entscheiden lassen wann du den Test laufen lassen willst, damit er dich nicht von der Arbeit abhaelt, die du womoeglich noch beenden willst auf dem Server.
Bin gespannt, ob das irgendein Ergebnis bringt. Wenn nicht, muessen wir mal weiterschauen
@Dragon,
danke für den Tipp, werde nach Arbeit mal mit dem Programm Nachsehen ob ich ein BlueScreen hatte, der Techniker schrieb mir heute Morgen das der Server fest Friert und ich im Rescue Modus mal die Hardware schecken soll, obwohl ich mich ganz ehrlich Frage warum der Techniker das nicht gleich tat, denn schließlich ist der Server ja schon fehlerhaft Ausgeliefert worden!
Zitat von
BobDschingis
Cool, welches Programm ist das denn?
Apache Bench
BobDschingis
27.08.13, 14:42
Zitat von
dabla
Ich habe jetzt mal etliche Verbindungen aufn Indianer losgelassen und keine Probleme
Cool, welches Programm ist das denn?
Dann würde ich das auch mal testen und euch ne Refenrenz geben.
Hab Proxmox 3 (Debian Wheezy/7), mit Debian und Ubuntu dahinter laufen.
vg (nicht volume group, sondern viele grüße )
(Edit)
@dabla: Das Problem tritt dann auf, wenn viel I/O Last auf dem Netzwerkport ablaeuft. Hier trat das Problem auch erst auf, als 1000 und mehr Verbindungen pro Minute stattfanden. Vorher lief der Server teilweise Wochen ohne Probleme. Der Kernel ist dabei afaik egal, da ich damals sowohl auf dem 2.6er Kernel als auch auf dem 3.2er Kernel das gleiche Problem hatte, bis der Treiber ersetzt wurde.
Ich habe jetzt mal etliche Verbindungen aufn Indianer losgelassen und keine Probleme
Code:
Server Software: Apache/2.2.22
Server Hostname: meine.domain.de
Server Port: 80
Document Path: /
Document Length: 601681 bytes
Concurrency Level: 100
Time taken for tests: 2284.162 seconds
Complete requests: 5000000
Failed requests: 0
Write errors: 0
Total transferred: 3009820000000 bytes
HTML transferred: 3008405000000 bytes
Requests per second: 2188.99 [#/sec] (mean)
Time per request: 45.683 [ms] (mean)
Time per request: 0.457 [ms] (mean, across all concurrent requests)
Transfer rate: 1286807.50 [Kbytes/sec] received
Zitat von
marius
Here are the details of the operation performed:
No information on the screen ("black screen"). No response
to keyboard.
Mir wurde genau das gleiche vom Techniker geschrieben.
Dann wurde die Festplatte getauscht, danach kam der Server nach ~10-20mins alleine wieder, ohne Hardreboot.
@SlashRose: Das mit dem 8169/8168b Treiberproblem ist eine Linuxangelegenheit. Bei Windows wuerde ich von der Beschreibung her davon ausgehen, dass es dir einen Bluescreen liefert, den du nicht siehst. Hast du mal das Programm "BlueScreenView" versucht? Sollten Bluescreens die Ursache sein, kannst du das dort nachlesen. Windows schreibt sowas leider nicht immer in das Eventlog. Der Dump existiert aber normalerweise in jedem Fall.
(Edit)
@dabla: Das Problem tritt dann auf, wenn viel I/O Last auf dem Netzwerkport ablaeuft. Hier trat das Problem auch erst auf, als 1000 und mehr Verbindungen pro Minute stattfanden. Vorher lief der Server teilweise Wochen ohne Probleme. Der Kernel ist dabei afaik egal, da ich damals sowohl auf dem 2.6er Kernel als auch auf dem 3.2er Kernel das gleiche Problem hatte, bis der Treiber ersetzt wurde.
Xen Server 6.2
Kernel: 2.6.32.43-0.4.1.xs1.8.0.835.170778xen #1 SMP
Code:
modinfo r8168
modinfo: could not find module r8168
Code:
modinfo r8169
filename: /lib/modules/2.6.32.43-0.4.1.xs1.8.0.835.170778xen/kernel/drivers/net/r8169.ko
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew
srcversion: D513006DD24EBF2A6874B83
alias: pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias: pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias: pci:v000016ECd00000116sv*sd*bc*sc*i*
alias: pci:v00001259d0000C107sv*sd*bc*sc*i*
alias: pci:v00001186d00004300sv*sd*bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
alias: pci:v000010ECd00008136sv*sd*bc*sc*i*
alias: pci:v000010ECd00008129sv*sd*bc*sc*i*
depends: mii
modinfo r8169
filename: /lib/modules/2.6.32.43-0.4.1.xs1.8.0.835.170778xen/kernel/drivers/net/r8169.ko
version: 2.3LK-NAPI
license: GPL
description: RealTek RTL-8169 Gigabit Ethernet driver
author: Realtek and the Linux r8169 crew
srcversion: D513006DD24EBF2A6874B83
alias: pci:v00000001d00008168sv*sd00002410bc*sc*i*
alias: pci:v00001737d00001032sv*sd00000024bc*sc*i*
alias: pci:v000016ECd00000116sv*sd*bc*sc*i*
alias: pci:v00001259d0000C107sv*sd*bc*sc*i*
alias: pci:v00001186d00004300sv*sd*bc*sc*i*
alias: pci:v000010ECd00008169sv*sd*bc*sc*i*
alias: pci:v000010ECd00008168sv*sd*bc*sc*i*
alias: pci:v000010ECd00008167sv*sd*bc*sc*i*
alias: pci:v000010ECd00008136sv*sd*bc*sc*i*
alias: pci:v000010ECd00008129sv*sd*bc*sc*i*
depends: mii
also ganz normaler 8169 treiber im einsatz
Zitat von
SlashRose
@Marius,
habe auf meinem mSP genau das gleiche Problem aber unter Win 2008 R2, der Server Stürzt nach einigen Stunden so ca. nach 2-3 Stunden einfach ab und Bootet neu und Funktioniert dann für 2-3 Stunden wieder ganz Normal, daher wollte ich noch mal Nachfragen ob bei dir nach dem Treiber Wechsel jetzt das Prob noch mal Aufgetreten ist den es sind ja jetzt drei Tage Vergangen?
Ich hatte in der Tat wieder einen Absturz, allerdings nur bei einem Server, und zwar heute morgen. Die zwei Tage davor war nichts.
Ich weiß nicht ob es nach wie vor das alte Problem ist, oder ob dieser Server, der heute abgestürzt ist eventuell noch einen Hardwaredefekt oder so hat.
Bei dem Absturz heute hat auch ein Techniker einen Hardwarereset durchgeführt, davor war es immer so, dass die Server nach einer Zeit von alleine wieder erreichbar waren, ohne hard reset.
Here are the details of the operation performed:
No information on the screen ("black screen"). No response
to keyboard.
Zitat von
dabla
hab auf meinem mSP keine Probs trotz realtek chip
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 09)
Welchen Kernel verwendest du?
Den von OVH? Welche Version?
Ich habe auf meinem mSP ebenfalls Abstürze, jedoch bei VMWare ESXi. Dieser verliert einfach die Netzwerkkarte und muss hart resettet werden. Heute bereits 3 Mal.
hab auf meinem mSP keine Probs trotz realtek chip
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 09)
@Marius,
habe auf meinem mSP genau das gleiche Problem aber unter Win 2008 R2, der Server Stürzt nach einigen Stunden so ca. nach 2-3 Stunden einfach ab und Bootet neu und Funktioniert dann für 2-3 Stunden wieder ganz Normal, daher wollte ich noch mal Nachfragen ob bei dir nach dem Treiber Wechsel jetzt das Prob noch mal Aufgetreten ist den es sind ja jetzt drei Tage Vergangen?
Danke für den Link zum UK Forum
Ich habe jetzt auf einigen Servern auf einen modularen Kernel gewechselt und die Realtek Treiber installiert.
Scheint bis jetzt soweit zu funktionieren, NIC lässt sich längere Zeit auf mehr als 100mbit/s auslasten, ohne das der Server abstürtzt.
Zitat von
EvilMoe
Warum verwendest du ein altes Debian 6 wenn du die Server erst neu installiert hast?
Aufgrund von Software die noch nicht ausreichend unter Debian 7 getestet wurde.
Macht aber keinen Unterschied, da das Problem unter Debian 7 auch auftreten würde.
(siehe @ich123)
Master_of_SKT
24.08.13, 14:56
@ marius das problem hatte ich auch gehabt, ich konnte auf dem kompletten server nicht mehr zugreifen, aber laut monitoring war alles okay gewesen... hatte debian 6 am laufen gehabt
hab den server checken lassen, aber da war alles okay gewesen
Ich habe genau das gleiche Problem. Debian 7 Wheezy.
Ticket ist seitdem 14.08 offen.
Warum verwendest du ein altes Debian 6 wenn du die Server erst neu installiert hast?
Ich habe auch einen mSP und unter Last hat der keine Probleme.
EDIT: Habe auch keine Realtek wie im UK Forum.
Code:
00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05)
Moin,
angesichts dessen, dass ich auch einen mSP bestellt habe und hier nun sowas lese, werden die Erinnerungen an einen deutschen Hoster mit H wach. Dort existiert das gleiche Problem, wie es hier beschrieben wird. Bei mittlerer bis hoher Last ist der Server nicht mehr erreichbar. Beguenstigt wird dies durch den Linux-internen Treiber der Version 8169. In der Konsole las man in meinem Fall nur noch alle 5-10 Sekunden "eth0: link up" und es half nur noch ein Hardreboot, da der Server via LAN (aussen und innen) nicht mehr erreichbar war.
Finde es eigentlich unschoen, dass OVH nun auch diesen Realtekmist verbaut. Auch wenn alles nach dem Wechsel des Treibers (8168) soweit laeuft, finde ich das doch nervig, dass man sowas selbst als Kunde "beheben" muss.
I'm UK Forum war die Rede von Netzwerkkartentreibern
http://forum.ovh.co.uk/showthread.php?t=6802
Zitat von
dabla
3 unterschiedliche mSP's sind heute abgestürzt? oder ist einer 3x abgestürzt?
nein, 3 unterschiedliche jeweils 1x heute
Wie gesagt anhand der Logs lässt sich absolut nichts rausfinden.
evtl. io probs oder kernel fehler aber glaskugel ist gerade zur politur
3 unterschiedliche mSP's sind heute abgestürzt? oder ist einer 3x abgestürzt?
Hallo,
ich verwalte insgesamt 7 mSPs bei OVH, verteilt über verschiedene RZ (SBG und RBX1/3/4).
Die Server laufen seit 10 Tagen und werden seit 2 Tagen produktiv eingesetzt.
Seitdem treten auch die Probleme auf.
Allein heute sind 3 Server über den Tag verteilt einfach so abgestürzt.
In allen Fällen lassen sich anhand der Logs keine Ursachen finden.
Nach einem reboot läuft alles wieder.
OS: debian 6 (squeeze) 64bit
Standart OVH Kernel: Linux 3.8.13-xxxx-grs-ipv6-64 #4 SMP Mon Aug 5 14:37:04 CEST 2013 x86_64 GNU/Linux
Die Hardware ist bei allen Servern genau identisch.
Hat jemand ähnliche Probleme?