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

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

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.
  • VMware 6.5.0-u1 & Leap 42.3 friert nach 2 Tagen ein

    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

  • 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:

    Shell-Script

    1. # erst mal root werden in der Konsole
    2. su
    3. # er frägt nach dem root Spasswort, das du blind eingeben musst.
    4. # es werden nicht einmal Sternchen angezeigt. Einfach tippen und
    5. # enter drücken.
    6. # iotop ist ein Tool, das die Ein/Ausgabelast von Prozessen anzeigt.
    7. # wenn es noch nicht installiert ist, erst installieren mit
    8. zypper in iotop
    9. # -b meint Batchmode
    10. # -o nly die Prozesse, die wirklich I/O machen
    11. # >> lenkt die Ausgabe in die Datei, die neu erstellt wird,
    12. # solange es keine Datei mit dem angegebenen Namen gibt, sonst
    13. # wird dort am Ende die Ausgabe angehängt.
    14. iotop -b -o >> meineIOlast.txt
    15. # und nochmal ähnliches, für die Prozessorlast.
    16. # das liefert der Befehl top
    17. # -o %CPU sortiert nach CPU Verbrauch
    18. # -b wieder Batchmode
    19. # -d 1 jede Sekunde einmal auslesen
    20. # -i keine Idle Prozesse anzeigen
    21. top -o %CPU -b -d 1 -i >> meineCPUlast.txt
    Alles anzeigen
    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.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 117347 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • 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

    Dieser Beitrag wurde bereits 1 mal 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.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 117376 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • 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.
    Sokrates sagte, dass er nichts wisse.
    Ich bin viel, viel klüger als Sokrates.
    Ich weiß ganz genau, dass ich gar nichts weiß.

    Für den Inhalt des Beitrages 117378 haftet ausdrücklich der jeweilige Autor: Berichtigung

  • 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