Beiträge von saremox

This forum is a "Customer helping Customer" forum mainly. So you won't find any support staff here especially on not business hours. Use the emergency hotline: https://www.netcup.com/de/helpcenter/support

Falls nicht, erreichen Sie einen unserer Techniker außerhalb der regulären Hotline-Zeiten (17:00 – 09:00 Uhr - Europa/Berlin) direkt unter folgender Telefonnummer: +49 721 754 0 755 5

Zitat von Michael Saleeb

Und was die Verwendung von KI zur Strukturierung eines Beitrags betrifft: Auf KI zu verzichten, nur um möglichst „natürlich“ zu wirken, ist kein Beweis für Intelligenz – eher für natürliche Dummheit.

Dann ein gut gemeinter Rat: Gib deinen LLM der Wahl mit, dass es sich bei den Rezipienten deiner Texte um Menschen handelt, welche Freiwillig dir helfen wollen und das LLM bitte möglichst wenig ausschmückend schreiben soll.

Ich finde es kann nicht die Aufgabe von uns sein deinen Text erst einmal in ein LLM zu gießen um eine debloated Version zu bekommen. Wir alle hier tauschen uns komplett unentgeltlich und freiwillig aus. Daher empfinde ich auch solche langen typischerweise (ChatGPT macht das sehr gerne) sich wiederholenden Texte als despektierlich ggü. dem Lesenden.

Das wollte ich btw auch mit meiner ersten Antwort ausdrücken. Dort hatte ich als Beispiel ChatGPT gebeten eine maximal inhaltsleere Antwort zu geben...

Und eine wertere Bitte: Auch ggü. Supports E-Mails oder anderen Dienstleistern das gleiche. Ich war schon auf der Empfangenden Seite von solchen LLM Müll und empfand das Respektlos. Hat den Kunden letzten Endes aber auch direkt mehr gekostet, da es dadurch erheblich länger gebracht hat zu verstehen was dieser überhaupt möchte. Evtl sollte Netcup ja auch anfangen Normalen Support separat Abzurechnen mit maybe 10-20 € pro 15 Minuten

Zitat

Moin, kannst du mir bitte eine möglichst ausladene Antwort auf einen Foren Post schreiben in dem daerauf hinweist das "ROTA" bei einer VDA überhaupt nichts aussagt darüber ob die vda wirklich auf HDD oder SSD liegt und das der OP doch einfach einen Benchmark machen soll. Versuche soviele Sätze wie möglich zu machen ohne dabei großartig informationen bereitzustellen. Es soll für den Lesenden die größtmöglich Zeitverschwendung sein:

Evtl muss ich nochmal schauen ob es einen Allgemeineren Prompt gibt den ich demnächst nutze für solche Foren Post wie in den anderen Thread. Meine das sich ja auch schon andere Darüber beschwert haben das es wie Zeitverschwendung anfüllt... Ist ja nicht so das man ein "Please be very concise, volunteers are trying to help me" beim Prompt hinzufügen könnte.

Wenn das die Qulität und Quantität ist, die der Netcup Support aktuell bekommt dann haben die mein Mitleid... Das ja schrecklich

Zitat von Michael Saleeb

Betreff: VPS nano G11s iv 6M NUE – SSD beworben, aber als HDD bereitgestellt?

Ich glaube, hier wird gerade etwas zu viel Bedeutung in den Wert ROTA beziehungsweise /sys/block/vda/queue/rotational hineininterpretiert.

Der entscheidende Punkt ist nämlich, dass du innerhalb eines VPS eben nicht das physische Laufwerk des Hostsystems siehst, sondern ein virtuelles Blockdevice.

In deinem Fall ist das /dev/vda.

Und /dev/vda ist zunächst einmal genau das: ein virtuelles Laufwerk, das dir vom Hypervisor beziehungsweise von der Virtualisierungsschicht präsentiert wird.

