OVH Community, your new community space.

Festplatten Aussetzer


Steve
23.03.08, 18:13
Hi,

Connection Errors gab es heute:

Mar 23 06:50:32 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 07:47:52 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 10:35:29 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 13:24:53 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 13:46:23 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 13:50:18 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 14:13:33 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 15:12:32 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 15:39:07 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 15:45:18 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 16:31:31 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 16:35:49 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 16:47:02 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 17:47:32 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 17:59:21 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Mar 23 18:02:22 r10948 kernel: connection1:0: iscsi: detected conn error (1011)
Soeben in Konsole bekommen:
Zitat Zitat von MeinekleineKonsole
Message from syslogd@r10948 at Sun Mar 23 18:38:42 2008 ...
r10948 kernel: journal commit I/O error

pbm
23.03.08, 17:34
wegen der grafikarte, die brauch auch nen bissel , is ja onboard ... fänds aber besser von OVh , wenn die grafikarte nur 4 mb nehmen würde.

windows bieten die ja noch nich an auf den RPS kisten, oder ?

die server die ich bei ovh schon hatte , hatten alle 32 mb für grafik.

sogar der kleine kimsufi

Mem: 214944k total, 211612k used, 3332k free, 1500k buffers

MDGeist
23.03.08, 17:27
wie kommts eigentlich, dass man nur 466mb ram hat, statt 512 ?
selbst mit 1024 umrechnungsfaktor fehlen da einige mb...

pbm
23.03.08, 16:57
hab seit gestern munin drauf

http://bier.mine.nu/munin/localhost/localhost-cpu.html

un Serverstats

http://bier.mine.nu/serverstats/detail.php?graph=1

sind schon dicke aussetzer die man da sieht.

bis 99,9 % iowait werden webseiten noch ausgeliefert , erst bei vollen 100% hängt alles

MDGeist
23.03.08, 14:29
gerade eben wieder einen 2:35 langen hänger gehabt... mitten beim löschen einer 4gig datei

F4RR3LL
23.03.08, 14:25
kann ich leider grade nicht nachschaun bin auf arbeit... reiche ich heute abend nach.

MDGeist
23.03.08, 12:30
ip deines sans ??

F4RR3LL
23.03.08, 11:46
Mich würde interessieren ob OvH hier zwei verschiedene testconfigurationen ausgeliefert hat. Denn meine hdparm tests liegen zwar meist nur bei 5-6 MB aber das Teil ist stabil, macht keine Probleme und rennt seit 2 Tagen wie am Schnürchen. Einziger nachteil das ruckeln auf der Console manchmal. Aber ansonsten passt alles. Mails werden sofort ausgegeben usw.

Fritz
23.03.08, 11:24
Zitat Zitat von pendulum
Wie kann man sowas als marktreif bezeichnen?....Hätte ich für die Box gelöhnt, wäre ich jetz wohl ziemlich angefressen.
Zitat Zitat von Avarus;
werde ich mal kurz testen, aber ich glaube nicht, dass ich verlaengern werde
Zitat Zitat von Steve;
Würde mich interessieren, ob ovh einen Plan B hat
Ich persönlich betrachte die 50 kostenlosen Server schon als Plan B und 'erweiterten Betatest'.
Ich denke nicht, dass OVH die Dinger im großen Stil schon ausliefert.

Es liegt nicht nur an den sehr optimistischen Ankündigungen, sondern auch an unserer Ungeduld. Es sollte eben noch keiner diese neue Serverklasse für wichtige produktive Projekte einplanen. Lasst uns munter weiter testen, sachliches Feedback geben, und erst wirklich meckern, wenn wir dafür bezahlen müssen.

Gruß Fritz

pendulum
23.03.08, 06:41
Seit gestern irgendwas vor 10 hab ich den RPS im "Koma" gelassen. Sprich ISCSI Verbindung war kaputt und nix ging mehr.
Monitoring meckert nicht und Support hat auch nicht eingegriffen. Liegt wohl daran, dass der RPS auf Pings antwortet. Das ist aber auch alles was er in dem Zustand noch macht.
Man kann sich nichtmal mehr einloggen.

=> Monitoring muss verbessert werden. Ich will nich wissen wieviele RPS brach liegen ohne dass ihre Herrchen es wissen.

