Hoster blockiert CPU Funktionen - normal?
- Thread starter Homwer
- Start date
A
andreas0
Guest
@Homwer
Bekommst du vom Provider die 4 Kerne wirklich exklusiv? Sind das nicht eher virtuelle Kerne bzw. vCores, die dein Provider da anbietet?
Homwer
Member
In deiner Weklt möchte ich nicht leben.
Automodell =! Ausstattung?
Natürlich erwartest du bei einem Modell X dass du diese Ausstattung auch erhältst. Was du nicht erwartest sind 3 Reifen und ein fehlender Blinker...
Aber wir schweifen vom Thema ab. Eigentlich wollte ich nur wissen welche Erfarhung andere User gemacht haben und ob das vorenthalten von CPU Features normal ist.
@andreas0, man wirbt zumindest damit dass die kerne Dedicated sind. Genau das machte das Angebot ja so spannend
A
andreas0
Guest
@andreas0, man wirbt zumindest damit dass die kerne Dedicated sind. Genau das machte das Angebot ja so spannend
@Homwer
Aber dediziert würde ich jetzt nicht gleich setzen mit exklusiv oder wie siehst du es?
C
chbu
Guest
So in etwa hätte ich mir das bei "4 dedizierte CPU-Kerne" auch vorgestellt. Aber so etwas ist typisch bei den Anbietern, die ihre Vserver Rootserver nennen.
A
andreas0
Guest
@Homwer
Unter dediziert versehe ich, dass man Eigenschaften vom Provider zugesichert bekommt, aber dadurch noch lange nicht diese zugesicherten Eigenschaften auch exklusiv bekommt, sofern es sich um einen virtuellen Server handelt. Denn dein virtueller Server ist wiederum auf einen sehr großen dedizierten Server installiert, den du dir mit weiteren Kunden teilst.
Du darfst also deinen virtuellen Server und dessen Komponenten nicht wie einen echten dedizierten Server sehen.
Last edited by a moderator:
nexus
Well-Known Member
Nach deiner Interpretation wäre aber dann ein virtueller Kern mehr oder weniger gleichbedeutend mit einem dedizierten Kern, da ich in beiden Fällen mit anderen teilen müßte...
Nach meiner (rein subjektiven) Interpretation bedeutet dediziert in der IT "fest zugeordnet" und wenn mir etwas fest zugeordnet wird, kann es niemand anderes mitbenutzen, also steht mir die Ressource exklusiv (weil alleine) zur Verfügung.
Einen dedizierten Rootserver muß ich ja auch nicht mit jemandem teilen...damit meine ich jetzt "echte" dedizierte Kisten, nicht diese Pseudo-Rootserver.
Last edited by a moderator:
killerbees19
Member
Würde ich meinen…Netcup ?
Bis vor wenigen Monaten war das dort übrigens schlichtweg gar nicht möglich, erst bei der neuen Generation 7. Und offenbar haben sie diese Unterstützung auch jetzt nicht auf jedem Node.
Prinzipiell darf man davon ausgehen, dass jemand, der dieses Feature nutzt, deutlich mehr Traffic verbraucht und auch die I/O Leistung mehr ausreizt. Der Speicherplatz ist wahrscheinlich ebenfalls gut ausgelastet. Insofern kann man das schon als Mischkalkulation sehen, die ohne Aufpreis nicht mehr aufgeht. RAM und CPU an sich müssten ja theoretisch egal sein, wenn sie wirklich exklusiv zur Verfügung stehen und nicht überbucht werden. Das alles weiß aber nur der Anbieter.
MfG Christian
PS: Ich gehöre zu denen, die das gebucht haben.
D
Deleted member 15972
Guest
Das schöne ist, das Du in Deinem letzten Satz bereits den Unterschied zwischen dediziert und virtualisiert nennst.
Vorher argumentierst Du aber, dass der Zusatz "dediziert" trotzdem etwas anderes bedeuten soll.
Wenn ich einen Teil eines Systems mit dediziert qualifiziere, dann habe ich genau das getan. Wenn etwas nicht dediziert ist, dann lasse ich den Begriff weg. Wenn ich ihn verwende, dann tue ich dies bewusst und treffe damit eine eindeutige Aussage.
Manche Begriffe sind eben eindeutig definiert und diese Neigung alles umzudefinieren ist zwar verständlich (Sprache lebt), man braucht sich allerdings nicht wundern, wenn das viele/die meisten Mitmenschen anders sehen. Ein Apfel bleibt ein Apfel, auch wenn ich ihn Banane nenne.
Last edited by a moderator:
[netcup] Felix
New Member
Guten Morgen,
auf den Verdacht hin das es sich hier um einen Root-Server von uns handelt, ein paar Worte zum Thema VMX-Flag in per KVM virtualisierten Servern:
Wir sehen es nicht so, dass wir ein Feature gezielt sperren, da VMX für KVM immer explizit im Kernel des jeweiligen Nodes aktiviert werden muss. Im Sinne einer besseren Performance ist dieses Seitens der Kernelentwickler zunächst deaktiviert. Das VMX je nach Anwendungsfall Nachteile bei der Performance bringt bestätigen auch Benchmarks von Anbietern die dieses Feature aktiviert haben (z.B. https://www.thomaschristlieb.de/benchmark-der-vserver-bei-php-friends/ ). Eigene Messungen auf unseren Systemen bestätigen dieses.
Da vermehrt der Wunsch nach aktiviertem VMX bei unseren Root-Servern aufkommt, haben wir einige Nodes mit aktiviertem VMX bereitgestellt. Auf Anfrage stellen wir auf diesen Systemen Root-Server bereit. Derzeit verlangen wir hier 2 Euro zusätzlich je Kern, was wir aufgrund des aktuell noch manuellen Aufwands als fair erachten. Je mehr Kunden daran Interesse hätten, je günstiger würden natürlich die Systeme werden.
Da hier auch zu dedizierten Kernen Fragen aufkamen: Wir verstehen unter dedizierten Kernen CPU Kerne (keine Threads) die Kunden garantiert zur Verfügung stehen, wenn auf diesen Rechenoperationen gestartet werden. Die Kerne stehen dabei mit voller Leistung zur Verfügung. Die Kerne werden in dem Moment nicht von anderen Systemen mit genutzt. Als Featureset stellen wir die Features bereit, die per Default einem Kern des beworbenen CPU-Typs zur Verfügung stehen.
Zum Vergleich: Bei unseren VPS teilen sich mehrere Kunden die zur Verfügung stehenden Kerne, was natürlich einen enormen Preisvorteil bietet. Viele Unserer Mitbewerber nehmen rein diesen Preisvorteil mit und wollen gar keine dedizierten Kerne vermarkten. Auch hier zeigen Ergebnisse von Benchmarks auf, dass man als Kunde nur bedingt mit solchen Systemen arbeiten kann. Spätestens für den Betrieb eigener virtueller Instanzen sollte garantierte CPU-Leistung zur Verfügung stehen.
Wir sind sehr daran interessiert unseren Kunden das anzubieten, was sie sich wünschen. Sollte VMX ein genereller Wunsch sein und von vielen gefragt werden, werden wir dieses anbieten. Bei entsprechend großer Menge sogar ohne Aufpreis, allerdings mit dem Vermerk auf die Einbußen bei der Performance. Wir freuen uns daher über jedes Feedback zum Thema aktiviertes VMX auf Root-Servern.
Vielen Dank!
Mit freundlichen Grüßen
Felix Preuß
auf den Verdacht hin das es sich hier um einen Root-Server von uns handelt, ein paar Worte zum Thema VMX-Flag in per KVM virtualisierten Servern:
Wir sehen es nicht so, dass wir ein Feature gezielt sperren, da VMX für KVM immer explizit im Kernel des jeweiligen Nodes aktiviert werden muss. Im Sinne einer besseren Performance ist dieses Seitens der Kernelentwickler zunächst deaktiviert. Das VMX je nach Anwendungsfall Nachteile bei der Performance bringt bestätigen auch Benchmarks von Anbietern die dieses Feature aktiviert haben (z.B. https://www.thomaschristlieb.de/benchmark-der-vserver-bei-php-friends/ ). Eigene Messungen auf unseren Systemen bestätigen dieses.
Da vermehrt der Wunsch nach aktiviertem VMX bei unseren Root-Servern aufkommt, haben wir einige Nodes mit aktiviertem VMX bereitgestellt. Auf Anfrage stellen wir auf diesen Systemen Root-Server bereit. Derzeit verlangen wir hier 2 Euro zusätzlich je Kern, was wir aufgrund des aktuell noch manuellen Aufwands als fair erachten. Je mehr Kunden daran Interesse hätten, je günstiger würden natürlich die Systeme werden.
Da hier auch zu dedizierten Kernen Fragen aufkamen: Wir verstehen unter dedizierten Kernen CPU Kerne (keine Threads) die Kunden garantiert zur Verfügung stehen, wenn auf diesen Rechenoperationen gestartet werden. Die Kerne stehen dabei mit voller Leistung zur Verfügung. Die Kerne werden in dem Moment nicht von anderen Systemen mit genutzt. Als Featureset stellen wir die Features bereit, die per Default einem Kern des beworbenen CPU-Typs zur Verfügung stehen.
Zum Vergleich: Bei unseren VPS teilen sich mehrere Kunden die zur Verfügung stehenden Kerne, was natürlich einen enormen Preisvorteil bietet. Viele Unserer Mitbewerber nehmen rein diesen Preisvorteil mit und wollen gar keine dedizierten Kerne vermarkten. Auch hier zeigen Ergebnisse von Benchmarks auf, dass man als Kunde nur bedingt mit solchen Systemen arbeiten kann. Spätestens für den Betrieb eigener virtueller Instanzen sollte garantierte CPU-Leistung zur Verfügung stehen.
Wir sind sehr daran interessiert unseren Kunden das anzubieten, was sie sich wünschen. Sollte VMX ein genereller Wunsch sein und von vielen gefragt werden, werden wir dieses anbieten. Bei entsprechend großer Menge sogar ohne Aufpreis, allerdings mit dem Vermerk auf die Einbußen bei der Performance. Wir freuen uns daher über jedes Feedback zum Thema aktiviertes VMX auf Root-Servern.
Vielen Dank!
Mit freundlichen Grüßen
Felix Preuß
Last edited by a moderator:
d4f
Kaffee? Wo?
Vorab, der Beitrag von netcup ist sehr fachlich und schön detailliert. Danke für diese Informationen. Mich stören nur ein paar Details, bitte dies nicht als Schlechtmachen ansehen.
Oder man kann sagen dass der Vergleich von Apfel (dedizierte CPU-Zuteilung, teurerer Server) mit Birne (günstiger Server) zum Beweis einer willkürlichen Angabe etwas weit her geholt ist.
Dass VMX tatsächlich einen Overhead verursacht bezweifele ich übrigens nicht. Nur die Beweisführung war hier doch etwas sehr holperig
Ich sehe keinen Zusammenhang zwischen dem Benchmark und VMX. Im Vergleich wird ein 5.99€ System von PHP-Friends mit einem 8.99€ System von Netcup verglichen. Um den Unterschied zu verdeutlichen; wenn wir davon ausgehen dass Preis/Leistung linear ist, hat der PHP-Friends Server 66.63% der Leistung des Netcup Servers. Dies bedeutet im Umkehrschluss dass bei gleichem Preis mit 22.48 Sekunden hochgerechnetem CPU-Benchmark schneller. Ich könnte also hier behaupten dass VMX leistungssteigernd wirkt.
Oder man kann sagen dass der Vergleich von Apfel (dedizierte CPU-Zuteilung, teurerer Server) mit Birne (günstiger Server) zum Beweis einer willkürlichen Angabe etwas weit her geholt ist.
Dass VMX tatsächlich einen Overhead verursacht bezweifele ich übrigens nicht. Nur die Beweisführung war hier doch etwas sehr holperig
"Bedingt" ist ein durchaus dehnbarer Begriff. Ich wage mal zu behaupten dass für die absolute Mehrheit der (Nicht-Gamer) Kunden die Vorteile irrelevant und damit der Preisunterschied nicht zu rechtfertigen ist. Insbesondere wenn man berücksichtigt dass in dem Preisbereich wo wir uns hier bewegen Anbindung, Festplattenleistung und viele anderen Faktoren von den meisten Anbieter auch nach "best effort" gelten und nicht garantiert werden (können) respektive die Garantien auf urzeitlichen Niveaus liegen.
Hier wäre für die Kunden zwecks Transparenz eventuell ein weiterführender Link zu dem default-featureset nützlich. Schliesslich hängen defaults doch sehr stark von Faktoren wie Version und Umgebung ab was dann nicht für den Durchschnittskunden nachvollziehbar ist. Alternativ eine Bewerbung der Zusatzoption "VMX".
[netcup] Felix
New Member
Vielen Dank für das ausführliche Feedback!
Es tut mir Leid wenn das so verstanden wurde, dass die Unterschiede alleine an VMX liegen. Selbstverständlich gibt es weitere erhebliche Faktoren welche die Leistungsunterschiede erklären. VMX ist allemal ein Faktor der gering ins Gewicht fällt.
Vielen Dank für die Tipps. Wir werden hier eine Darstellung erarbeiten. Zudem kann jeder Root-Server auch im Rahmen der Zufriedenheitsgarantie zurück gegeben werden. Testen kostet hier kein Geld.
Beste Grüße
Felix Preuß
Es tut mir Leid wenn das so verstanden wurde, dass die Unterschiede alleine an VMX liegen. Selbstverständlich gibt es weitere erhebliche Faktoren welche die Leistungsunterschiede erklären. VMX ist allemal ein Faktor der gering ins Gewicht fällt.
Vielen Dank für die Tipps. Wir werden hier eine Darstellung erarbeiten. Zudem kann jeder Root-Server auch im Rahmen der Zufriedenheitsgarantie zurück gegeben werden. Testen kostet hier kein Geld.
Beste Grüße
Felix Preuß
ThomasChr
Active Member
Ich mache gerne einen Test mit aktiviertem VMX Flag und ohne.
Nur möchte ich jetzt nicht vom Support erst das Flag aktivieren und ein paar Tage später gleich wieder deaktivieren lassen.
Wäre interessant ob es da tatsächlich einen deutlich messbaren Unterschied gibt.
Thomas
Nur möchte ich jetzt nicht vom Support erst das Flag aktivieren und ein paar Tage später gleich wieder deaktivieren lassen.
Wäre interessant ob es da tatsächlich einen deutlich messbaren Unterschied gibt.
Thomas
nexus
Well-Known Member
Sorry Leute, aber ich kann nicht wirklich nachvollziehen, warum man Benchmarks auf virtualisierten Kisten für eine objektive Leistungsbewertung hernimmt 
Wenn überhaupt, dann kann ein solcher Benchmark nur grobe Anhaltspunkte für die vermutete Leistung liefern, denn man weiß nie, welche Nachbar-VM's sich gerade ihren Anteil an den gemeinsam genutzten Ressourcen genehmigen und so das Testergebnis mehr oder weniger verfälschen.
Der einzig sinnvolle Weg, um bei einem solchen Test einigermaßen aussagekräftige Werte zu bekommen wäre der, daß vom Hoster exklusiv nur eine einizige VM auf einem ansonsten leeren Host bereitgestellt werden würde...
Wenn überhaupt, dann kann ein solcher Benchmark nur grobe Anhaltspunkte für die vermutete Leistung liefern, denn man weiß nie, welche Nachbar-VM's sich gerade ihren Anteil an den gemeinsam genutzten Ressourcen genehmigen und so das Testergebnis mehr oder weniger verfälschen.
Der einzig sinnvolle Weg, um bei einem solchen Test einigermaßen aussagekräftige Werte zu bekommen wäre der, daß vom Hoster exklusiv nur eine einizige VM auf einem ansonsten leeren Host bereitgestellt werden würde...
dataforest
Active Member
Ganz kurz nur, da wir im verlinkten Benchmark Erwähnung finden: Es wundert mich wenig, dass Felix das hier ohne jeden Zusammenhang aufgreift - wer hier regelmäßig mitliest, versteht sicher, was gemeint ist. Der bei uns getestete vServer hat eine ganz andere CPU, was Felix sicher auch im Vorfeld bekannt war, und ist daher nicht vergleichbar. Der Hinweis auf eigene Messungen zu Nested Virtualization wäre hier völlig ausreichend gewesen.
Zugegebenermaßen kommen wir in Sachen I/O in dem Benchmark schlechter weg, als wir wollen. Dazu hat der Tester aber netterweise auch ein Ticket bei uns aufgemacht und wir evaluieren Leistungssteigerungen durch Hardwareänderungen bei neueren Systemen. Dennoch muss ich (da der Benchmark nun mal gepostet wurde), auch ohne den Thread dafür "hijacken" zu wollen, darauf hinweisen, dass derartige Ergebnisse nur bedingt ausschlaggebend für eine tatsächlich schlechtere Performance unter echter Workload sind. Die Erfahrung zeigt hier klar, dass die SSD-Leistung eines (v)Servers i.d.R. weit nach anderen Ressourcen ans Limit kommt und daher in der Praxis keinen Flaschenhals darstellt, auch wenn ein bewusst nur auf den SSDs Volllast generierender Benchmark deutliche Abweichungen aufzeigen kann. Ungeachtet dessen sind wir natürlich bemüht, eine verglichen mit unseren Mitbewerbern gute - auch messbare - Leistung in allen Bereichen anzubieten, aber weitere Upates zu diesem Thema würde ich gerne in besagtem Ticket bei uns und nicht in diesem Thread behandeln
Auch werden wir eigene Messungen bezüglich Nested Virtualization durchführen, da uns hier bislang keine nennenswerten Unterschiede bekannt sind. Völlig korrekt ist natürlich Felix' Aussage, man blockiere im Endeffekt keine Funktion, da diese - wie im Vorfeld von mir beschrieben - explizit auf dem Hostsystem aktiviert werden muss. Ich kann auch bestätigen, dass dieses Feature für 99% der Kunden nicht relevant ist. Sofern sich der Performanceunterschied bestätigen lässt, hielte ich netcups Lösung daher durchaus für fair, da man als Provider unmöglich alle "Nicht-Features" auflisten kann (so hatten wir beispielsweise mal eine Beschwerde, dass bei einem vServer - sehr zur Überraschung des Kunden - die SMART-Werte der darunterliegenden Platten nicht auslesbar sind).
Viele Grüße
Tim
Zugegebenermaßen kommen wir in Sachen I/O in dem Benchmark schlechter weg, als wir wollen. Dazu hat der Tester aber netterweise auch ein Ticket bei uns aufgemacht und wir evaluieren Leistungssteigerungen durch Hardwareänderungen bei neueren Systemen. Dennoch muss ich (da der Benchmark nun mal gepostet wurde), auch ohne den Thread dafür "hijacken" zu wollen, darauf hinweisen, dass derartige Ergebnisse nur bedingt ausschlaggebend für eine tatsächlich schlechtere Performance unter echter Workload sind. Die Erfahrung zeigt hier klar, dass die SSD-Leistung eines (v)Servers i.d.R. weit nach anderen Ressourcen ans Limit kommt und daher in der Praxis keinen Flaschenhals darstellt, auch wenn ein bewusst nur auf den SSDs Volllast generierender Benchmark deutliche Abweichungen aufzeigen kann. Ungeachtet dessen sind wir natürlich bemüht, eine verglichen mit unseren Mitbewerbern gute - auch messbare - Leistung in allen Bereichen anzubieten, aber weitere Upates zu diesem Thema würde ich gerne in besagtem Ticket bei uns und nicht in diesem Thread behandeln
Auch werden wir eigene Messungen bezüglich Nested Virtualization durchführen, da uns hier bislang keine nennenswerten Unterschiede bekannt sind. Völlig korrekt ist natürlich Felix' Aussage, man blockiere im Endeffekt keine Funktion, da diese - wie im Vorfeld von mir beschrieben - explizit auf dem Hostsystem aktiviert werden muss. Ich kann auch bestätigen, dass dieses Feature für 99% der Kunden nicht relevant ist. Sofern sich der Performanceunterschied bestätigen lässt, hielte ich netcups Lösung daher durchaus für fair, da man als Provider unmöglich alle "Nicht-Features" auflisten kann (so hatten wir beispielsweise mal eine Beschwerde, dass bei einem vServer - sehr zur Überraschung des Kunden - die SMART-Werte der darunterliegenden Platten nicht auslesbar sind).
Viele Grüße
Tim