Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #129768 > unrolled thread

VM mit HD Fehler

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-04 07:06 +0200
    Re: VM mit HD Fehler Paul Muster <exp-311223@news.muster.net> - 2023-04-04 07:40 +0200
      Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-04 08:27 +0200
    Re: VM mit HD Fehler Marco Moock <mo01@posteo.de> - 2023-04-04 08:55 +0200
      Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-05 07:21 +0200
        Re: VM mit HD Fehler Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2023-04-05 06:23 +0000
          Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-05 08:53 +0200
        Re: VM mit HD Fehler Claus Reibenstein <creibens@gmail.com> - 2023-04-05 11:44 +0200
          Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-05 11:57 +0200
            Re: VM mit HD Fehler Claus Reibenstein <creibens@gmail.com> - 2023-04-05 13:11 +0200
    Re: VM mit HD Fehler Marcus Jodorf <m@bogomips.de> - 2023-04-04 12:14 +0200
      Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-05 07:20 +0200
        Re: VM mit HD Fehler Marcus Jodorf <m@bogomips.de> - 2023-04-05 19:03 +0200
          Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-12 07:12 +0200
            Re: VM mit HD Fehler Marcus Jodorf <m@bogomips.de> - 2023-04-13 23:43 +0200
    Re: VM mit HD Fehler Stefan Möding <Apr2023.5.kill-9@spamgourmet.com> - 2023-04-04 21:04 +0200
      Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-05 07:32 +0200
        Re: VM mit HD Fehler Michael Brand <brandm@gmx.net> - 2023-04-05 09:18 +0200
          Re: VM mit HD Fehler Jan Novak <repcom@gmail.com> - 2023-04-05 09:42 +0200
      Re: VM mit HD Fehler Tim Ritberg <tim@server.invalid> - 2023-04-05 13:13 +0200

#129768 — VM mit HD Fehler

Moin,

auf einem Proxmox Server (qemu) läuft eine VM, welche eine der 3 
virtuellen Platten gestern um 21:00 Uhr in den RO Modus setzte.

Die VM ist primäre ein Web Dienst und SMB Server im Intranet mit sehr 
vielen IO's.

Auf dem Host ist ein zfs. Dort sind keine Plattenfehler in dessen 
Platten oder im Raid selbst zu sehen. Auch ist genügend Platz auf dem 
Host und in der VM.

Im Log sehe ich diese Ausgabe:


pr  3 21:00:31 ams kernel: [37862368.830448] sd 2:0:0:2: [sdb] tag#148 
FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Apr  3 21:00:31 ams kernel: [37862368.830452] sd 2:0:0:2: [sdb] tag#148 
Sense Key : Aborted Command [current]
Apr  3 21:00:31 ams kernel: [37862368.830453] sd 2:0:0:2: [sdb] tag#148 
Add. Sense: I/O process terminated
Apr  3 21:00:31 ams kernel: [37862368.830456] sd 2:0:0:2: [sdb] tag#148 
CDB: Write(16) 8a 00 00 00 00 00 3f d4 22 08 00 00 00 b8 00 00
Apr  3 21:00:31 ams kernel: [37862368.830461] print_req_error: I/O 
error, dev sdb, sector 1070866952
Apr  3 21:00:31 ams kernel: [37862368.845488] Aborting journal on device 
sdb1-8.
Apr  3 21:00:32 ams kernel: [37862369.241844] EXT4-fs error (device 
sdb1): ext4_journal_check_start:61: Detected aborted journal
Apr  3 21:00:32 ams kernel: [37862369.242482] EXT4-fs (sdb1): Remounting 
filesystem read-only


Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?


Jan

[toc] | [next] | [standalone]

#129769

On 04.04.23 07:06, Jan Novak wrote:

> auf einem Proxmox Server (qemu) läuft eine VM, welche eine der 3 
> virtuellen Platten gestern um 21:00 Uhr in den RO Modus setzte.

Vielleicht in de.comp.virtualisierung


mfG Paul