Schade dass Wochenende is, da werden die meisten vom Kundendienst wohl leider nicht arbeiten. Montag is auch noch Feiertag... dabei würd ich echt gerne mal ein paar Worte von OVH zur Situation hören, damn

Code:
6:40 Hard reboot über Manager
6:43 login, emerge von glibc gestartet
6:57 ISCSI tot -> hard reboot
Hätte ich für die Box gelöhnt, wäre ich jetz wohl ziemlich angefressen.

Hm nach nem reboot kommt der RPS nichtmehr hoch. Support hat ihn in den rescue pro versetzt damit ich den Fehler beheben kann. Die Frage ist: wie lautet das root Passwort? Mein altes ist es auf jeden Fall nicht und in der Mail steht auch kein neues.
Was mir auch komisch vorkommt: in dem Fehlerbericht steht dass der Server keine Konfiguration für eth0 hat. Ich erinnere mich aber nicht daran etwas geändert zu haben. Das einzige, was ich gemacht hab. war emerge -avuDN system.

MDGeist
22.03.08, 23:36
hdparm beachtet leider nich die ausfälle ;<
denn wenns nich geht, wartet es ja einfach und wird dann ausgeführt wenns system wieder speed liefert

Steve
22.03.08, 22:29
Von mir auch ein paar:

Code:
hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   20 MB in  3.12 seconds =   6.40 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   28 MB in  3.14 seconds =   8.93 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:  hdparm -t /dev/sda
 32 MB in  3.16 seconds =  10.14 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.25 seconds =  10.48 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.10 seconds =  10.98 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.17 seconds =  10.72 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.09 seconds =  11.01 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.09 seconds =  10.99 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.10 seconds =  10.96 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.09 seconds =  10.99 MB/sec
r10948:/var/log# hdparm -t /dev/sda

/dev/sda:
 Timing buffered disk reads:   34 MB in  3.11 seconds =  10.95 MB/sec

Fritz
22.03.08, 22:22
der muss sich warmlaufen

habe ein paar mal hintereinander hdparm -t /dev/sda gestartet:

Code:
 Timing buffered disk reads:    8 MB in  3.51 seconds =   2.28 MB/sec
 
 Timing buffered disk reads:   14 MB in  3.12 seconds =   4.49 MB/sec
 
 Timing buffered disk reads:   18 MB in  3.29 seconds =   5.47 MB/sec
 
 Timing buffered disk reads:   26 MB in  3.49 seconds =   7.46 MB/sec
 
 Timing buffered disk reads:   30 MB in  3.10 seconds =   9.68 MB/sec
 
 Timing buffered disk reads:   32 MB in  4.12 seconds =   7.77 MB/sec
 
 Timing buffered disk reads:   34 MB in  3.41 seconds =   9.98 MB/sec
 
 Timing buffered disk reads:   34 MB in  3.12 seconds =  10.91 MB/sec
 
 Timing buffered disk reads:   34 MB in  3.09 seconds =  11.01 MB/sec
 
 Timing buffered disk reads:   34 MB in  3.09 seconds =  11.00 MB/sec
 
 Timing buffered disk reads:   32 MB in  3.03 seconds =  10.56 MB/sec
 
 Timing buffered disk reads:   34 MB in  3.10 seconds =  10.96 MB/sec
 
 Timing buffered disk reads:   32 MB in  3.03 seconds =  10.55 MB/sec
 
 Timing buffered disk reads:   34 MB in  3.17 seconds =  10.72 MB/sec
 
 Timing buffered disk reads:   32 MB in  3.04 seconds =  10.54 MB/sec
 
 Timing buffered disk reads:   34 MB in  3.10 seconds =  10.97 MB/sec

Steve
22.03.08, 22:20
Würde mich interessieren, ob ovh einen Plan B hat, bzw. was genau unternommen, damit diese Probleme mit iSCSI aufhören

avarus
22.03.08, 22:07
eh ja...also wenn ich denn mal mein Spielzeug auch bekomme, werde ich mal kurz testen, aber ich glaube nicht, dass ich verlaengern werde .

Fritz
22.03.08, 22:05
Die Abstände werden jetzt immerhin größer
Solche Meldungen bekomme ich 10x pro Sekunde

Code:
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x3
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x2b
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0xf
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x0
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x4f
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x13
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x6f
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x5f
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x31
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x4b
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x9
Mar 22 21:52:08 stock kernel: iscsi: dropping ctask with itt 0x7b
das werden wohl keine Fehler sein.


