Das längste Thema

Zitat von sudo

Woher kommt eigentlich die scheinbar als selbstverständlich angenommene Behauptung, dass das eine absichtliche Handlung sei (also die Beschränkung der I/O-Leistung) und nicht nur ein (temporäres) Problem?

Ich weiß nicht, aber wenn alle ähnlich schlechte Benchmarks haben. Kann mir nicht vorstellen, dass es am Zeitpunkt der Tests liegt. Außer zu den gängigen Backupzeiten vielleicht.
Meinst du netcup zieht Systeme freiwillig 2x um? Okay, bei außergewöhnlichen Engpässen evtl., aber allen Kunden mit einem ARM VPS nun so die Diskperformance herunter zu setzen...ich weiß nicht.

Außerdem ist es wirklich schade, dass den Kunden gegenüber nie ein vernünftiges, klares Feedback gegeben wird, z.B. hier im Forum durch Lars oder so. Jemandem der die Schnittstelle zwischen Technik und Kunden darstellt.
Auch bei massiver Kritik im Forum rührt sich niemand von Seiten des Anbieters, obwohl es ein hier paar Schnittstellen geben würde, um eine klare Kommunikation abbilden zu können. Sozusagen einen PR-Manager für die Kunden. Momentan sind da i.d.R. nur die Moderatoren in Forum von reiner Moderation des bunten Haufens hier und noch den monatlichen Aktionstagen und evtl. noch die anderen Werbekanäle.
Es fehlt mir irgendwie, diese eine Verbindung zur besseren Kundenkommunikation, das auch Sprachrohr hin zur GSL von netcup wäre.
Bislang hat sich nur Alexander ein paar Mal zwischendurch zu Wort gemeldet, aber eine Standleitung zwischen Forum und GSL / Führungs-/ Leitungsteam gibt es leider nicht.
Anders noch: Es werden wahrscheinlich alle unsere Statements mitgelesen und evtl mal als leichte Anregung beäugt, aber damit gibt es nur eine einseitige, "stasi-mäßige" Kommunikation, aber es kommt (fast) nie ein adäquates Feedback zurück. Leider.

Paul
Für ein reines "Cloudspeicher"-System ist es nicht ganz so kriegsentscheidend. Da hast du Recht.
Für andere Anwendungsgebiete, wo fortlaufend R/W-Performance benötigt wird, eher kontraproduktiv. :-/

da soll noch jemand sagen, dass Windows Updates Dinge ruinieren/zerstören ...

gestern meine 2te Fedora VM von Fedora 40 auf Fedora 41 upgegraded und Zack ...

ich habe am Desktop benutzerdefinierte Icons mit Hilfe von .desktop-Files

z.B.

[Desktop Entry]
Version=1.0
Exec=/usr/bin/firefox https://www.paypal.com/at/home/
Icon=/home/walter/myData/icons/PayPalIcon.ico
Type=Application
Categories=
Name=PayPal

sämtliche dieser benutzerdefinierten Icons waren alle ein nicht definiertes Icon;

hatte dann aus den .ico-Icon-Files .png-Bitmap-Files gemacht,

und diese in den .desktop-Files eingetragen

man glaubt es nicht, meine benutzerdefinierten Icons waren wieder da;

erklär das mal wen, dass auf einmal .ico-Icons nicht mehr gehen ..,

„Diese Erfahrungen sind ein wesentlicher Bestandteil der Nutzung von Fedora. Mit Arch wäre das nicht passiert …“

* duck' und weg …

Zitat von m_ueberall

Mit Arch wäre das nicht passiert …

Sekundiere ich, mit Arch Linux ist mir das tatsächlich noch nie passiert.

Zitat von m_ueberall

„Mit Arch wäre das nicht passiert …“

da passieren dann ganz andere Dinge

Hallo zusammen,

wir waren bezüglich der gemeldeten I/O-Problematik bei ARM VPS nach erfolgter Migration nicht untätig und haben das Problem in der Zwischenzeit bereits untersucht.

Zuerst möchte ich betonen, dass es sich hier nicht um eine absichtliche Einschränkung der I/O-Leistung durch uns handelt. Die Migrationen fanden statt, um an den Hostsystemen Wartungen an unserem Software-Stack durchführen zu können, ohne dass es zu länger andauernden Ausfällen für unsere Kunden kommt. Grund dieser nötigen Wartungen ist die Erhöhung der Stabilität der Systeme. Diese stehen also auch nicht in direktem Zusammenhang mit der berichteten eingeschränkten I/O-Leistung.

