RS 2000 Prozessor

    Hallo,

    kann mir jemand folgendes Phänomen erklären?


    Ich habe einen RS2000

    Prozessorkerne: 4 dediziert

    Prozessor: Intel® Xeon® Gold 6230


    Ich Verstehe auch, dass das nicht wirklich durchgereichte Prozessorkerne sind.


    Nun habe ich darauf das Debian 10 minimal Image von NC installiert,

    meine Tools und Buildsystem aufgespielt, die Sourcen geladen und einen Kompiliervorgang gestartet.

    Dieser dauerte knapp 2 Stunden. Die load lag bei 5-6 und steal bei quasi 0.

    Da ich die Sourcen mit verschiedenen Konfigurationen bauen muss, habe ich denselben Build mehrmals durchgeführt.

    Jedes mal dauerte das Kompilieren knappe 2 Stunden.

    Am ersten Tag.


    Nach 2-3 Tagen habe ich nochmal einige Kompilierdurchläufe gestartet.

    Load und steal identisch, nur - Es dauert seither mindestens 3,5-4 Stunden pro Kompiliervorgang!

    Das hat sich seitdem auch nicht mehr geändert.


    Wurde der Server auf ein Profil für "CPU-Hogs" geschoben? Oder hat jemand eine Annehmbare Erklärung dafür?

    Hi,


    Da hier noch keiner geantwortet hat, schieße ich einfach mal ins dunkle.


    Ich weiß jetzt nicht, was genau und wie genau du da kompilierst, aber bist du vielleicht I/O mäßig langsamer unterwegs? Ich weiß nur ganz grob vom Linux Kernel, dass es sich teilweise wohl sehr lohnen kann in einer RAM Disk zu bauen.

    Zitat von ASS

    Nach 2-3 Tagen habe ich nochmal einige Kompilierdurchläufe gestartet.

    Load und steal identisch, nur - Es dauert seither mindestens 3,5-4 Stunden pro Kompiliervorgang!

    Das hat sich seitdem auch nicht mehr geändert.

    Bezugnehmend auf das, was Valkyrie andeutete: Kann es sein, dass sich der Swap-Space/die übrige Festplattenausnutzung geändert hat? Ein paar Tests mit steigendem Aufwand, um das Problem einzugrenzen, wären:

    1. Wenn es möglich ist, auf Swap-Space zu verzichten (spart I/O-Zugriffe, verschlingt dafür RAM): Hilft swapoff -a?
    2. Wenn man die Maschine via SCP einmal herunterfährt (also ausschaltet) und danach wieder startet, wird es dann schneller (mit/vorzugsweise ohne o.g. Swap)?
    3. Ist es möglich, auf der Maschine Platz zu schaffen, indem "Überreste" vorangegangener Kompiliervorgänge (ccache-Inhalte – auch wenn diese normalerweise beschleunigend wirken sollten –, Objektdateien, Quellverzeichnisse) entfernt werden?
    4. Deutlich aufwendiger, wenn nicht von Anfang an eingeplant: Wenn man die Maschine völlig neu aufsetzt (am Anfang ist ggf. genügend Platz für einen Snapshot) und die obengenannten Tests wiederholt, ist das Ergebnis reproduzierbar – schnell nach Neuaufsetzung/Einspielung des initialen Snapshots, langsam nach wiederholten Durchläufen, wieder schnell nach Restauration des Snapshots? Letzteres würde darauf hindeuten, dass hier irgendein Engpass entsteht, der im 3. Schritt nicht erkannt wurde (vgl. nächsten Absatz) ...

    Wird auf der Maschine ggf. ZFS verwendet? Wenn das Dateisystem einmal vollgelaufen ist (ab 85%), sinkt die Leistung drastisch… das ist derzeit m.W. leider nur durch Neuerstellung des Pools heilbar. Inwieweit das durch den 4. Schritt oben aufgedeckt werden kann, hängt davon ab, wie ein solcher Snapshot funktioniert -- wenn das auf Dateibasis abläuft, ist eine Restauration des Ausgangs-/Snapshot-Zustands (zwingend) wirkungslos.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Zitat von ASS

    Wie soll "Ich" denn langsamer "unterwegs" sein?

    Die Frage dürfte sich auf die "io wait cpu time" (bei [h]top: "wa") beziehen, welche insbesondere bei längeren, durchgängig I/O-intensiven Aufgaben deutlich nach oben schnellen kann (unabhängig von der "steal time" (bei [h]top: "st"); allerdings korreliert dies nach eigener Erfahrung immer mit erhöhten Load-Werten (wie sie uptime auswirft)…

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Zitat von m_ueberall

    Kann es sein, dass sich der Swap-Space/die übrige Festplattenausnutzung geändert hat?

    Nein.


    Zitat von m_ueberall

    Wenn es möglich ist, auf Swap-Space zu verzichten (spart I/O-Zugriffe, verschlingt dafür RAM): Hilft swapoff -a?

    Die Installation hat kein Swap.


    Zitat von m_ueberall

    Wenn man die Maschine via SCP einmal herunterfährt (also ausschaltet) und danach wieder startet, wird es dann schneller (mit/vorzugsweise ohne o.g. Swap)?

    Nein.


    Zitat von m_ueberall

    Ist es möglich, auf der Maschine Platz zu schaffen, indem "Überreste" vorangegangener Kompiliervorgänge (ccache-Inhalte – auch wenn diese normalerweise beschleunigend wirken sollten –, Objektdateien, Quellverzeichnisse) entfernt werden?

    Das wird sowieso getan Von Anfang an.


    Zitat von m_ueberall

    ist das Ergebnis reproduzierbar

    Ja.

    Der Rechner ist jetzt anscheinend langsamer als Anfangs.


    Zitat von m_ueberall

    Wird auf der Maschine ggf. ZFS verwendet?

    Es wird weder ZFS noch sonst etwas Exotisches eingesetzt.

    Auch weden Dateisystemgrenzen nicht erreicht.

    Das SCP sagt 190 von 240GB belegt.

    Es kann also auch nicht an einer Fragmentierung liegen.


    Es ist ein neues Debian auf ext4.

    OS und Build System belegen ca. 70-80 GB.

    Zwischendateien belegen maximal weitere 80GB.

    Die Binaries sind dann am Ende etwa 7GB.


    Der Kompiliervorgang belegt immer unter 1GB Ram. Die restlichen 15GB werden als Buffer benutzt.


    Es gibt ein Script, das jeweils die Config in den Source Pfad kopiert, ein Clean durchführt, das kompilieren startet, das Ergebnis per SCP wegschiebt

    und dann das ganze mit der nächsten config wiederholt.

    Das Script lief am ersten Tag etwa 3 mal. Jeder Vorgang war in 2 Stunden abgeschlossen.

    Dann waren 3 Tage Pause.

    Dann habe ich das Script nochmal gestartet und seit dem Dauert ein Durchlauf immer zwischen 3,5 und 4 Stunden, statt 2.

    Auf dem Rechner war in der zwischenzeit niemand eingeloggt.

    Es laufen außer SSH und NTP keinerlei Dienste auf dem Rechner.

    Zitat von m_ueberall
    1. Deutlich aufwendiger, wenn nicht von Anfang an eingeplant: Wenn man die Maschine völlig neu aufsetzt (am Anfang ist ggf. genügend Platz für einen Snapshot) und die obengenannten Tests wiederholt, ist das Ergebnis reproduzierbar – schnell nach Neuaufsetzung/Einspielung des initialen Snapshots, langsam nach wiederholten Durchläufen, wieder schnell nach Restauration des Snapshots?
    Zitat von ASS

    Ja.

    Der Rechner ist jetzt anscheinend langsamer als Anfangs.

    Mit "reproduzierbar" meinte ich einen ganzen Zyklus (d.h. "bekommt man die Maschine durch Neuinstallation nochmal so schnell wie am Anfang… und wird es danach wieder langsamer?"). Wenn dem so ist, wäre das Problem IMHO primär in der VM zu suchen; wenn nicht – alles bleibt langsam, trotz Neuinstallation – muss es externe Gründe geben (Gastsystemauslastung[*]). Eine Protokollierung dieses Umstands wäre ggf. ein berechtigter Grund, Netcup um eine Verschiebung der VM zu bitten (ohne Dokumentation wird der Support ggf. genau o.g. Vorgehen einfordern, aber sofortiges Fragen kostet nichts… ;)). Im worst case war die Ursache, dass die eigene VM ursprünglich als erste auf einem ansonsten ungenutzten Gastsystem platziert wurde und dadurch unerwartet gut funktionierte.


    [*] Technisch dadurch zu testen, indem man eine Zwillings-VM bucht (wird von Netcup auf einem anderen Gastsystem platziert) und Vergleichsmessungen mit einem Snapshot-Export/-Import anstellt.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Zitat von ASS

    Wie soll "Ich" denn langsamer "unterwegs" sein?`Wenn, dann ist das ja wohl der Server und somit ein Teil der Frage.

    Mit "du" war natürlich deine gesamte Maschine gemeint. Da deine Frage nur auf die CPU abzielte und sonst, abgesehen von der benötigten Zeit, scheinbar alles gleich war (load, steal), wollte ich auf mögliche andere "Flaschenhälser" wie dem Storage hinweisen. Die Posts von m_ueberall sind dahingehend schön ausführlich.

    Es gab bzw. gibt ein Limit an I/O pro Sekunde. Im Monitoring gab das eine schöne glatte Zahl. Hast du ein Monitoring?


    Wer hat ein Link zur Hand?

    "Security is like an onion - the more you dig in the more you want to cry"