Zu hoher CPU-Steal?

  • Hallo Community,


    bevor ich beim Support eine Anfrage stelle, wollte ich mal hier nach eurer Meinung fragen.


    Ich besitze den den Root-Server Spring von Netcup. Ich denke die Specs kennt ihr, von einer Intel Xeon Gold 6140 besitzt der Server 2 dedizierte Cores davon.


    Die Auslastung meines Servers liegt je nachdem bei max. 40%, im Schnitt sind es wenn ich mein Monitoring so anschaue in etwa bei 25%.

    In mein Monitoring habe ich auch immer etwas von "steal" gelesen, da dies aber immer so zwischen 1 und 6 % hin und her wandert, habe ich mich nicht wirklich dafür interessiert.

    Nun war gestern aber der CPU-Steal sehr hoch, so in etwa bei 25% bis hin zu 32%.. dann wurde ich aufmerksam und habe mich ein bisschen eingelesen.


    Das es bei einem Server mit vCores zu einem höheren Steal Wert kommen kann, das würde ich noch verstehen. Aber da ich ja ich sag mal in Anführungszeichen einen "Root-Server" habe, also einen vServer mit dedizierten Kernen, dürfte der Wert doch eigentlich nicht so hoch sein?

    Was sind den in dem Bereich so eure Werte? Sind die teilweise 6%, die doch jede Minute immer mal wieder vorkommen normal?


    Danke für eure Antwort :)


    [Blocked Image: http://rlopane.de/Netcup_Steal.jpg]

  • Bei Steal-Werten über 3% je Core kannst du dich an den Support wenden, wenn ich das richtig in Erinnerung habe. Bei 2 Cores also 6%

    Die Aussage "diese Kerne reichen wir direkt zu ihnen durch" in der Produktbeschreibung besagt eigentlich einen Steal Wert von 0%.

    Ich würde die Aussage in dem Link eher so verstehen, daß du dich bei allem über 0% an den Support wenden kannst, daß aber technisch bedingt kurzzeitig (gesamt)Werte von 1-2-3% vorkommen können, bis das Verteilsystem die nicht dedizierten VM von deinem Core geworfen hat.

  • Die Aussage "diese Kerne reichen wir direkt zu ihnen durch" in der Produktbeschreibung besagt eigentlich einen Steal Wert von 0%.

    Ich würde die Aussage in dem Link eher so verstehen, daß du dich bei allem über 0% an den Support wenden kannst, daß aber technisch bedingt kurzzeitig (gesamt)Werte von 1-2-3% vorkommen können, bis das Verteilsystem die nicht dedizierten VM von deinem Core geworfen hat.

    Sollte die Stealtime je Kern durchgehend > 3% sein, wenden Sie sich bitte an unseren Support, denn dann stimmt etwas nicht. Das gilt nur für dedizierte Kerne.

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.raucher-werden.de - www.serioese-alternative.de - www.jeff-media.de

  • Super, vielen Dank für eure schnellen Antworten. Dann waren die zwei Stunden mit teilweise 32% Steal-Werten auf jedenfall nicht normal.

    Auch die spitzen von teils 8% (war vor ein paar Minuten) dürften dann eigentlich nicht sein.


    Habe ich dadurch, obwohl ich aktuell nur etwa 25% meiner CPU in Anspruch nehme,Leistungseinbußen oder brauche ich mir da keine Gedanken machen?

    Falls das kein Problem ist, sehe ich von einer Support Anfrage ab, dann ist das ganze meiner Meinung nach nicht so gravierend, zumindest wenn es bei Peak-Werten von 8% bleibt.

  • Ich würde das einfach mal über ein paar Tage beobachten. Bei kleineren Peaks würde ich mir jetzt keine allzu großen Sorgen machen. Ist der Steal jedoch dauerhaft im höheren einstelligen Prozent Bereich, würde ich dann doch mal den Support kontaktieren.


    Merkst du das denn selbst? Reagieren die Applikationen langsamer als sonst? Letztendlich kommt es ja genau darauf an, ob das spürbare Auswirkungen hat. Einen Unterschied zwischen 2% und 5% wird man in der Praxis wohl eher kaum wahrnehmen. Daher schau einfach mal, ob sich das nicht einfach von selbst löst. Und wenn nicht, ist so eine Support Anfrage ja auch schnell mal gestellt.


    Die 32% sind natürlich schon etwas viel. Daher beobachte das auf jeden Fall mal über einen längeren Zeitraum.

  • Du Zitierst nur aus dem ersten Post. Im Zweiten wird das ja eingeschränkt.

    Und: Die Aussagen sind mittlerweile älter als ein Jahr. Damals gab es die Aussage "wir reichen die Kerne direkt durch" noch nicht.


    Dann waren die zwei Stunden mit teilweise 32% Steal-Werten auf jedenfall nicht normal.

    Das halte ich in jedem Fall für Inakzeptabel...


    Falls das kein Problem ist, sehe ich von einer Support Anfrage ab

    Was du für ein Problem hälst, bleibt dir Überlassen. Laut Werbeaussage sollten es 0% sein. technisch wohl kurzzeitig 1-3%. Alles was dauerhaft ist und mehr als 1-2% würde mich stören.

    Wirklich bemerken tut man sowas als Mensch wohl sowieso nicht. Auch nicht bei 10-20%. Es hängt eben davon ab, ob du Applikationen laufen hast, denen du die eingekauften Resouchen auch wirklich zugeteilt wissen willst.

    Meiner Meinung nach bemerkt man eine miese I/O Performance und zu wenig RAM erheblich mehr, als etwas weniger Prozessorleistung.

  • Ich hatte den Link erst als Edit eingefügt und da er in deinem (meinem) Zitat noch nicht vorkam, bin ich davon ausgegangen dass du den nicht wahrgenommen hast, sorry.


    Fakt ist: ich würde definitiv keine CPU-Steal von 0% bei virtuellen Systemen erwarten, es sei denn, ich laste meine Kerne selbst zu 100 % aus. Aber da kann dann wohl nur Felix oder der Support weiterhelfen. Lopayne , frag doch einfach mal nach und berichte wie die Antwort ausfällt :)

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.raucher-werden.de - www.serioese-alternative.de - www.jeff-media.de

  • Damals gab es die Aussage "wir reichen die Kerne direkt durch" noch nicht.

    Laut Werbeaussage sollten es 0% sein.


    KVM läuft unter Linux. Und jeder Kern einer VM ist ein Prozess im Hostsystem.

    Das Einkoppeln, Auskoppeln und Planen von Prozessen auf der physikalischen Hardware übernimmt hierbei der Scheduler.

    Qemu unetrstützt dabei Hardware Affinität, d.h. der gleiche Qemu Prozess wird immer auf dem gleichen Kern ausgeführt, nun ist es aber so, dass die Hostsysteme nicht nur die VMs als Prozesse haben, sondern auch z.B. den Kernel, IO-Prozesse, systemd etc. pp. - und die müssen auch irgendwo hin gescheduled werden.


    Daher kann es nie zu einem 0% Steal kommen, es sei denn es werden eigene Scheduler exakt dafür geschrieben.

    Das durchreichen der Kerne bezieht sich hierbei auf Passthrough Parameter - also der CPU Fähigkeiten. In Qemu-KVM können nämlich verschiedene CPU Modelle emuliert werden. Direktes Durchreichen beschreibt einfach nur: das CPU Modell und die Flags die du hier vorfindest, reiche bitte weiter an die VM. Weil es den geringsten Emulations Overhead hat.

  • Du brauchst mir die Technik von KVM nicht zu erklären. Ich zitiere lediglich Aussagen aus Artikelbeschreibung und Werbung von nc...

    Es wird nirgendwo eine Steal-Time von 0% beworben.

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.raucher-werden.de - www.serioese-alternative.de - www.jeff-media.de

  • Bin leider erst jetzt dazugekommen die Support–Mail zu schreiben.

    Hatte vorhin auch wieder kurze Peaks von über 30% festgestellt, meist wechselt der Wert aberzwischen 5 – 13% hin und her. Für direkt durchgereichte Kerne aber trotzdem relativ hoch.


    Mal gespannt was der Support zu sagen hat, sollte ich eine Antwort bekommen gebe ich euch Bescheid.

  • Es gibt ein Update zu der Sache.


    Zuerst muss ich auch mal beim Support-Bereich einen Lob aussprechen. Es wurde mir sehr schnell geantwortet & auch gleich eine Lösung angeboten, und zwar die Migration in ein anderes System natürlich. Das ganze klappte sogar Live & es musste nicht mal ein Neustart durchgeführt werden. Das finde ich spitze.


    Leider wurde mir aber nicht gesagt warum es so einen hohen CPU Steal gab. Die CPU sind dediziert & werden direkt durchgereicht, so die Aussage vom Support.



    Das Endergebnis der Migration, der Steal-Wert bleibt nahezu bei 0%, also alles super soweit.

  • Zuerst einmal: gute und schnelle Lösung durch den Support.


    Was ich aber etwas schade finde: Wenn sich hier der Kunde nicht beschwert hätte, wäre er auf einem (vermutlich) überbuchten System geblieben, und hätte dadurch nicht die volle Leistung zur Verfügung gehabt. Meiner Meinung nach sollte Netcup hier proaktiv auf den Kunden zukommen und eine Migration vornehmen. Noch besser wäre, diesen vServer garnicht erst auf dem betroffenen System zu provisionieren (geht natürlich nur, wenn sich dieser Umstand durch's Monitoring bereits abgezeichnet hat).