eher so etwas:

Code:
Mar 22 20:42:58 stock kernel:  connection1:0: iscsi: detected conn error (1011)
Mar 22 21:19:08 stock kernel:  connection1:0: iscsi: detected conn error (1011)
Mar 22 21:23:01 stock kernel:  connection1:0: iscsi: detected conn error (1011)
Mar 22 21:33:16 stock kernel:  connection1:0: iscsi: detected conn error (1011)

MDGeist
22.03.08, 21:48
Zitat Zitat von Steve
Code:
Mar 22 19:11:42 r10948 kernel: iscsi: dropping ctask with itt 0x21
Mar 22 21:39:42 r10948 kernel: iscsi: dropping ctask with itt 0x50
Die Abstände werden jetzt immerhin größer


Code:
Mar 22 21:38:27 stock kernel:  connection1:0: iscsi: detected conn error (1006)
Mar 22 21:38:28 stock kernel: iscsi: dropping ctask with itt 0x19
Mar 22 21:38:28 stock kernel: iscsi: dropping ctask with itt 0x4c
Mar 22 21:40:55 stock kernel: iscsi: dropping ctask with itt 0x6c
Mar 22 21:40:55 stock kernel: iscsi: dropping ctask with itt 0x60
Mar 22 21:40:55 stock kernel: iscsi: dropping ctask with itt 0x43
Mar 22 21:40:55 stock kernel: iscsi: dropping ctask with itt 0x74
Mar 22 21:40:55 stock kernel: iscsi: received itt 202000c expected session age (0)
Mar 22 21:40:55 stock kernel:  connection1:0: iscsi: detected conn error (1010)
Mar 22 21:42:29 stock kernel: iscsi: dropping ctask with itt 0x13
Mar 22 21:42:29 stock kernel: iscsi: dropping ctask with itt 0x59
Mar 22 21:42:29 stock kernel: iscsi: dropping ctask with itt 0x20
Mar 22 21:42:29 stock kernel: iscsi: dropping ctask with itt 0x0
Mar 22 21:42:29 stock kernel: iscsi: dropping ctask with itt 0x17
Mar 22 21:42:29 stock kernel: iscsi: dropping ctask with itt 0x15
Mar 22 21:44:18 stock kernel: iscsi: dropping ctask with itt 0x1
Mar 22 21:44:18 stock kernel: iscsi: dropping ctask with itt 0x40
Mar 22 21:44:18 stock kernel: iscsi: dropping ctask with itt 0x5f
Mar 22 21:44:18 stock kernel: iscsi: dropping ctask with itt 0x7e
Mar 22 21:44:18 stock kernel: iscsi: dropping ctask with itt 0x5b
Mar 22 21:44:18 stock kernel: iscsi: dropping ctask with itt 0x77
Mar 22 21:44:18 stock kernel: iscsi: dropping ctask with itt 0x61

Steve
22.03.08, 21:39
Code:
Mar 22 19:11:42 r10948 kernel: iscsi: dropping ctask with itt 0x21
Mar 22 21:39:42 r10948 kernel: iscsi: dropping ctask with itt 0x50
Die Abstände werden jetzt immerhin größer

Steve
22.03.08, 20:24
Letzter Aussetzer war bei "mir" 19:11:42, also mehr als eine Stunde kein Fehler mehr

pbm
22.03.08, 20:24
Zitat Zitat von F4RR3LL
Aber das problem scheint nur bei den 91,121ern zu sein bei den 87ern ist alles grün.
Hi

also ich hab nen 87.98.180.xxx er ip (eth0:0)

die 91.121.196.73 is wohl die ip der "Festplatte" bei mir (eth0)

hätte ich wohl im ersten post mit hinzuschreiben sollen.

pendulum
22.03.08, 20:03
Zitat Zitat von avarus
hrm...gefaellt mir nicht . Am meisten wirds wohl bei MySQL in Verbindung mit MyIsam zu Problemen fuehren.
Also da mySQL + MyISAM laufen zu lassen grenzt schon fast an Fahrlässigkeit. Datenverlust vorprogrammiert.

Die Beobachtungen von Steve kann ich unterschreiben. Die letzten 3 Aussetzer:
17:46, 18:02 und 18:40