Wir haben einen Fehler gefunden und diesen behoben. Die I/O-Leistung der betroffenen Server sollte damit inzwischen wieder deutlich gebessert sein. Wir haben auch schon eine entsprechende positive Rückmeldung eines betroffenen Kunden per E-Mail dazu erhalten.

Zitat von [netcup] Lars S.

Die I/O-Leistung der betroffenen Server sollte damit inzwischen wieder deutlich gebessert sein.

Besser ja. "Deutlich besser" würde ich das aber nicht nennen, wenn ich die Werte mit meinen anderen Servern vergleiche.

Vor einer Woche:

Zitat von Virinum

Code

Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 30.56 MB/s    (7.6k) | 101.91 MB/s   (1.5k)
Write      | 30.54 MB/s    (7.6k) | 104.94 MB/s   (1.6k)
Total      | 61.10 MB/s   (15.2k) | 206.86 MB/s   (3.2k)
           |                      |                     
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 115.21 MB/s    (225) | 306.88 MB/s    (299)
Write      | 125.06 MB/s    (244) | 342.39 MB/s    (334)
Total      | 240.27 MB/s    (469) | 649.27 MB/s    (633)

Alles anzeigen

Jetzt:

Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 77.41 MB/s   (19.3k) | 199.38 MB/s   (3.1k)
Write      | 77.36 MB/s   (19.3k) | 205.31 MB/s   (3.2k)
Total      | 154.77 MB/s  (38.6k) | 404.69 MB/s   (6.3k)
           |                      |                     
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ---- 
Read       | 294.71 MB/s    (575) | 346.58 MB/s    (338)
Write      | 319.92 MB/s    (624) | 386.68 MB/s    (377)
Total      | 614.63 MB/s   (1.1k) | 733.26 MB/s    (715)

Zitat von [netcup] Lars S.

Hallo zusammen,

wir waren bezüglich der gemeldeten I/O-Problematik bei ARM VPS nach erfolgter Migration nicht untätig und haben das Problem in der Zwischenzeit bereits untersucht.

Zuerst möchte ich betonen, dass es sich hier nicht um eine absichtliche Einschränkung der I/O-Leistung durch uns handelt. Die Migrationen fanden statt, um an den Hostsystemen Wartungen an unserem Software-Stack durchführen zu können, ohne dass es zu länger andauernden Ausfällen für unsere Kunden kommt. Grund dieser nötigen Wartungen ist die Erhöhung der Stabilität der Systeme. Diese stehen also auch nicht in direktem Zusammenhang mit der berichteten eingeschränkten I/O-Leistung.

Wir haben einen Fehler gefunden und diesen behoben. Die I/O-Leistung der betroffenen Server sollte damit inzwischen wieder deutlich gebessert sein. Wir haben auch schon eine entsprechende positive Rückmeldung eines betroffenen Kunden per E-Mail dazu erhalten.

Hallo [netcup] Lars S.

Herzlichen Dank für dein positives Feedback.
Es sah, dadurch dass es sich um ein globales Problem handelte, für mich leider nach einer beabsichtigten Einschränkung aus.
Schön, dass Ihr Euch meldet.

Dann bleibt zu hoffen, dass alle Disk-I/O Werte wieder auf den alten Stand zurück kommen.

Zitat von [netcup] Lars S.

Die I/O-Leistung der betroffenen Server sollte damit inzwischen wieder deutlich gebessert sein. Wir haben auch schon eine entsprechende positive Rückmeldung eines betroffenen Kunden per E-Mail dazu erhalten.

Die Werte des "VPS 2000 ARM G11 SE (VIE/ANX..)" sind mittlerweile besser und damit auch besser als die eines "RS 2000 G8 HDD"; auch wenn man hier Äpfel mit Birnen vergleicht, würde ich mir aber noch "ein wenig mehr" Geschwindigkeit wünschen, denn ein aktueller "RS 2000 G11 SE (VIE/ANX..)" hat da einen ganz anderen Durchsatz – wir reden hier von einem Faktor >10:

(Für die (umgerechneten) Werte und fio-Testparameter siehe "VServer IOPS Comparison Sheet" unten)

Um das mal zu relativieren, bei dem Ticket ging es mir in die I/O-Latenz, nicht den Durchsatz. Die Latenz passt jetzt wieder, und das hatte ich dann auch so an den Support zurück gemeldet.