[toc] | [prev] | [next] | [standalone]

#129770

Am 04.04.23 um 07:40 schrieb Paul Muster:
> On 04.04.23 07:06, Jan Novak wrote:
> 
>> auf einem Proxmox Server (qemu) läuft eine VM, welche eine der 3 
>> virtuellen Platten gestern um 21:00 Uhr in den RO Modus setzte.
> 
> Vielleicht in de.comp.virtualisierung

ich denke nicht, dass es ein Virtualisierungsfehler des Hostes ist, 
sondern eher mit der VM selbst.

Jan

[toc] | [prev] | [next] | [standalone]

#129771

Am 04.04.2023 um 07:06:58 Uhr schrieb Jan Novak:

> Auf dem Host ist ein zfs. Dort sind keine Plattenfehler in dessen 
> Platten oder im Raid selbst zu sehen. Auch ist genügend Platz auf dem 
> Host und in der VM.

fsck auf dem Host und Gast durchführen.

Ist der Gast oder der Host ggf. mal abgeschmiert?

[toc] | [prev] | [next] | [standalone]

#129780

Am 04.04.23 um 08:55 schrieb Marco Moock:
> Am 04.04.2023 um 07:06:58 Uhr schrieb Jan Novak:
> 
>> Auf dem Host ist ein zfs. Dort sind keine Plattenfehler in dessen
>> Platten oder im Raid selbst zu sehen. Auch ist genügend Platz auf dem
>> Host und in der VM.
> 
> fsck auf dem Host und Gast durchführen.

Habe ich gemacht. Nach 30 min war das System wieder benutzbar.


> Ist der Gast oder der Host ggf. mal abgeschmiert?


Nein. Sowohl Host als auch VM hatten eine Uptime von ~ 300 Tagen.

Jan

[toc] | [prev] | [next] | [standalone]

#129782

Jan Novak <repcom@gmail.com> wrote:

> Nein. Sowohl Host als auch VM hatten eine Uptime von ~ 300 Tagen.

Du wirst also gerne gehackt?
Oder sind die Systeme nicht vernetzt?

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    https://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#129784

Am 05.04.23 um 08:23 schrieb Ulli Horlacher:
> Jan Novak <repcom@gmail.com> wrote:
> 
>> Nein. Sowohl Host als auch VM hatten eine Uptime von ~ 300 Tagen.
> 
> Du wirst also gerne gehackt?

immer wieder gerne ;-)

> Oder sind die Systeme nicht vernetzt?

Falsches Thema hier und die Systeme sind nicht von aussen erreichbar. 
Updates (bis auf Kernel + rebboot) sind übrigens gemacht.
Bitte keine weiteren Nachrichten zur Sicherheit / Updates usw. (vor alle 
m nicht zu diesem Thread).

Jan

[toc] | [prev] | [next] | [standalone]

#129787

Jan Novak schrieb am 05.04.2023 um 07:21:

> Am 04.04.23 um 08:55 schrieb Marco Moock:
>
>> fsck auf dem Host und Gast durchführen.
>
> Habe ich gemacht. Nach 30 min war das System wieder benutzbar.

Dann war da wohl im Filesystem irgendetwas durcheinander.

> Sowohl Host als auch VM hatten eine Uptime von ~ 300 Tagen.

Da wundert mich gar nichts mehr.

Meine Rechner laufen i.d.R. nur ein paar Stunden am Stück. Nur selten
kommen die mal auf eine Uptime von mehr als 24 Stunden.

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#129788

Am 05.04.23 um 11:44 schrieb Claus Reibenstein:
> Jan Novak schrieb am 05.04.2023 um 07:21:
> 
>> Am 04.04.23 um 08:55 schrieb Marco Moock:
>>
>>> fsck auf dem Host und Gast durchführen.
>>
>> Habe ich gemacht. Nach 30 min war das System wieder benutzbar.
> 
> Dann war da wohl im Filesystem irgendetwas durcheinander.
> 
>> Sowohl Host als auch VM hatten eine Uptime von ~ 300 Tagen.
> 
> Da wundert mich gar nichts mehr.
> 
> Meine Rechner laufen i.d.R. nur ein paar Stunden am Stück. Nur selten
> kommen die mal auf eine Uptime von mehr als 24 Stunden.