Wohlgemerkt sind das die Aussetzer, die er noch loggen konnte. Bei einem abrupten Crash kann er ja nichtmal mehr ins Log schreiben.

F4RR3LL
22.03.08, 19:56
Aber das problem scheint nur bei den 91,121ern zu sein bei den 87ern ist alles grün.
Nutzt OvH unterschiedliche TestConfigs ?
Muss ja ne ursache haben. Mein RPS schnurrt wie nen kätzchen.

avarus
22.03.08, 19:29
hrm...gefaellt mir nicht . Am meisten wirds wohl bei MySQL in Verbindung mit MyIsam zu Problemen fuehren.

pendulum
22.03.08, 19:26
Und die ISCSI Verbindung lässt sich auch nicht neustarten denn dazu müsste er die config Datei lesen... von der Festplatte... per ISCSI...

Monitoring bringt da übrigens auch nix, da dabei nicht die Festplatte bzw die ISCSI Verbindung überprüft wird.

Ich würde gerne mal ein paar Sätze von OVH dazu hören.

Steve
22.03.08, 19:22
Hab die Logfiles mal durchgeschaut, im Schnitt würde ich sagen stürzt iscsi alle 15-20 Minuten ab und startet dann (nicht immer unmittelbar!) neu.

Die Bezeichnung "marktreif" trifft wohl eher auf den "Marktplatz" = lateinisch "Forum" zu

pendulum
22.03.08, 19:08
Code:
top - 19:10:10 up  1:51,  2 users,  load average: 3.00, 2.99, 2.83
Tasks:  54 total,   2 running,  51 sleeping,   0 stopped,   1 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,  0.0%id,100.0%wa,  0.0%hi,  0.0%si,  0.0%st
Seit einigen Minuten mal wieder... Wie kann man sowas als marktreif bezeichnen?

Fritz
22.03.08, 18:56
87.98.144.xxx
Gestern geliefert mit Gentoo Unix-Bench 106

Code:
hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   2168 MB in  2.00 seconds = 1083.59 MB/sec
 Timing buffered disk reads:   22 MB in  3.12 seconds =   7.05 MB/sec
Hatte nachmittags einen Fehlversuch bei Ubuntu-Neuinstallation
(iscsi -ausfall mitten in Neuinstallation)

2. Versuch war ok, Ubuntu läuft seit 22.03.08 17:47
Unix-Bench 122.7

Code:
hdparm -tT /dev/sda
 Timing cached reads:   1116 MB in  2.00 seconds = 557.52 MB/sec
Timing buffered disk reads:   12 MB in 63.59 seconds = 193.25 kB/sec
Code:
hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads:   24 MB in  3.01 seconds =   7.98 MB/sec
Code:
hdparm -T /dev/sda
 Timing cached reads:   1128 MB in  2.00 seconds = 563.88 MB/sec

Steve
22.03.08, 18:39
Also arbeiten auf dem System ist schwer möglich, Festplatte "hängt" schon wieder, leider startet iscsi seit 5 Minuten nicht mehr neu.

Steve
22.03.08, 16:34
Hi,

kann das bestätigen:
Code:
Mar 22 16:04:28 r10948 kernel:  connection1:0: iscsi: detected conn error (1011)
Mar 22 16:04:28 r10948 kernel: iscsi: host reset succeeded
Mar 22 16:04:28 r10948 kernel: iscsi: dropping ctask with itt 0x4d
Mar 22 16:04:28 r10948 kernel: iscsi: dropping ctask with itt 0x15
Mar 22 16:04:28 r10948 kernel: iscsi: dropping ctask with itt 0x30
Mar 22 16:04:28 r10948 kernel: iscsi: dropping ctask with itt 0x27
Mar 22 16:08:00 r10948 kernel: iscsi: dropping ctask with itt 0x4
Mar 22 16:08:00 r10948 kernel: iscsi: dropping ctask with itt 0x16
Mar 22 16:11:41 r10948 kernel: iscsi: dropping ctask with itt 0x77
Mar 22 16:11:41 r10948 kernel: iscsi: dropping ctask with itt 0x37
Mar 22 16:11:41 r10948 kernel: iscsi: dropping ctask with itt 0x3f
Mar 22 16:11:41 r10948 kernel: iscsi: dropping ctask with itt 0x5a
Mar 22 16:23:12 r10948 kernel: iscsi: dropping ctask with itt 0x79
Mar 22 16:23:12 r10948 kernel: iscsi: dropping ctask with itt 0x57
Mar 22 16:23:12 r10948 kernel: iscsi: dropping ctask with itt 0x68
Mar 22 16:23:12 r10948 kernel: iscsi: dropping ctask with itt 0x4
Mar 22 16:23:12 r10948 kernel: iscsi: dropping ctask with itt 0x35
Mar 22 16:23:12 r10948 kernel: iscsi: dropping ctask with itt 0x11
Mar 22 16:23:12 r10948 kernel: iscsi: dropping ctask with itt 0x1e
Mar 22 16:23:12 r10948 kernel:  connection1:0: iscsi: detected conn error (1011)
Mar 22 16:23:13 r10948 kernel: iscsi: host reset succeeded
EDIT: Und das ist nur ein "kleiner" Auszug