citecite

Durchsatz und I/O Latenz korrelieren in gewisserweise;

ist die I/O-Latenz sehr hoch, hemmt das den Durchsatz;

Also ich kann jedenfalls bestätigen, dass die IO-Werte bei meinem Server jetzt wieder auf dem Level von vor dem Umzug sind. Dass der ARM VPS 2000 bei 4K bessere Werte zeigt und dafür bei großen Blockgrößen schlechtere als der VPS 1000 (x86) war schon immer so. Gerade kurz getestet:

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda4):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 167.34 MB/s  (41.8k) | 256.63 MB/s   (4.0k)
Write      | 167.23 MB/s  (41.8k) | 264.26 MB/s   (4.1k)
Total      | 334.58 MB/s  (83.6k) | 520.90 MB/s   (8.1k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 318.82 MB/s    (622) | 430.59 MB/s    (420)
Write      | 346.09 MB/s    (675) | 480.41 MB/s    (469)
Total      | 664.91 MB/s   (1.2k) | 911.01 MB/s    (889)

Das kommt mir sehr gelegen, ich mag nicht schon wieder Dutzende Postfächer umziehen und an allen Clients den Mailserver ändern. Also macht keine zu guten Angebote in der Black Week. Bei mir hat die Behebung des Fehlers jedenfalls alles wieder zurück auf Normalwerte gebracht. Danke dafür. Im Moment kommt leider Vieles zusammen.

Und Debian 12 und fail2ban machen auch komische Sachen zusammen. Irgendwelche Zeitzonen-Probleme, fail2ban meckert jeden Tag über Journaleinträge mit Timestamps in der Zukunft. Ist zwar mit "RTC in local TZ: no" eingestellt, also RTC = UTC, aber ich dachte eigentlich, das sei die empfohlene Einstellung. Wie handhabt ihr das? Sollte die RTC doch besser die lokale Zeit benutzen?

Gibt es eine Weboberfläche zum selbsthosten, Open-Source für Python scripts?

Ich möchte halt von überall per Webbrowser drauf zugreifen können, und keine Python-KDE lokal installieren.

Das hier könnte schon das richtige sein, ich weiß nur nicht, ob das nur zum erstellen und bearbeiten ist. Ich will mein Geschreibsel nämlich auch direkt ausführen bzw testen können... Sonst könnte ich ja jeden beliebigen Editor nehmen:

https://vscode.dev/

Zitat von mainziman

da soll noch jemand sagen, dass Windows Updates Dinge ruinieren/zerstören ...

gestern meine 2te Fedora VM von Fedora 40 auf Fedora 41 upgegraded und Zack ...

ich habe am Desktop benutzerdefinierte Icons mit Hilfe von .desktop-Files

z.B.

Icon f. PayPal

Code: paypal.desktop

[Desktop Entry]
Version=1.0
Exec=/usr/bin/firefox https://www.paypal.com/at/home/
Icon=/home/walter/myData/icons/PayPalIcon.ico
Type=Application
Categories=
Name=PayPal

sämtliche dieser benutzerdefinierten Icons waren alle ein nicht definiertes Icon;

hatte dann aus den .ico-Icon-Files .png-Bitmap-Files gemacht,

und diese in den .desktop-Files eingetragen

man glaubt es nicht, meine benutzerdefinierten Icons waren wieder da;

erklär das mal wen, dass auf einmal .ico-Icons nicht mehr gehen ..,

Alles anzeigen

Wer Fedora verwendet muss latent Masochistisch veranlagt sei und benötigt viel Resilienz um es zu ertragen.

Zitat von m_ueberall

Die Werte des "VPS 2000 ARM G11 SE (VIE/ANX..)" sind mittlerweile besser und damit auch besser als die eines "RS 2000 G8 HDD"; auch wenn man hier Äpfel mit Birnen vergleicht, würde ich mir aber noch "ein wenig mehr" Geschwindigkeit wünschen, denn ein aktueller "RS 2000 G11 SE (VIE/ANX..)" hat da einen ganz anderen Durchsatz – wir reden hier von einem Faktor >10:

Product	Filesystem	IOPS Read	BW Read	IOPS Write	BW Write	Date
VPS 2000 ARM G11 SE (VIE/ANX..)	zfs (v2.2.6)	344	1377 KiB/s	115	460 KiB/s	10.11.2024
RS 2000 G8 HDD (NUE/ANX84)	zfs (v2.0.1)	381	1524 KiB/s	127	510 KiB/s	28.01.2021
VPS 2000 ARM G11 SE (VIE/ANX..)	zfs (v2.2.6)	509	2038 KiB/s	170	681 KiB/s	15.11.2024
RS 2000 G11 SE (VIE/ANX..)	zfs (v2.2.6)	5424	21,2 MiB/s	1813	7252 KiB/s	10.11.2024

(Für die (umgerechneten) Werte und fio-Testparameter siehe "VServer IOPS Comparison Sheet" unten)

Alles anzeigen

Kann es sein, dass die IOPS-Ergebnisse der G11 vServer nur Minimalwerte sind und nicht die Durchschnittswerte? Denn die Durchschnittswerte sind ja gewöhnlich deutlich höher?

Zitat von andreas.

Kann es sein, dass die IOPS-Ergebnisse der G11 vServer nur Minimalwerte sind und nicht die Durchschnittswerte? Denn die Durchschnittswerte sind ja gewöhnlich deutlich höher?

Die genannten IOPS-Werte sind das Ergebnis eines fio-Benchmarks (der eine gewisse Charakteristik aufweist, was die Gewichtung von Lese-/Schreibzugriffen anbelangt), welcher auf dem ARM64 ca. 30min läuft; bei sehr ähnlichen Werten zu unterschiedlichen Zeiten ist zwar zu erwarten, dass etwas Luft nach unten oder oben ist, aber nicht wesentlich. "Deutlich höhere Durchschnittswerte" würde ich hier ausschließen wollen – das ist eher Glück mit der jeweiligen Instanz. (Andererseits messe ich auch nicht 24h auf verschiedenen Instanzen desselben Typs, um die Ergebnisse zu mitteln.)

Zitat von [netcup] Lars S.

Unsere Priorität, insbesondere im Bereich E-Mail-Versand, liegt aktuell auf einer weiteren Erhöhung der Zustellbarkeit, auch an große Freemail-Provider, die oftmals sehr strikte Maßstäbe an die Annahme von E-Mails setzen. Hier haben wir in den letzten Jahren und Monaten auch schon große Fortschritte gemacht, insbesondere im Bereich shared Webhosting. Dennoch sind hier noch weitere Verbesserungen möglich und derzeit auch aktiv in Umsetzung. Sicherlich kann zukünftig auch DANE zu diesen Optimierungen zählen. Es ist aktuell aber nicht unser Hauptfokus und wir halten andere Optimierungen derzeit für wichtiger, um weiterhin ein hohes Maß an Qualität im Bereich des E-Mail-Versands sicherstellen zu können.

Seit dem Beitrag ist ja nun schon ein wenig Zeit vergangen und gebe mal Rückmeldung:

ich finde es hat sich tatsächlich spürbar gebessert, was die Webhostings betrifft.

Mittlerweile ist die Zuverlässigkeit bei der Zustellung von eMails an die üblichen Verdächtigen ziemlich gut geworden.

Zitat von Borgqueen

Wer Fedora verwendet muss latent Masochistisch veranlagt sei und benötigt viel Resilienz um es zu ertragen

Das kommt schon gut hin, ich habe damals mit Redhat angefangen und bin mittlerweile auf dem Desktop bei Ubuntu. Wenn etwas schief läuft oder nicht klappt, ist bei Fedora nen Abend getüfftel angesagt. Dagegen ist Debian ohne Desktop wie Fahrradfahren.

Ich habe schon so viele Linux Distributionen ausprobiert und Fedora ist mit Abstand die stabilste und zuverlässigste Distribution, die mir unter gekommen ist. Ich habe Fedora Server, die laufen schon seit Jahren und haben unzählige dnf system-upgrades hinter sich. Auch meine berufliche Workstation läuft schon ewig mit Fedora, weil ich mich da auf ein stabiles OS verlassen will, was aber trotzdem einigermaßen aktuelle Software bietet. Privat läuft bei mir zwar primär Archlinux, weil ich da die unkomplizierte Installation von unfreien Treibern und Software bevorzuge (das ist das einzige, was mich wirklich etwas an Fedora stört), habe aber trotzdem ein paar Fedora Testsysteme (Gerade die Atomic Varianten probiere ich hin und wieder mal aus).

Zitat von Borgqueen

Wer Fedora verwendet muss ...

bei den anderen brauchst gleich an Mainframe