Aber wir reden hier von Produktionsservern. Nicht Benutzerrechner. Die 
laufen 24/7.

Jan

[toc] | [prev] | [next] | [standalone]

#129789

Jan Novak schrieb am 05.04.2023 um 11:57:

> Am 05.04.23 um 11:44 schrieb Claus Reibenstein:
>
>> Jan Novak schrieb am 05.04.2023 um 07:21:
>> 
>>> Sowohl Host als auch VM hatten eine Uptime von ~ 300 Tagen.
>>
>> Da wundert mich gar nichts mehr.
>> 
>> Meine Rechner laufen i.d.R. nur ein paar Stunden am Stück. [...]
>
> Aber wir reden hier von Produktionsservern.

Das hatte ich übersehen. Sorry.

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#129772

Jan Novak <repcom@gmail.com> schrieb:


> Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?

Da wird sich ein Laufwerk verschluckt haben. zfs steckt das normal weg
und restauriert die Daten automatisch, solange es noch Redundanz gibt.
Aber klar, daß es eine VM nicht mag, wenn dann quasi von außen ihre
virtuelle Platte manipuliert wird, wenn der Fehler ausgerechnet
innerhalb der Datei der virtuellen Platte aufgetreten ist.

„zpool status“ sollte Dir erzählen, ob es da ein Problem gab.
Beispiel:

  pool: zroot
 state: ONLINE
  scan: resilvered 2.32M in 00:00:00 with 0 errors on Sun Apr  2 06:47:42 2023
config:

	NAME                                                         STATE     READ WRITE CKSUM
	zroot                                                        ONLINE       0     0     0
	  mirror-0                                                   ONLINE       0     0     0
	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C40FNECA6-part3  ONLINE       0     0     0
	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C40AAECA6-part3  ONLINE       0     0     0
	  mirror-1                                                   ONLINE       0     0     0
	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C405GECA6        ONLINE       0     0     0
	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C40CGECA6        ONLINE       0     0     0
	  mirror-2                                                   ONLINE       0     0     0
	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_62MA209VKDB6        ONLINE       0     0     0
	    nvme-Samsung_SSD_980_PRO_1TB_S5GXNX0T207705A             ONLINE       0     0     0
	  mirror-3                                                   ONLINE       0     0     0
	    nvme-Samsung_SSD_990_PRO_2TB_S6Z2NJ0TB10778B             ONLINE       0     0     0
	    nvme-Samsung_SSD_990_PRO_2TB_S6Z2NJ0TB10674P             ONLINE       0     0     0

errors: No known data errors


Das hier war nach einem Reset und zfs hat sich danach wieder repariert
und alles ist wieder ok.
Sollte bei Dir vergleichbar aussehen.
Dann hast Du nur noch ein Problem mit dem VM image. Da mußt Du halt
einen fsck über das ext4 Filesystem jagen.

Du solltest natürlich auch die Logs des Host checken und sehen, ob Du
herausbekommst, was die eigentlich Ursache war - also ob ein Laufwerk im
Pool vielleicht ein ernsteres Problem hat.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#129779