Wenn Linux für dieses virtuelle Laufwerk nun ROTA=1 beziehungsweise rotational=1 meldet, bedeutet das zunächst lediglich, dass dieses virtuelle Blockdevice gegenüber dem Gast als rotierend gekennzeichnet wurde.

Das bedeutet aber nicht automatisch, dass sich darunter tatsächlich eine klassische HDD befindet.

Zwischen deinem Gastbetriebssystem und dem tatsächlichen physischen Storage können mehrere Schichten liegen.

Das kann lokaler Storage sein.

Das kann RAID sein.

Das kann SSD sein.

Das kann NVMe sein.

Das kann ein Storage-Cluster sein.

Das kann ein verteiltes Storage-System sein.

Das kann Netzwerk-Storage sein.

Und theoretisch kann es natürlich auch eine HDD sein.

Nur lässt sich genau diese Frage aus dem ROTA-Wert eben nicht beantworten.

Der Wert sagt dir nicht:

„Deine Daten liegen physisch auf einer rotierenden Festplatte.“

Er sagt dir:

„Das virtuelle Blockdevice, das dein Gast sieht, wurde als rotational markiert.“

Das ist ein durchaus relevanter Unterschied.

Auch die Ausgabe

cat /sys/block/vda/queue/rotational

ändert daran nichts.

lsblk denkt sich diesen Wert schließlich nicht selbst aus, sondern nutzt Informationen, die der Kernel über das Blockdevice kennt.

Wenn also sowohl lsblk als auch sysfs dort eine 1 anzeigen, bestätigt das im Wesentlichen nur, dass Linux konsistent dieselbe Eigenschaft für dieses virtuelle Gerät sieht.

Es bestätigt aber nicht, welche Hardware tatsächlich unterhalb des Hypervisors steckt.

Anders gesagt:

Dein Gastbetriebssystem kann nur das wissen, was ihm die Virtualisierungsschicht mitteilt.

Es hat keinen magischen Blick durch den Hypervisor hindurch bis in das Server-Rack.

Wenn dort also beispielsweise physisch NVMe-SSDs verbaut wären, die Virtualisierungsschicht das virtuelle Gerät aber trotzdem mit rotational=1 bereitstellt, dann sieht dein Gast eben trotzdem ROTA=1.

Umgekehrt wäre übrigens auch ROTA=0 kein unwiderlegbarer Beweis dafür, dass physisch ausschließlich SSDs darunter liegen.

Dann wäre das virtuelle Laufwerk eben als nicht rotierend gekennzeichnet.

Mehr nicht.

Natürlich wäre bei einem SSD-basierten Backend rotational=0 vermutlich die sinnvollere Einstellung.

Schon deshalb, weil Betriebssysteme solche Informationen teilweise für I/O-Optimierungen verwenden.

Und es würde sicherlich auch solche Missverständnisse vermeiden.

Aber das ist eine andere Frage als die Frage, ob ROTA=1 beweist, dass dein VPS auf HDD liegt.

Das beweist es eben nicht.

Ich würde deshalb an deiner Stelle einfach das testen, was am Ende tatsächlich relevant ist:

die Storage-Performance.

Also einen Benchmark machen.

Und dafür würde ich eher fio verwenden als dd.

dd ist hervorragend darin, Daten von A nach B zu kopieren.

Das macht es seit sehr langer Zeit ausgesprochen zuverlässig.

Als Storage-Benchmark ist es aber nur begrenzt aussagekräftig.

Ein sequentieller Schreibtest zeigt dir beispielsweise nicht wirklich, wie sich das System bei kleinen zufälligen Zugriffen verhält.

Und gerade dort sieht man Unterschiede zwischen klassischem HDD-Storage und SSD-basiertem Storage normalerweise wesentlich deutlicher.

Interessant wären zum Beispiel:

4K Random Read.

4K Random Write.

IOPS.

Latenzen.

Sequential Read.

Sequential Write.

Und gegebenenfalls das Ganze mit unterschiedlichen Queue Depths.

Dann hast du zumindest konkrete Messwerte.