EDIT2: @pbm: Wir sind ja sozusagen jetzt Nachbarn

Gruß,

Stefan

F4RR3LL
22.03.08, 14:06
87.98 keine Aussetzer.. aber das Arbeiten auf der Console ist ...ruppig

MDGeist
22.03.08, 13:07
91.121.199.254 < einige aussetzer bisher

jessica
22.03.08, 12:42
Meine RPS IP ist eine 87.98 und hatte seit gestern keine Aussetzer ?

gunnarh
22.03.08, 09:52
Zitat Zitat von pendulum
Nachtrag: hard Reboot durchgeführt über Manager. Mail von OVH sagt RPS sei anpingbar. Bei 100% Packetloss erscheint mir das aber eher unwahr
Die Mail von OVH kann schon stimmen - die checken nicht die "offizielle" IP beim PING-Test sondern die iSCSI IP. Wenn Du den Server neu startest bekommt er die auf eth0 aufkonfigurierte inoffizielle IP recht rasch per DHCP und ist über diese auch pingbar. Die offizielle IP wird erst im Laufe des Boots statisch dazukonfiguiert auf eth0:0 und ist daher erst zu einem späteren Zeitpunkt pingbar.

sledge0303
22.03.08, 07:45
Die IPs vom RPS haben alle 91.121! Es kommt auf die 3. Zahl an wie 194, 195...

MDGeist
22.03.08, 04:08
kann das mit dem 91.121 bestätigen

hatte ebenfalls lange aussetzer , völlig random
kenne noch einen, der ebenfalls im subnetz ist und zeitgleich mit mir aussetzer hat

pendulum
22.03.08, 03:49
Langsam hegt sich mir der Verdacht, dass es am 91.121. Subnet liegt. Andere scheinen diese Probleme nicht zu haben.

Grad ein soft reboot durchgeführt aber die Kiste kommt nichtmehr hoch. Mail von OVH is da. Mal schaun was die Techniker berichten.

Nachtrag: hard Reboot durchgeführt über Manager. Mail von OVH sagt RPS sei anpingbar. Bei 100% Packetloss erscheint mir das aber eher unwahr

Bisheriges Fazit: +

pbm
22.03.08, 03:34
Wird das in Zukunft noch behoben mit den ständigen Ausetzern der Festplatte ?

es tritt unregelmässig auf und dauert unregelmässig lange an.

Die wait geht dann hoch auf 100%
weiteres arbeiten auf der maschine ist dann nicht möglich(putty sessions bleiben offen,nur eingaben , downloads,mails,web einfach alles geht dann nicht.)

Mein System ist ein Debian4 etch, Ich denk mal an meiner install/config wird es nicht liegen.

Code:
top - 01:35:54 up 1 day,  4:10,  3 users,  load average: 2.89, 2.86, 3.12
Tasks:  88 total,   1 running,  87 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,  0.0%id,100.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    477656k total,   463396k used,    14260k free,     6160k buffers
Swap:   522104k total,       24k used,   522080k free,   351860k cached
in den logs findet sich sowas