Am 04.04.23 um 12:14 schrieb Marcus Jodorf:
> Jan Novak <repcom@gmail.com> schrieb:
> 
> 
>> Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?
> 
> Da wird sich ein Laufwerk verschluckt haben. zfs steckt das normal weg
> und restauriert die Daten automatisch, solange es noch Redundanz gibt.
> Aber klar, daß es eine VM nicht mag, wenn dann quasi von außen ihre
> virtuelle Platte manipuliert wird, wenn der Fehler ausgerechnet
> innerhalb der Datei der virtuellen Platte aufgetreten ist.
> 
> „zpool status“ sollte Dir erzählen, ob es da ein Problem gab.
> Beispiel:
> 
>    pool: zroot
>   state: ONLINE
>    scan: resilvered 2.32M in 00:00:00 with 0 errors on Sun Apr  2 06:47:42 2023
> config:
> 
> 	NAME                                                         STATE     READ WRITE CKSUM
> 	zroot                                                        ONLINE       0     0     0
> 	  mirror-0                                                   ONLINE       0     0     0
> 	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C40FNECA6-part3  ONLINE       0     0     0
> 	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C40AAECA6-part3  ONLINE       0     0     0
> 	  mirror-1                                                   ONLINE       0     0     0
> 	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C405GECA6        ONLINE       0     0     0
> 	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_627C40CGECA6        ONLINE       0     0     0
> 	  mirror-2                                                   ONLINE       0     0     0
> 	    nvme-KXG80ZNV1T02_NVMe_KIOXIA_1024GB_62MA209VKDB6        ONLINE       0     0     0
> 	    nvme-Samsung_SSD_980_PRO_1TB_S5GXNX0T207705A             ONLINE       0     0     0
> 	  mirror-3                                                   ONLINE       0     0     0
> 	    nvme-Samsung_SSD_990_PRO_2TB_S6Z2NJ0TB10778B             ONLINE       0     0     0
> 	    nvme-Samsung_SSD_990_PRO_2TB_S6Z2NJ0TB10674P             ONLINE       0     0     0
> 
> errors: No known data errors
> 

Dies ist die Ausgabe des Hostes (die Platten sind bereits ein Raid 5 vom 
Dell Controller):

  pool: ssd
  state: ONLINE
   scan: scrub repaired 0B in 00:10:12 with 0 errors on Sun Mar 12 
00:34:13 2023
config:

	NAME                                            STATE     READ WRITE CKSUM
	ssd                                             ONLINE       0     0     0
	  scsi-361866da080b888002901314f098fe339-part3  ONLINE       0     0     0

errors: No known data errors

   pool: store
  state: ONLINE
   scan: scrub repaired 0B in 15:32:44 with 0 errors on Sun Mar 12 
15:56:46 2023
config:

	NAME                                            STATE     READ WRITE CKSUM
	store                                           ONLINE       0     0     0
	  scsi-361866da080b8880029012371062fb6a0        ONLINE       0     0     0
	logs	
	  scsi-361866da080b888002901314f098fe339-part2  ONLINE       0     0     0
	cache
	  scsi-361866da080b888002901314f098fe339-part1  ONLINE       0     0     0

errors: No known data errors

Es wurd 2 Tage vorher kein Fehler gefunden. Ich lasse ihn heute Abend 
noch mal scrub'ben.

> Du solltest natürlich auch die Logs des Host checken und sehen, ob Du
> herausbekommst, was die eigentlich Ursache war - also ob ein Laufwerk im
> Pool vielleicht ein ernsteres Problem hat.

Bis auf das, was ich schrieb, steht nichts weiter im LOG.
Das Raid selbst hat keinen Fehler und die Platten sind laut smartctl OK.

Jan

[toc] | [prev] | [next] | [standalone]

#129794

Jan Novak <repcom@gmail.com> schrieb:

> Dies ist die Ausgabe des Hostes (die Platten sind bereits ein Raid 5
> vom Dell Controller):

Uff. Genaus das soll man mit ZFS nicht machen - da ein Raid
drunterlegen (für production würde ich persönlich auch nie raid 5
verwenden - immer raid 6. Sonst ist die Chance erfahrungsgemäß wirklich
nicht schlecht, daß Dir beim Rebuild nach Plattenschaden der Rest
implodiert, falls die nächste wegbricht.)

> pool: ssd
> state: ONLINE
> scan: scrub repaired 0B in 00:10:12 with 0 errors on Sun Mar 12