Die sagen zwar ebenfalls nicht zwingend, welches genaue physische Laufwerksmodell irgendwo im Rechenzentrum verbaut ist.

Aber sie sagen dir etwas viel Wichtigeres:

Welche Storage-Leistung bekommt dein VPS tatsächlich?

Und das dürfte für dich praktisch deutlich relevanter sein als ein einzelnes Flag eines virtuellen Blockdevices.

Natürlich muss man auch bei solchen Benchmarks vorsichtig sein.

Ein VPS läuft normalerweise auf geteilter Infrastruktur.

Das bedeutet, dass ein Benchmark um 10:00 Uhr andere Ergebnisse liefern kann als derselbe Benchmark um 18:00 Uhr.

Wenn andere Kunden gerade viel I/O erzeugen, kann das die Messwerte beeinflussen.

Außerdem kann der Anbieter den Storage absichtlich begrenzen.

Ein VPS auf NVMe-Storage muss deshalb nicht zwangsläufig mehrere Gigabyte pro Sekunde liefern.

Man kann SSD-Storage problemlos auf bestimmte IOPS oder bestimmte Transferraten limitieren.

Deshalb wäre auch

„nur 300 MB/s, also keine SSD“

keine besonders belastbare Schlussfolgerung.

Viel interessanter wären meiner Meinung nach vor allem Random-I/O und Latenzen.

Wenn du dort beispielsweise Werte bekommst, die mit klassischen HDDs praktisch nicht sinnvoll erklärbar wären, dann hast du einen ziemlich guten Hinweis darauf, dass du nicht einfach auf einer einzelnen rotierenden Platte gelandet bist.

Und wenn die Werte dagegen auffällig schlecht sind, dann hast du zumindest etwas Konkretes, mit dem du beim Support nachfragen kannst.

Dann lautet die Frage nämlich nicht mehr:

„Bei mir steht ROTA=1, habe ich eine HDD?“

sondern beispielsweise:

„Mein VPS erreicht bei 4K Random Read nur X IOPS und Y ms Latenz. Entspricht das der vorgesehenen Storage-Klasse für dieses Produkt?“

Damit kann ein technischer Support meiner Meinung nach deutlich mehr anfangen.

Die unterschiedliche Bezeichnung zwischen G11s und G11.5s würde ich davon übrigens zunächst einmal getrennt betrachten.

Es kann durchaus sein, dass sich Marketingbezeichnungen geändert haben, während interne Produktnamen gleich geblieben sind.

Es kann auch sein, dass intern andere Generationen oder Varianten existieren.

Aber auch daraus folgt nicht automatisch etwas über den physischen Storage.

Die Kombination

„Produktname sieht anders aus“

plus

„ROTA=1“

ergibt noch keinen belastbaren Beweis für

„netcup liefert HDD statt SSD“.

Dafür fehlen schlicht die entscheidenden Informationen.

Wenn du es wirklich sauber klären möchtest, würde ich deshalb zwei Dinge machen:

Erstens einen vernünftigen fio-Benchmark durchführen.

Zweitens netcup direkt fragen, ob das Produkt auf SSD-/NVMe-basiertem Storage liegt und warum das virtuelle Laufwerk mit rotational=1 präsentiert wird.

Dann hast du sowohl die praktische als auch die technische Seite abgedeckt.

Denn am Ende ist die entscheidende Aussage eigentlich erstaunlich kurz:

ROTA=1 bei /dev/vda sagt dir, dass dein virtuelles Blockdevice als rotierend markiert ist.

Es sagt dir nicht zuverlässig, ob der darunterliegende physische Storage tatsächlich aus HDDs besteht.

Und bevor man aus diesem einen Bit eine größere Theorie über die Hardware des Providers entwickelt, würde ich schlicht fio starten und messen, was das Ding tatsächlich leistet.

Das dürfte am Ende sehr viel mehr Erkenntnis bringen als noch fünf weitere Varianten von lsblk, udevadm oder irgendwelchen sysfs-Dateien auszulesen, die letztlich alle dieselben Informationen über dasselbe virtuelle Blockdevice anzeigen.

