VMware 6.5.0-u1 & Leap 42.3 friert nach 2 Tagen ein

Hinweis: In dem Thema VMware 6.5.0-u1 & Leap 42.3 friert nach 2 Tagen ein gibt es 15 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Im Gebiet Serveradministration bin ich auf Neuland - daher meine Hoffnung zur Lösungsfindung hier;


    Habe das Problem das eine Leap 42.3 Installation regelmässig spätestens nach 2 Tagen einfriert. Das System hat zur Zeit nur dieAufgabe ein Ordner per NFS freizugegeben. Auf diesen werden non-stop Daten kopiert - der Kopier-Prozess läuft auf der Gegenseite. Das Share ist ein externer Datenspeicher (RAID) per SCSI angeschlossen


    Meine erste, naive, Feststellung ist, dass ab dem Zeitpunkt wie Daten kopiert werden, der Arbeitsspeicher zunehmend "aufgefressen" wird - der Swap wird nicht beansprucht. Wie das System einfriert, wird ab diesem Zeitpunkt rapid die CPU beansprucht - bis zur Volllast obwohl nichts mehr geht. Der Host gibt auch kein Ping mehr zurück - "tot"


    Wie kann ich die Herkunft dieses Fehlers eingrenzen? Wo/Wie soll ich "an die Sache" rann gehen das ich die "Kiste zum fliegen bekomme"?
    Ich bin da wirklich auf fremde Hilfe angewiesen da wie bereits erwähnt, ich ein Newbee i.s. Serveradministration bin.


    Die Installation läuft auf einem (und einzige Instanz) ESXi 6.5.0 mit U1 Update (build 5969303)
    Hardware ist ein Intel S2600CWR, 128GB Ram, 2 CPU (XEON E5-2683 v4)



    Herzlichen Dank um jeden Hinweis wie ich das angehen muss/soll


    Marc

    Für den Inhalt des Beitrages 117338 haftet ausdrücklich der jeweilige Autor: aiub

  • Und was für ein Prozess geht da hoch oder auf 100% ?

    Für den Inhalt des Beitrages 117341 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Du meintest iSCSI. SCSI selbst ein altes Interface mit dem man Festplatten betrieben hat.
    iSCSI ist ein ähnliches Interface, aber letztlich ein modernes Netzwerkwerkprotokoll für Speichergeräte.


    Ein paar Befehle, die Aufschluss bringen könnten:


    Es entstehen in dem Verzeichnis, in dem du gerade bist zwei Dateien namens meineCPUlast.txt und meineIOlast.txt.
    Kürze die auf die letzten 50 Zeilen und poste die dann hier.

  • Guten Morgen


    @Sauerland: was die CPU im Zielsystem dann derart belastet kann ich nicht mehr herausfinden da das System nicht mehr ansprechbar ist - auch nicht per vmware-konsole
    Berichtigung: verzeih mir meine fehlerhafte Formulierung. Der Controller ist natürlich kein SCSI (Asche auf mein Haupt) => 8 Port SASIII Dual Core Raid Kontroller mit 2 externen SASIII Ports (wovon 1 verwendet wird)


    Was ich derweilen feststellen konnte:
    Wärend dem kopieren wird 1:1 zum kopierten auch der Arbeitsspeicher des Zielsystems aufgebraucht. Warte ich zu bis dieser "aufgebraucht" ist, System arbeitet noch, lässt sich kein reboot/halt durchführen - das system friert darauf hin ein.
    Unterbreche ich den kopier Vorgang vorzeitig, (20-60gb speicher werden verwendet), lässt sich das Leap wohl neu starten. Innerhalb diesem wird nach dem Reboot der gesamte zugeteilte Speicher als frei angezeigt - jedoch seitens vmware bleibt die Speicherauslastung (gesamt, wie auch der Instanz) unverändert (¿?).
    Bei beiden Scenarios, wenn das System noch läuft und nicht abgeschmiert ist, wird der Speicher erst freigegeben wenn ich die Instanz "power off" mache.
    Ein "power off" der Instanz funktioniert auch nur, wenn diese noch ansprechbar war. Wie im ersten Betrag erwähnt, wenn die Instanz "tot" ist, lässt sich auch kein "power off" mehr durchführen - der ESXi selbst lässt sich dann auch nicht mehr rebooten - ein brutaler "hard reset" ist dann nötig um die komplete Kiste neu hochzufahren.


    Add:
    Berichtigung: werde beide iotop laufen lassen - hoffe dass das System nochmals in die Knie geht um Sachdienliches rückmelden zu können

    Einmal editiert, zuletzt von aiub ()

    Für den Inhalt des Beitrages 117366 haftet ausdrücklich der jeweilige Autor: aiub

  • Verwende meine Befehle möglichst mit einem Pfadnamen, der auf einen Mount zeigt, der nicht über diesen Controller geht.
    Man kann das auch nach Coldboot dann auf jeden Fall lesen.

  • zur Zeit wird dies nicht möglich sein - das Leap hat nur diesen Storage (/, /home, /data in separaten hd-images auf dem externen RAID-Speicher angelegt) und der interne RAID-0 ist exclusiv für die vmware.


    ein nfs-mount wird, so denke ich, früher nicht mehr ansprechbar sein - ergo lasse ich dies mal bleiben. ich bin gespannt;
    zur aktuellen Zeit sind wieder die >120gb ram in benutzung (>160gb kopiert, 800'000 dateien). es gibt mit dem jetzigen copy-job noch weitere 160gb zu kopieren - oder anderst gesagt 3'500'000 dateien....

    Für den Inhalt des Beitrages 117377 haftet ausdrücklich der jeweilige Autor: aiub

  • Dann schreib die Dateien doch einfach auf irgendeine andere Kiste durch einen sshfs mount.


    So ist die Situation ziemlich unklar.
    Benenne dann wenigstens exakt das andere Backend.
    Was läuft dort? Welche nfs Versionen, etc.

  • Soweit so gut - die Ausgabe läuft nun auf ein sshfs-mount


    Mehr Licht ins Dunkle (ich versuche so gut es geht - ich weiss ja nicht wie/was ich "ausleuchten" soll um möglichst viel an Infos bereit zu stellen):


    Quell-System (vmware 6.5.0):
    openSuSE 12.2 (64bit)
    nfs-client-1.2.6-2.16.1.x86_64 (nfs4)


    Ziel-System (vmware 6.5.0, U1):
    openSuSE Leap 42.3
    nfs-kernel-server-1.3.0-28.1.x86_64 (nfs4)
    (/data liegt als 1x15TB vm-File, Thin provisioned), ext4 auf echten Raid, in eigener Partition, 21TB)
    /etc/export ==> /data *(rw,no_root_squash,sync,no_subtree_check)


    Ein nfs-mount (mount ziel:/data /mnt/data) habe ich auf dem Quell-System gemacht, wo folglich auch der copy-job läuft
    (mc, so sehe ich beim kontrollieren ob noch und wieviel wie schnell kopiert wird - was ich +/- auch im vmware-monitoring sehen kann/könnte)


    Das Quell-System läuft non-stop ohne Fehler weiter - auch wenn das Ziel-System sich verabschiedet hat


    Entschuldigt bitte meine etwas "naive" Art - gerne werde ich mich bemühen möglichst rasch und umfassend Informationen bereit zustellen - doch ist mir das "einkreisen" meines Problems absolut nicht geläufig


    BTW: u.a. habe ich auch versucht die Daten per netcat rüber zu bekommen. Da war das Resultat noch ernüchternder (von scp ganz zu schweigen) - zumal viele kleine Dateien vorhanden sind (langsam) - das Ziel-System ging noch rascher in die Knie - sprich frierte ein.
    Beim Verzeichnis "/data" handelt es sich um 8.5TB an Daten die vom alten zum neuen System gelangen müssen - die Anzahl Files habe ich bis dato noch nicht erruiert...werden aber zig Milionen sein (z.T. sind in einzelnen Verzeichnissen +/- 40'000 Dateien). Die Dateien sind meist wenige kB gros, z.T. 20-40 MB - wenige sind im GB Bereich)

    Für den Inhalt des Beitrages 117385 haftet ausdrücklich der jeweilige Autor: aiub

  • mc=midnight commander => F5, mit "Attribute sichern"
    ...aber der arbeitet ja auf dem Quell-System - ¿?

    Für den Inhalt des Beitrages 117402 haftet ausdrücklich der jeweilige Autor: aiub