> pool: store
> state: ONLINE
> scan: scrub repaired 0B in 15:32:44 with 0 errors on Sun Mar 12


Da ist also nichts dazwischen auf zfs Ebene schiefgelaufen. Da hätte ich
jetzt zunächst einmal reparierte Fehler erwartet.
Aber klar, Raid darunter fängt gegebenenfalls zuerst Plattenfehler ab.

Was nicht bedeutet, daß eine VM auf oberer Ebene nicht in Timeouts
rennen und sich verschlucken kann, auch wenn die Layer darunter das
vielleicht mit längeren Timeouts noch klaglos wegstecken.

Hat Dein Raidcontroller ein Log? Das würde ich mir zuerst anschauen.
Und lägerfristig solltest Du das wirklich unbedingt umbauen und die
Platten durchreichen. ZFS gehört nicht auf Raid. Ich würde dann auch
wenigstens Raid-Z2 anraten.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#129863

Am 05.04.23 um 19:03 schrieb Marcus Jodorf:
>> Dies ist die Ausgabe des Hostes (die Platten sind bereits ein Raid 5
>> vom Dell Controller):
> 
> Uff. Genaus das soll man mit ZFS nicht machen - da ein Raid
> drunterlegen (für production würde ich persönlich auch nie raid 5
> verwenden - immer raid 6. Sonst ist die Chance erfahrungsgemäß wirklich
> nicht schlecht, daß Dir beim Rebuild nach Plattenschaden der Rest
> implodiert, falls die nächste wegbricht.)

Moin,

das kann ich nicht bestätigen. Ich habe mit Rechenzentrenbetreibern 
gesprochen. Die meinten, dass die häufigsten Fehler bei einem Ausfall 
die Spares sind. (Ja, Raid6 ist kein Raid 5 mit Spare). Seit dem setzen 
die nur noch raid5 ein.


> Da ist also nichts dazwischen auf zfs Ebene schiefgelaufen. Da hätte ich
> jetzt zunächst einmal reparierte Fehler erwartet.
> Aber klar, Raid darunter fängt gegebenenfalls zuerst Plattenfehler ab.

Stimmt. Andererseits melden weder die Platten selbst (Smart) noch der 
Kontroller irgendwelche Fehler.


Jan

[toc] | [prev] | [next] | [standalone]

#129882

Jan Novak <repcom@gmail.com> schrieb:

> das kann ich nicht bestätigen. Ich habe mit Rechenzentrenbetreibern
> gesprochen. Die meinten, dass die häufigsten Fehler bei einem Ausfall
> die Spares sind. (Ja, Raid6 ist kein Raid 5 mit Spare). Seit dem
> setzen die nur noch raid5 ein.

Hängt von der Risikoabwägung ab. Ich würde nach schlechten Erfahrungen
kein Raid5 mehr einsetzten und ich kenne auch genug andere, die das bei
ihren Servern auch schon lange nicht mehr machen. Insbesondere, seit
drehender Rost Kapazitäten erreicht hat, bei denen ein Rebuild Tage
dauern kann.

>> Da ist also nichts dazwischen auf zfs Ebene schiefgelaufen. Da hätte
>> ich jetzt zunächst einmal reparierte Fehler erwartet.  Aber klar,
>> Raid darunter fängt gegebenenfalls zuerst Plattenfehler ab.
>
> Stimmt. Andererseits melden weder die Platten selbst (Smart) noch der
> Kontroller irgendwelche Fehler.

Timeouts könnten noch mit reinspielen. Falls die VM kürzere
Filesystem-Timeouts hat als die unterliegenden Schichten, dann kann das
auch schief gehen.

Wobei der Raidcontroller sollte die Plattentimeouts normalerweise
runtergedreht haben (bzw. derjenige, der das Raid aufgesetzt hat) -
falls es nicht billige Konsumerplatten sind, wo das nicht geht und die
dann unter Umständen minutenlang auf einem problematischen Sektor
rumkauen, statt mit Fehler abzubrechen.
Normal setzt man da 7 Sekunden oder so um den Dreh als Plattentimeout,
so daß der Controller nicht ewig wartet und das Filesystem darüber
wegfliegt sondern stattdessen die Daten von den anderen Raidmembern
holt und die Platte rauskickt.