Kurz gesagt:

Benchmark machen.

Ergebnisse posten.

Dann kann man weiterdiskutieren. 🙂

Bei mir hat es ein Nano erwischt:

Problem: SSH service is down on Saremox - Gateway A
Problem started at 16:18:04 on 2026.02.19
Problem name: SSH service is down on Saremox - Gateway A
Host: Saremox - Gateway A
Severity: Average
Operational data: Down (0)

Problem: Saremox - Gateway A has been restarted (uptime < 10m)
Problem started at 17:50:15 on 2026.02.19
Problem name: Saremox - Gateway A has been restarted (uptime < 10m)
Host: Saremox - Gateway A
Severity: Warning
Operational data: 00:00:23

Zum Glück hat der B-node übernommen. Zumindest gab es keine Alarme das Dienste ausgefallen sind.

Zitat von Borgqueen

lässt sich BigBlueButton auch mit Apache installieren an Stelle von nginx?

Bisherige Erfahrung von meiner Arbeit ist, dass man am besten gar nicht vom Install Skript abweichen soll.
Frisches Ubuntu aufsetzen und dann das Install Skript laufen lassen.

Alles andere ist nicht wirklich supported und macht nur mehr aufwand, den man dann bei jeden Update wieder hat.

Zitat von mmaark

Okay also reicht der Server aus , mit z.b hunderte Mitglieder, die registriert wären? Natürlich sind nicht alle gleichzeitig aktiv die Mitglieder,...

Es kommt hier sehr Stark darauf an was für eine Software du für deine Webseiten einsetzt und was das genaue Nutzungsverhalten ist. Wenn es ein Blog/Newsseite ist, wo ein großteil der Last sowieso damit reduziert werden kann durch entsprechendes sinnvolles Caching reicht das Teil wahrscheinlich auch für 1000 Tägliche Benutzer/Besucher.

Wenn da jetzt ein Forum drauf läuft und du 100 User hast ist die Last eine andere, aber auch da würde ich sagen reicht der Server aus.

Wenn das jetzt eine Nextcloud/Owncloud oder andere rechenintensive PHP anwendung ist muss man eben schauen wie das Verhalten von den 100 Users ist. Wenn da jeder einen Desktop Syncclient an hat und da ordentlich durch geht, kommt man da evtl bei einen VPS so langsam an dem Punkt wo in Peak Zeiten die UX (Ladezeiten und Reaktivität) schlechter werden könnte.

Wenn da jetzt ein Custom Written Browser game drauf läuft sieht es sowieso noch einmal ganz anders aus.

Was ich dir aber auf jeden Fall empfehlen kann ist, dir eine Software mal auf den Server zu installieren und laufen zu lassen die deine Systemlast aufzeichnet:

- UptimeKuma https://github.com/louislam/uptime-kuma - Ist eine Software die hier sehr gerne von Menschen im Forum genutzt wird. Natürlich macht das Monitoring im Sinne von "Ist die Webseite/Server gerade ausgefallen" nur dann Sinn wenn du das auf einen 2. Server laufen lässt. Wenn es jetzt aber erst einmal nur darum geht deine Systemlast mal schön aufzuzeichnen und dann dir die Graphen anzusehen ist das ein recht gutes Tool.
- Zabbix - Lernkurve ist hier wahrscheinlich etwas steiler, ist aber das Tool welches ich gerne für Traditionelle VMs nutze, das aber wohl auch eher aus Macht der Gewohnheit und weil ich dort bereits ein Setup habe mit Benachrichtigungen über ein Telegram Bot
- atop - Kleinen Tools was top/htop ähnlich die System auslastung aufzeichnet. Bedienung ist sehr gewöhnungsbedürftig.

Bonus punkte wenn du in die Software noch Metriken einfließen lässt wie "Anfragen / s vom Webserver", "Aktive Nutzer". Dann kannst du direkt deine Systemlast mit dem Nutzerverhalten korrelieren.