Code:
Mar 22 03:11:51 r10949 kernel: iscsi: dropping ctask with itt 0x39
Mar 22 03:11:51 r10949 kernel: iscsi: dropping ctask with itt 0x65
Mar 22 03:11:51 r10949 kernel: iscsi: dropping ctask with itt 0x5a
Mar 22 03:11:51 r10949 kernel: iscsi: dropping ctask with itt 0x42
Mar 22 03:11:51 r10949 kernel: iscsi: dropping ctask with itt 0x3d
Mar 22 03:11:51 r10949 kernel: iscsi: dropping ctask with itt 0x2b
Mar 22 03:15:32 r10949 kernel: iscsi: dropping ctask with itt 0x4e
Mar 22 03:15:32 r10949 kernel: iscsi: dropping ctask with itt 0x8
Mar 22 03:15:32 r10949 kernel: iscsi: dropping ctask with itt 0x6c
Mar 22 03:15:32 r10949 kernel: iscsi: dropping ctask with itt 0x35
Mar 22 03:15:32 r10949 kernel: iscsi: dropping ctask with itt 0x19
Mar 22 03:15:32 r10949 kernel: iscsi: dropping ctask with itt 0x31
Mar 22 03:15:32 r10949 kernel: iscsi: dropping ctask with itt 0x71
Mar 22 03:17:07 r10949 kernel:  connection1:0: iscsi: detected conn error (1011)
Mar 22 03:17:07 r10949 kernel: iscsi: host reset succeeded

Code:
Mar 21 12:42:20 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 12:42:20 r10949 iscsid: connection1:0 is operational after recovery (4 attempts)
Mar 21 13:38:22 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 13:38:22 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 21 17:31:58 r10949 ntpdate[994]: step time server 87.98.159.36 offset 0.158867 sec
Mar 21 17:37:33 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1010) state (3)
Mar 21 17:37:33 r10949 iscsid: connection1:0 is operational after recovery (4 attempts)
Mar 21 17:57:24 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 17:57:25 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 21 18:01:47 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 18:01:47 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 21 18:11:40 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 18:11:40 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 21 18:40:19 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 18:40:19 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 21 19:46:59 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 19:47:01 r10949 iscsid: connect failed (111) 
Mar 21 20:03:50 r10949 iscsid: connect failed (113) 
Mar 21 20:03:50 r10949 last message repeated 4 times
Mar 21 20:05:15 r10949 last message repeated 73 times
Mar 21 20:05:15 r10949 iscsid: connect failed (111) 
Mar 21 20:05:15 r10949 last message repeated 2 times
Mar 21 20:05:15 r10949 iscsid: connection1:0 is operational after recovery (86 attempts)
Mar 21 20:05:15 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 20:05:15 r10949 iscsid: connection1:0 is operational after recovery (21 attempts)
Mar 21 20:05:15 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 20:05:15 r10949 iscsid: connection1:0 is operational after recovery (6 attempts)
Mar 21 20:05:15 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 20:05:15 r10949 iscsid: connection1:0 is operational after recovery (9 attempts)
Mar 21 20:05:15 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 21 20:05:15 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 21 21:26:47 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1010) state (3)
Mar 21 21:26:48 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 21 21:47:23 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1006) state (3)
Mar 21 21:47:23 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (1)
Mar 21 21:47:23 r10949 iscsid: connection1:0 is operational after recovery (4 attempts)
Mar 21 23:49:18 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1006) state (3)
Mar 21 23:49:18 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (1)
Mar 21 23:49:18 r10949 iscsid: connection1:0 is operational after recovery (4 attempts)
Mar 22 00:01:48 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1006) state (3)
Mar 22 00:01:48 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 22 00:04:05 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1010) state (3)
Mar 22 00:04:05 r10949 iscsid: connection1:0 is operational after recovery (4 attempts)
Mar 22 00:06:36 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3)
Mar 22 00:06:36 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 22 01:19:27 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1006) state (3)
Mar 22 01:19:27 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
Mar 22 01:41:53 r10949 iscsid: Kernel reported iSCSI connection 1:0 error (1010) state (3)
Mar 22 01:41:53 r10949 iscsid: connection1:0 is operational after recovery (2 attempts)
als eth0 hab ich "91.121.196.73" (san ip)
als eth0:0 hab ich "87.98.180.xxx" (server ip)
ein reboot funktioniert nicht immer, wohl wegen diesen aussetzern.

wenn es dann extrem lange ist, kommen immer mails von OVH das ein defect vorliegt un sich ein Technicker drum kummern wird.

Ich kann nur hoffen das dies in Zukunft behoben wird.

mfg

###############EDIT###############
Munin Stats
http://bier.mine.nu/munin/localhost/localhost-cpu.html
un Serverstats
http://bier.mine.nu/serverstats/detail.php?graph=1