Falls ein Filesystem auf höherer Ebene in der VM z.B. nach 30 Sekunden
aussteigt aber darunterliegende Schichten länger warten und eine
angeschlagene Platte die Daten vielleicht doch noch nach 40 Sekunden
zusammenklaubt, dann wären so seltsame Geschichten denkbar.
Deshalb Platten immer auf kurzen Timeout von nur wenigen Sekunden
setzen. Und keine Konsumerplatten einsetzen.


Gruß,

Marcus
⚂⚃

[toc] | [prev] | [next] | [standalone]

#129777

Jan Novak <repcom@gmail.com> writes:

> Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?

Von der Uhrzeit würde ich darauf tippen, dass ein um 21:00 gestarteter
Prozess (Cronjob?) einige I/Os gemacht hat. 30 Sekunden (der Default
SCSI-Timeout bei Linux, siehe /sys/block/sdb/device/timeout) später sind
die vom SCSI-Treiber mit einem Fehler beantwortet worden, so dass das
Filesystem zur Vermeidung von größerem Datenverlust auf read-only
geschaltet hat.

Stellt sich damit halt die Frage, warum die I/Os vom Host nicht innerhalb
von 30 Sekunden beantwortet werden.

Wieviel I/O-Last hat der Host denn? Läuft da um 21:00 auch noch etwas, was
das ZFS ausbremst (ZFS Snapshots, ...)? Oder machen vielleicht alle VMs um
21:00 Last?

Ein bevorstehender Plattenausfall auf dem Host wäre auch eine Möglichkeit.
Das ZFS sieht erst Probleme, wenn der Gerätetreiber auf dem Host auch mit
einem Fehler antwortet. Falls das nur (sehr) lange dauert und die Platte
mit viel Mühe dann doch einen Erfolg meldet, könnte sich so ein Bild
ergeben.

-- 
Stefan

[toc] | [prev] | [next] | [standalone]

#129781

Am 04.04.23 um 21:04 schrieb Stefan Möding:
> Jan Novak <repcom@gmail.com> writes:
> 
>> Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?
> 
> Von der Uhrzeit würde ich darauf tippen, dass ein um 21:00 gestarteter
> Prozess (Cronjob?) einige I/Os gemacht hat. 30 Sekunden (der Default
> SCSI-Timeout bei Linux, siehe /sys/block/sdb/device/timeout) später sind
> die vom SCSI-Treiber mit einem Fehler beantwortet worden, so dass das
> Filesystem zur Vermeidung von größerem Datenverlust auf read-only
> geschaltet hat.

Das ist vermutlich die Ursache. Stündlich werden diverse Jobs gestartet. 
Der um 2100 Uhr hatte gar nicht so viel zu tun ...



> Stellt sich damit halt die Frage, warum die I/Os vom Host nicht innerhalb
> von 30 Sekunden beantwortet werden.

genau...


> Wieviel I/O-Last hat der Host denn? Läuft da um 21:00 auch noch etwas, was
> das ZFS ausbremst (ZFS Snapshots, ...)? Oder machen vielleicht alle VMs um
> 21:00 Last?

Hmmm da laufen Replikationen. Und ja.. es läuft eine um 21:00 Uhr ...


> Ein bevorstehender Plattenausfall auf dem Host wäre auch eine Möglichkeit.
> Das ZFS sieht erst Probleme, wenn der Gerätetreiber auf dem Host auch mit
> einem Fehler antwortet. Falls das nur (sehr) lange dauert und die Platte
> mit viel Mühe dann doch einen Erfolg meldet, könnte sich so ein Bild
> ergeben.

Das klingt für mich auch sehr wahrscheinlich.

Werde das mal beobachten.

Jan