Zitat von dalu

Ok ich hatte UEFI nicht aktiv.

Das Upgrade war gefühlt instant.

Habe UEFI nun an, und dank deiner coolen animierten Anleitung das 2. device ausgewählt, aber wenn ich enter drücke flackert es kurz und wenn ich raus gehe und continue passiert nichts. Es ist noch immer das standard device eingestellt, wahrscheinlich weil das System nicht per UEFI installiert wurde.

Seit Talos 1.11 installiert er nur noch den Bootloader der benötigt wird und nicht mehr beides. D.h. du müsstest damit es mit UEFI klappt mindestens einmal ein: talosctl -n <ip> upgrade machen über den boot mit der ISO. Hab das aber bisher selber noch nicht gemacht ein BIOS zu UEFI konvertieren mit Talos. BIOS geht ja gar nicht mit den ARM64 kisten.

Zitat von dalu

Das Problem ist halt, BIOS meint vda ist boot disk und findet keinen boot sector o.ä. weil, wie bei dir ceph bluestore.

Und vdb hat das Talos system.

Shit ja da bin ich auch schon rein gelaufen. Deswegen hab ich diesen "Hack", dass ich als install drive vda (also immer die größere) nehme und dann das Ephemeral auf das LBS packe.

talosctl -n 192.168.32.10 get discoveredvolumes
NODE            NAMESPACE   TYPE               ID      VERSION   TYPE        SIZE     DISCOVERED   LABEL       PARTITIONLABEL
192.168.32.10   runtime     DiscoveredVolume   loop1   1         disk        672 kB   squashfs
192.168.32.10   runtime     DiscoveredVolume   loop2   1         disk        66 MB    squashfs
192.168.32.10   runtime     DiscoveredVolume   rbd0    1         disk        11 GB    ext4
192.168.32.10   runtime     DiscoveredVolume   sr0     1         disk        1.1 GB
192.168.32.10   runtime     DiscoveredVolume   vda     1         disk        1.1 TB   gpt
192.168.32.10   runtime     DiscoveredVolume   vda1    1         partition   2.2 GB   vfat         EFI         EFI
192.168.32.10   runtime     DiscoveredVolume   vda2    1         partition   1.0 MB   talosmeta                META
192.168.32.10   runtime     DiscoveredVolume   vda3    1         partition   105 MB   xfs          STATE       STATE
192.168.32.10   runtime     DiscoveredVolume   vda4    1         partition   1.1 TB   bluestore                r-storage
192.168.32.10   runtime     DiscoveredVolume   vdb     1         disk        54 GB    gpt
192.168.32.10   runtime     DiscoveredVolume   vdb1    1         partition   54 GB    xfs          EPHEMERAL   EPHEMERAL

Hilft dir jetzt natürlich nicht viel. Ich schaue mal gleich ob ich noch im Kopf habe wie ich damals das gefixt hab (muss dafür aber mal kurz eine node drainen, zum testen), dass zumindest das System wieder bootet. Gab beim UEFI von den ARM kisten zumindest eine Möglichkeit interaktiv explizit von der vdb zu booten.

EDIT:

TalosBootNetcupARM64UEFI-2.gif

EDIT2:

wahrscheinlich wurdest du aufgrund des Updates auf ein anderes Host System umgezogen. Nach meinen Verständnis verschwinden dann die EFI einstellungen die z.B. talos gemacht hat. Danach ist der Default wieder das auf der "Ersten" Block device nach einer EFI partition mit bootx64.efi/bootxaarch.efi gesucht wird.

Moderatoren würde mir wünschen wenn man die BootOrder der Block devices im SCP wählen könnte. Das würde sowas deutlich reboot safer machen und man bräuchte keine Hacks (die erst kürzlich mit Talos 1.11 möglich sind) brauchen, wenn man vda als Bluetstore für ein CEPH nutzen möchte.

I know mega special anwendungscase den nicht jeder hat. Wäre aber trotzdem mega toll

