Posts by Paul

    Vielleicht fehlt mir diesbezüglich einfach das Wissen. Wenn ich aber ein solch signifikant höheren Steal Time sehe und dazu noch von anderen lese, daß dies zu hoch sei um zuzugreifen, erwarte ich nicht, daß was ich in meinem Ticket selbst geäußert habe, daß die Ressourcen geteilt werden und gewisser "steal" der Norm entspricht als Antwort zurück ?(

    Da müssen wir auch 2 Dinge unterscheiden. Wenn tab schrieb, dass 50% mal ok waren und das jetzt auf 60% erweitert wurde, meinte er nicht, dass es generell ok wäre, so einen hohen Steal zu haben, sondern dass es für Netcup ok ist, wenn eine Kunden VM aus der (ARM) VPS Serie einen solchen Steal hat und sie bei einer Meldung/einem Ticket diesbezüglich nichts unternehmen werden.


    Generell ist nämlich ein Steal von 50% eigentlich gar nicht ok. Auch schon 30% Steal sind im Grunde zuviel, wenn man die CPU Leistung eigentlich bräuchte. Es geht hier eher darum, ab wann man sich deswegen beim Support melden sollte. Und da sagt Netcup, dass sie erst ab einer gewissen Grenze etwas machen. Im Grunde ist das dann eigentlich auch ok, weil die ARM Server sehr billig sind und man sowas eigentlich erwarten müsste. Für den Preis muss es quasi überbucht sein. Da muss man auch als Kunde Abstriche in Kauf nehmen. Ich habe mir das selbst auch schönreden wollen und dachte, ich kann mit dem ARM Server 30% sparen und trotzdem die gleiche Leistung erwarten. Sogar mehrmals. Aber irgendwann erkennt man dann doch, dass man etwas mehr bezahlen sollte, wenn man schon penibel auf die Leistung schaut.

    Huch? Schlechte Erfahrungen gemacht?

    Leider ja. Ich hatte seit Einführung der ARM Server jetzt mehrere (inkl. BETA). Im Idle war immer alles ok. Aber sobald etwas Load auf die Server kam, ist wirklich bei jedem der Steal immer direkt auf 40-60% förmlich explodiert. Da bringen mir halt die 10 Cores eines VPS ARM 2000 relativ wenig, wenn man sie eh nicht wirklich nutzen kann. Da bleibe ich dann doch lieber bei meinen x86 VPS, die bei exakt gleichem Workload einen Steal von <1% aufweisen und zahle den minimalen Aufpreis mehr. Und da das nicht nur bei einem, sondern allen und das zeitlich verteilt aufgetreten ist, bin ich mit der ARM Serie im Moment generell etwas vorsichtig.


    Im Grunde kann ich es auch verstehen. Der günstige Preis muss ja irgendwo herkommen. 10 Cores für 10,79 €und dann noch 1TB NVME Disk. Da muss man irgendwo Abstriche in Kauf nehmen. Es gibt sicher auch zufriedene Kunden, vor allem wenn man die vielen Cores nicht braucht.

    Wenn man es natürlich streng sieht, dann sollte ein Backup grundsätzlich nie beim gleichen Provider liegen, wo auch die produktiven Daten verarbeitet werden. Ein evtl. gesperrter Kundenaccount würde z.B. den Zugriff auf das produktive und das Backup System sperren. Daher wäre im Falle der VPS Lösung eigentlich ein weiteres Backup erforderlich. Je nach Wichtigkeit des Systems wäre das durchaus denkbar und auch sinnvoll. Man könnte z.B. 2 Mailserver haben, die mittels Dovecot dsync Replikation die Daten synchron halten und gleichzeitig ein Backup in die Storagebox schreiben.

    SnowBerryZ danke für die Info. Bin derzeit in Diskussion mit mir, ob lieber einen zweiten VPS, 1000 ARM G11, oder 'ne Storage Box für das Backup der Mailcow. Preislich macht das keinen großen Unterschied.

    In diesem Fall würde ich sogar eher zu dem VPS tendieren. Dieser hat den Vorteil, dass er im Notfall auch als Backup System live gehen kann, wenn mit dem produktiven System irgendwas längerfristiges nicht mehr funktionieren sollte. Da hat man denn für den gleichen Preis noch einen zusätzlichen Vorteil/Nutzen.

    Ja das stimmt ^^ der ist aber vom Preis mehr an einem "RS 4000 G11" dran, da verwirrt Preis/Leistung was den Namen betrifft

    Ja, definitiv. Das war auch mein erster Gedanke, dass der 2000 Ultra eigentlich nur der normale, "fehlende" RS 3000 ist, den es so im normalen Sortiment gar nicht gibt (mit ein klein bisschen größerer Disk). Aber vermutlich gibt es durchaus eine Zielgruppe dafür. m_ueberall wollte ja ein Produkt mit mehr RAM. Zumindest sein Wunsch wurde erfüllt ^^ .

    Auf Nummer sicher zu gehen ist immer besser. Es muss keine Malware sein. Aber dass so ein Prozess läuft - ohne dass man es will und dann auch noch 100% CPU Load verursacht - ist immer ein Warnsignal. Genaueres wird man erst wissen, wenn man sich den Container (am besten in einer isolierten Umgebung) genauer anschaut. Es ist prinzipiell immer riskant, wenn man fremde Container lädt und laufen lässt. Da helfen einem dann auch die gut gemeinten Sicherheitsvorkehrungen nichts, wenn man als Admin die Malware selbst installiert. Früher hatte man in Linux signierte Repositories/Pakete um genau solche Szenarien so gut wie möglich zu verhindern. Durch die neue Container Welt untergräbt man das diese Konzept halt wieder. Hat alles seine Vor- und Nachteile.

    Quote

    pg_recvlogical is a command-line tool included with PostgreSQL used for managing and consuming logical replication slots. It facilitates the streaming of changes from a logical replication slot, enabling real-time data capture and consumption. pg_recvlogical acts as a consumer of data, receiving changes from the replication slot and outputting them to a specified file or standard output.

    Dass dieser Prozess 100% CPU nutzen soll, ist etwas seltsam. Zumindest dann, wenn es sich tatsächlich um den genannten Postgres Prozess handeln sollte. Welche Container laufen denn alle bei dir? Es könnte sich natürlich auch gut um Malware handeln, die sich hinter diesem Prozess versteckt (und sich nur so genannt hat um nicht aufzufallen). Versuche hier wirklich mal den Container und den Prozess zu lokalisieren und genauer zu untersuchen. Falls dein System wirklich kompromittiert wurde, solltest du das auf keinen Fall einfach so weiter betreiben. Versuche also wirklich so schnell es geht da Klarheit zu schaffen. Vielleicht bringt ja auch irgendein Container oder ein Nextcloud Plugin eine integrierte Postgres Installation mit. Du kannst dir ja auf dem Host alle Prozesse mal anschauen und überprüfen, ob da noch andere Postgres Prozesse laufen. Müsste ja eigentlich, wenn alles mit rechten Dingen zugehen sollte.

    Ah, Fedora hat sie in den Repos als aktuellste Version. Narf.

    Hah, tatsächlich. Dabei laufen fast alle Server bei mir sogar mit Fedora (aber keiner davon nutzt Apache) ^^. Aber dass Fedora aktuellere Pakete als Archlinux hat, sieht man auch nicht alle Tage.

    Da nicht einmal Archlinux diese Version bisher in seinen Repos hatte, dürfte die wohl glücklicherweise eigentlich nirgends im Einsatz sein (es sei denn man hat Apache selbst kompiliert).

    Der Wert von 2010 Punkte bei dem "AMD EPYC 7513" ist wirklich beachtlich! Habe ich so nicht nirgends gesehen :/

    Auf den zweiten Blick hat der EPYC 7513 aber auch einen Grundtakt von 2,6GHz. Merkt man in der Praxis nicht wirklich, aber bei Benchmarks deutlich. ;) Die 10-15% lassen sich damit völlig problemlos erklären. Das ist ja auch der Grund, warum Desktop PCs bei solchen Benchmarks deutlich besser abschneiden, obwohl sie nur ein Bruchteil einer Server CPU kosten. Nicht ohne Grund sind ja gerade für Gaming Server Desktop CPUs wie der Ryzen interessant und werden auch bei einigen Providern entsprechend angeboten.

    Der EPYC 9643 hat einen Grundtakt von 2,25Gz und einen Turbo Boost von bis zu 3.7 GHz. Gerade bei Benchmarks kann so ein Boost für deutlich bessere Werte sorgen. Netcup hat ja in der Vergangenheit schon bestätigt, dass sie den Turbo Boost durchreichen. Da sich diesen aber alle VMs auf dem Node teilen müssen, ist es oft Glückspiel, wer ihn gerade erhält und ob er überhaupt in seinem maximalen Wert erreicht wird. Es gibt noch einen All Core Max Wert von 3.1 GHz.


    Wenn ich also Single Core Werte lese, die an 2000 oder darüber sind, dann würde ich mal stark behaupten, dass hier von dem Turbo Boost profitiert wurde. Je weniger auf dem Node gerade los ist, desto höher ist ja die Wahrscheinlichkeit, dass man davon profitiert. Realistisch sind sicherlich Werte von 1600-1800, die durch den Grundtakt erreicht werden. NIchtsdestotrotz sind das immer noch sehr gute Werte, die 50% über denen vorheriger Generationen liegen. Ich konnte hier jetzt auch noch keinen Fall sehen, wo das deutlich unter 1600 gefallen ist.


    An der reinen CPU Leistung kann man Netcup hier wohl keinen Vorwurf machen. Das passt soweit. Die Disk Performance ist dann natürlich ein ganz anderes Thema. Hier wird Netcup schon irgendwie dafür sorgen, dass die Leistung gerecht verteilt wird. Sie machen halt auch keinerlei Garantien oder Versprechungen, welche IO Leistung ein RS erwarten kann. Daher ist das immer ein schwieriges Thema, weil man als Kunde zwar unzufrieden sein kann, aber keinen wirklichen Punkt hat, auf den man sich berufen kann. Es wird nur die Größe in den Leistungsdaten erwähnt.

    Auf der anderen Seite sind die 4k Werte besser. Insgesamt scheinen RS also zwar niedrigere, dafür aber konstantere Werte zu haben, die weniger schwankungsanfällig sind und auch unter Last noch die gleiche Leistung bringen.


    Disk Benchmarks sind immer noch so eine Sache für sich. In der Praxis wird man nämlich gar keinen Unterschied feststellen können zwischen 500MB/s und 2GB/s, weil man solche Brandbreiten nie wirklich erreichen wird. Das gibt ja allein die Netzwerk-Anbindung gar nicht her. In der Praxis sind ganz andere Werte wichtig. Z.B. die Latenz oder IOPS. Da merkt man dann wirklich, ob die Applikation langsam oder schnell reagiert.


    Ich habe mal einen VPS mit dem neuen RS Ultra vergleichen. Die durchschnittliche Brandbreite war bei beiden in etwa gleich. Dafür hatte der RS weniger Schwankungen in der Latenz (3ms vs 13ms). Hier kommen dann auch Werte wie iowait zum Tragen, die vermutlich beim RS besser sein werden und vor allem in Last Situationen weniger stark nach oben hin ausreißen.


    Ich will das jetzt auch nicht schönreden und am Ende muss das jeder für sich selbst entscheiden, ob er mit der Leistung zufrieden ist oder nicht. Ich möchte nur den Gedankengang teilen, dass für die tatsächliche Leistung die Bandbreite nicht zwingend entscheidend ist und einem ein falsches Bild vermitteln kann. Ich selbst mache meistens den Test, dass ich einfach die Applikation installiere und mir das Verhalten dort anschaue. Ich vergleiche dann z.B. die gefühlte Ladezeit und Werte wie TTFB. Sind diese dann auch schlechter, dann wäre ich auch unzufrieden ;).

    Doch, soweit würde ich mich schon aus dem Fenster lehnen. Diese Phishing Kampagne richtig sich ganz explizit an Netcup Kunden. Ob da auch vereinzelt Nicht-Netcup-Kunden betroffen sind, kann sicherlich sein. Aber hier hat sich schon jemand Gedanken gemacht, wen er hier anschreiben muss. Das ist nicht die übliche Spamliste von Mailadressen, weil ein Service Provider ein Datenleck hatte. Da wurde schon ganz gezielt nach Domains gesucht.

    Das ist m.E. auch garnicht der Fall.

    Die Mails gehen einfach wahllos an eine beliebige Liste von Domainnamen.

    Ich glaube ihr interpretiert da viel zuviel Intelligenz hinein... :)

    Ja, das hat vermutlich gar nichts damit zu tun. Zumal halt auch Domains betroffen sind, bei denen Netcup gar nicht der Registar sind. Aber irgendwoher muss diese Liste ja kommen. Die Domains fallen ja nicht vom Himmel. Zumal die ja alle expliziten Zusammenhang mit Netcup haben. Die Domains findet man ja nicht einfach gerade mal so zufällig, nur weil der A Record zufällig auf eine Netcup IP auflöst.


    Es würde mich ja nicht wundern, wenn dafür sogar eine KI im Einsatz war, die als Prompt die Aufgabe bekommen hat, Domains zu suchen, deren Record auf eine Netcup IP auflöst :).


    RS 1000 G11 Ultra NUE FJUL25

    Auch gerade laufen lassen, sieht solide aus, nur von Disk Speed hätte ich mir mehr erwartet, oder ist das normal bei den aktuellen RS Servern? Meine VPS haben hier teils das 3 fache an Disk Speed 🤔

    Ich würde mit den Benchmarks noch ein wenig warten. Im Moment werden ja sehr viele neue Server provisioniert, was einen nicht ganz üblichen Workload auf den Nodes erzeugt. Viele VM Images werden erstellt, Image Installationen durchgeführt. Das kann durchaus (vor allem Disk) Performance kosten. Das erklärt auch, warum die CPU Benchmark ganz gut ist (die Kerne sind ja dediziert), aber die physischen Disks sind ja weiterhin shared. Das wird sich sicher die nächsten Tage beruhigen, wenn sich der Workload normalisiert. Dann kann man das ja nochmal in Ruhe testen.

    Heute sind meine Postfächer weitgehend verschont geblieben, weil die Spammer wohl einen Fehler mit dem Reverse DNS gemacht haben. 60 Zustellversuche, alle aus diesem Grund abgewiesen und somit gleich ab mit der IP in das fail2ban Jail. Ok, etwas mehr als die Hälfte davon wäre sowieso abgewiesen worden, weil die Adresse nicht existiert. Aber das Jail wäre ihnen erspart geblieben.

    Ja, hier genauso:

    Code
    NOQUEUE: reject: RCPT from unknown[89.144.5.230]: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [89.144.5.230]; from=<newsletter@zapef.com> to=<webmaster@domain.tld> proto=ESMTP helo=<zapef.com>

    Was mich vor allem irritiert, ist der Punkt, dass die Mails an Domains adressiert sind, die im Grunde völlig inaktiv sind. Da gibt es weder eine Webseite, noch eine Mailbox, noch ist diese sonst wo irgendwo öffentlich vertreten (nur die Standard RFC Adressen für abuse, postmaster & Co und daher einen mx Eintrag). Die wurden von mir einfach schon mal registriert um evtl. später mal genutzt werden zu können. Da wundert es mich schon ein wenig, wie diese auf die Liste gekommen sind. Einfach mal so kann man ja nicht mal eben alle Domains abfragen, die ein Registrar verwaltet (zumindest nicht ohne internen Zugriff). Auch sind die Nameserver nicht die gleichen. Einige Domains sind bei Netcup, andere bei Cloudflare und eine auch bei desec. Damit hängt es also auch nicht zusammen. Schon etwas merkwürdig.