[toc] | [prev] | [next] | [standalone]

#129785

Jan Novak wrote:
> Am 04.04.23 um 21:04 schrieb Stefan Möding:
>> Jan Novak <repcom@gmail.com> writes:
>>
>>> Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?
>>
>> Von der Uhrzeit würde ich darauf tippen, dass ein um 21:00 gestarteter
>> Prozess (Cronjob?) einige I/Os gemacht hat.
[...]
> 
> Das ist vermutlich die Ursache. Stündlich werden diverse Jobs gestartet. 
> Der um 2100 Uhr hatte gar nicht so viel zu tun ...

Werden diese diversen Jobs alle gleichzeitig zur vollen Stunde gestartet?

>> Stellt sich damit halt die Frage, warum die I/Os vom Host nicht innerhalb
>> von 30 Sekunden beantwortet werden.
> 
> genau...
> 
[...]
>> Oder machen vielleicht alle VMs um 21:00 Last?
> 
> Hmmm da laufen Replikationen. Und ja.. es läuft eine um 21:00 Uhr ...

Falls alle Jobs zur gleichen Zeit (bzw. sogar zeitgleich mit der
Replikation) gestartet werden, wäre es vielleicht keine schlechte Idee
diese jeweils mit ein paar Minuten Versatz zu starten.

Michael

[toc] | [prev] | [next] | [standalone]

#129786

Am 05.04.23 um 09:18 schrieb Michael Brand:
> Jan Novak wrote:
>> Am 04.04.23 um 21:04 schrieb Stefan Möding:
>>> Jan Novak <repcom@gmail.com> writes:
>>>
>>>> Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?
>>>
>>> Von der Uhrzeit würde ich darauf tippen, dass ein um 21:00 gestarteter
>>> Prozess (Cronjob?) einige I/Os gemacht hat.
> [...]
>>
>> Das ist vermutlich die Ursache. Stündlich werden diverse Jobs gestartet.
>> Der um 2100 Uhr hatte gar nicht so viel zu tun ...
> 
> Werden diese diversen Jobs alle gleichzeitig zur vollen Stunde gestartet?

nein, nicht stündlich ... vor allem nicht ausserhalb der 
Kernarbeitszeiten. Es sind aber keine einfachen cron Jobs, sondern viele 
kleine PHP CLI Scripte, welche von einem eigenen deamon gestartet 
werden. Das ist auch häufig "onDemand", also wenn irgendetwas einen 
event ausgelöst hat.

>> Hmmm da laufen Replikationen. Und ja.. es läuft eine um 21:00 Uhr ...
> 
> Falls alle Jobs zur gleichen Zeit (bzw. sogar zeitgleich mit der
> Replikation) gestartet werden, wäre es vielleicht keine schlechte Idee
> diese jeweils mit ein paar Minuten Versatz zu starten.

Das stimmt zwar, aber die Replikation startet um 0700,1400 und 2100 Uhr 
... das war wohl Zufall. Ich werde die Platten mal genauer überwachen, 
eventuell ist da was zu sehen ...


Jan

[toc] | [prev] | [next] | [standalone]

#129790

Am 04.04.23 um 21:04 schrieb Stefan Möding:
> Jan Novak <repcom@gmail.com> writes:
> 
>> Kann mir jemand einen Tip geben, warum/wie so etwas passieren kann?
> 
> Von der Uhrzeit würde ich darauf tippen, dass ein um 21:00 gestarteter
> Prozess (Cronjob?) einige I/Os gemacht hat. 30 Sekunden (der Default
> SCSI-Timeout bei Linux, siehe /sys/block/sdb/device/timeout) später sind
> die vom SCSI-Treiber mit einem Fehler beantwortet worden, so dass das
> Filesystem zur Vermeidung von größerem Datenverlust auf read-only
> geschaltet hat.
> 
Da nehme ich doch am liebsten Xen, das braucht keine emulierte Hardware. :-)

Tim

[toc] | [prev] | [standalone]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web