Ich betreibe auch ein 9 Nodes Talos Cluster bei Netcup mit ARM VPS. Hab da auch schon ein VPS Upgrade gemacht und das ging wunderbar. Das war aber mit einer Älteren Talos version irgendwann letztes Jahr, wenn ich mich richtig erinnere.

Wäre auf jeden fall cool wenn du deine Erkenntnisse hier weiter schreibst.

Ich habe auf der Maindisk vda eine Partition für Ceph Bluestore und ein 50 GB LBS für Ephemeral/System

machine:
  [...]
  install:
    bootloader: true
    image: factory.talos.dev/metal-installer/ce4c980550dd2ab1b17bbf2b08801c7eb59418eafe8f279833297925d67c7515:v1.11.2
    wipe: true
    diskSelector:
      size: ">= 128GB"
---
apiVersion: v1alpha1
kind: VolumeConfig
name: EPHEMERAL
provisioning:
  diskSelector:
    match: disk.size < 128u * GB
  grow: true
  minSize: 16GB
  maxSize: 128GB
---
apiVersion: v1alpha1
kind: RawVolumeConfig
name: storage
provisioning:
  diskSelector:
    match: disk.size > 128u * GB
  grow: true
  minSize: 128GB

EDIT: ich habe irgendwann angefangen mit diskselector nach Größe zu arbeiten, weil ich einige Nodes hatte wo auf einmal das LBS device vda war (warum auch immer).

Zitat von webdesignheld

Die KI hat den Schnipsel bekommen und den kompletten Mail Header von der Support email die an die gleiche Adresse ging an der die automatische Mail gescheitert ist. Ich wollte das auch nur berichten aber ich danke dir natürlich für die ausführliche Darlegung deiner Meinung zu dem Thema. Deine Auffassung wie der Schnipsel zu interpretieren ist teile ich, dazu braucht man ihn ja auch nur lesen.

Wenn nicht Hilfe beim Debugging oder Verstehen von dem E-Mail Zustellproblem, was war deine Intention das hier zu posten?

Dir ist bewusst, dass eine Automatische E-Mail, auch wenn sie über den gleichen SMTP-Relay Provider gesendet wird, anders von z.B. rspamd (Ist jetzt eine Stellvertreter Software, andere Software wird wahrscheinlich nach ähnlichen Metriken die Mail bewerten) gewertet wird als eine Support Antwort oder? Oder das der MTA der es raussendet in dem Fall eine Andere IP sein kann, die vielleicht eine bessere Reputation hat?

Zitat von webdesignheld

Please forward this to your mail operations team.
My domain is example.com. Your automated mail system reports
“550 [S10] Blocked” from mx1.mailchannels.net [18.236.29.166] when
sending verification emails. Your support replies arrive normally
(from 213.133.106.242 via MailChannels inbound).
This appears to be a MailChannels-to-MailChannels internal block.
Could you request MailChannels to delist your transactional relay IP?

Alles anzeigen

Und das ist, mit den Informationen aus dein Posting, der Grund warum man nicht alles so in eine KI pusten sollte. Besonders wenn man, selbst sagend, keine Ahnung davon hat.

In dem Schnipsel den du vom Support bekommst steht, meiner Auffassung nach, eben nicht das mx1.mailchannels.net die Mail ablehnt. Sondern das mx1.mailchannels.net versucht sie zuzustellen und vom dem MX deiner Mailbox ein 550 bekommt.

Da du hier leider auch nicht sagst wo deine Mailbox liegt (Nectup Webhosting, Mailkuh, Mailbox, whatever) kann man hier auch gar nicht großartig weiter helfen zu debuggen oder eine Sinnvollere Antwort mit dir zu formulieren als das von der KI.

KI ist mega toll und ein sehr gutes Tool Aufgaben die man selbst schon verstanden hat in vielen Fällen mit den richtigen Prompt schneller zum Ergebnis zu kommen. Man sollte aber in der Lage sein durch sein Wissen die Antwort von der KI zu bewerten. KI kann sehr viel schneller das gewünschte verhalten in ein Bash script von 100-200 Zeilen runter schreiben, aber ich muss das dann auch lesen können und beurteilen ob das korrekt ist. Wenn ich keine Ahnung habe von Automatisierung mit Bash, ist das einfach nur Roulette spielen und hoffen das es korrekt ist...

Btw ich korrigiere lieber Schreibfehler von anderen in einer Konfiguration, als Ständig AI-SLOP lesen zu müssen. Also falls du interessiert bist dein Problem zu debuggen kannst ja erstmal von Vorne anfangen:

• Wo liegt deine Mailbox?
• Hast du zugriff auf die SMTP Logs?
• Ist ein Spam Filter aktiv?
• Hast du Blocklisten aktiv (Spamhaus, UCEPROTECT etc. pp.)?
• Überprüfst du DKIM / SPF / DMARC?

Falls dir etwas aus der Liste unbekannt vor kommt oder du nicht genau weißt was es bedeutet frag entweder hier nach oder Google es einmal kurz.

Und weil ich aufgrund von Geekbench6 Ergebnissen auf eigener Hardware mal nachgeschaut habe, sollte man die Multi-Core Werte vom Yabs Benchmark mit GB6 etwas mit Vorsicht genießen:

Zitat von GB7 Internals, Page 7

Geekbench 6 uses a “shared task” model for multi-threading, rather than the “separate task” model used in earlier versions of Geekbench. The “shared task” approach better models how most applications use multiple cores.

The "separate task" approach used in Geekbench 5 parallelizes workloads by treating each thread as separate. Each thread processes a separate independent task. This approach scales well as there is very little thread-to-thread communication, and the available work scales with the number of threads. For example, a four-core system will have four copies, while a 64-core system will have 64 copies.

The "shared task" approach parallelizes workloads by having each thread processes part of a larger shared task. Given the increased inter-thread communication required to coordinate the work between threads, this approach may not scale as well as the "separate task" approach.

Bei einen 24 Kern Root-Server, lässt man ja meist eher mehrere Anwendungen (php-fpm und andere Server Client Anwendungen, Datenbanken, Caches, etc. pp.) parallel laufen, die dann ein anderes Skalierungsverhalten haben als ein Prozess mit 24 Threads und Synchronisierung zwischen diesen.

Was mich noch wundert ob SMT deaktiviert ist auf den Hosts? Sind es 24 Physische Cores oder 24 Threads die in die VM gegeben werden.

AWS beispielsweise reicht teilweiseThreads durch, es wird aber transparent auch einen gesagt wie viele Physische Cores man bekommt. Beispiel:

Wenn es SMT Threads sind, könnte das evtl. auch erklären was hier einige sehen... Das wäre dann aber, in meinen Augen, falsches Marketing... Dann ist die Performance die man bekommt ja immer Wundertüte.

Zitat von sla

Bei nur 50% der Leistung die ich davon nutzen kann, kann man schon über eine Rechnungsminderung nachdenken. Da scheint richtig was im Argen zu sein

Glaube das wird nichts. Du hast keinen Anspruch auf eine bestimmte Leistung hier. Der Vertrag sagt du bekommst Exklusiv 128 GiB Memory und 24 Kerne.

Da ist keine Garantie, dass du zu jeder Zeit immer die Performantesten Cores im Maximalen Turboboost bekommst. Wenn gerade alle auf dem Host ihre V-Server auslasten, gibt es halt für jeden nur maximal den All-Core Boost clock, der ist natürlich nicht so schnell, als wenn du der einzige auf dem Host System bist der gerade Last erzeugt und damit den vollen Turboboost abgekommst.

Ich glaube Netcup würde sich selbst einen Gefallen tun, wenn sie einfach den Turboboost im Bios/Firmware deaktivieren.

Edit: Aus den Specs der CPU:

Max. Boost-Taktung: Bis zu 3.7 GHz

All Core Boost Speed: 3.3 GHz*

Grundtaktung: 2.3 GHz

Wenn du in dem Moment nur den Baseclock abbekommst ist es halt 1,5 Ghz weniger. Das macht halt schon etwas aus bei IO und Geekbench

*EPYC-21: All-core boost for AMD EPYC™ processors is the average frequency of all processor cores running in performance mode while utilizing a low activity workload. Actual achievable all-core boost will vary based on hardware, software, workloads and other conditions.

Zitat von m-k

Auf 10Mbit/s kann man ja offensichtlich begrenzen, die 1Gbit/s gehen nicht, auch wenn bei mir nur maximal diese ankommen. Leider kenne ich mich nicht im Detail mit dem Wireguard Protokoll aus, kann mir aber nicht vorstellen, dass der Gegenpart mit angeblich bis zu 20Gbit/s verschickt, wenn mein RS nur 1Gbit/s entgegennehmen kann.

Wireguard läuft i.d.R. über UDP. Die Senderseite muss hier dann den Traffic begrenzen. Ein Limit (Hard & Softwareseitig) auf Empfängerseite führt jetzt nicht automatisch dazu, dass die Senderseite die Senderate reduziert. D.h. wenn deine Sendeseite ein 10Gbit Anschluss hat, machst im Zweifel dein 10Gbit Link voll wenn die Sende-CPU das schafft.

Unter Debian/Unbuntu nfs-common installiert? Was sagt

 # which mount.nfs4
/usr/sbin/mount.nfs4
 # which mount.nfs
/usr/sbin/mount.nfs

Zitat von monospacedmagic

Leider scheint auch die Konfiguration via Kernel-Parameter nicht zu funktionieren. Hier ist der Parameter, mit dem ich es versucht habe, als Beispiel:

ip=123.45.67.89/22::123.45.64.1:255.255.252.0:yourhostname:ens3:off::::

Die Kernel Parameter funktionieren bei Factory talos meist nur für die Update OCI images. Grundsätzlich hab ich es noch nie gehabt, dass die Kernel Parameter bei den Raw Disk Images funktionieren.

Du kannst die Machineconfig von Talos als CloudInit ablegen. Du musst dann aber ein nocloud image verwenden anstatt eines metal image. Wichtig ist, dass du dann in der Machineconfig bereits die IP's aus dem SCP hinterlegst:

machine:
  [...]
  network:
    hostname: w1.egg.eggcellent.cloud
    interfaces:
      - addresses:
          - 152.xxx.xxx.xxx/22
        deviceSelector:
          hardwareAddr: xx:xx:xx:72:a7:bb
        dhcp: false
        mtu: 1500
        routes:
          - gateway: 152.xxx.xxx.1
            network: 0.0.0.0/0
# Falls vorhanden VLAN hinzufügen, sinnvoll wenn du mehr als 1 node hast und darüber das Cluster Netz aufbauen willst
      - addresses:
          - 192.168.xxx.xxx/24
        deviceSelector:
          hardwareAddr: xx:xx:xx:72:a7:bc
        dhcp: false
        mtu: 1500
 [...]

Ich habe das aber bisher auf Netcup nicht getestet. Unter Proxmox bei mir auf der Arbeit funktioniert es darüber aber wunderbar.

Edit: Okay gerade getestet mit dem NoCloud image. Ist in die Hose gegangen, man kann bei einen Custom Image leider bei Netcup kein CloudInit mitgeben Ich setzte dann mal meinen einen Worker neu auf

Moin,

du musst sehr wahrscheinlich über das Talos Dashboard die Konfiguration vom Netzwerk Interface vornehmen. DHCP funktioniert hier leider nicht ganz so gut. Grundsätzlich ist hier über das SCP dein Freund zum debuggen. Hab bei Netcup aktuell ein 6 Nodes Talos cluster am werkeln. Kann also bestimmt die ein oder andere weitere Frage beantworten

Viel Erfolg und Spaß!

LMGTFY

pasted-from-clipboard.png