Beiträge von SiebenG

Zitat von ASS

Sollte euer Unterthema nicht besser in einen eigenen Thread ausgegliedert werden?

Es gehört ja nicht wirklich zu "Benchmarks RS / VPS Produkte", sondern eher zu "Probleme mit vollverschlüsselten Dateisystemen auf Vservern"...

Ja, Du hast Recht, DatAres nehmen wir doch den Thread hier falls wir dazu nochwas diskutieren müssen.

Es scheint übrigens nichts mit einer Verschlüsselung zu tun zu haben, sondern einfach mit einer vollen SSD, siehe verlinkter Thread.

Ich habe gerade vor einer Minute eine Antwort auf mein Ticket bekommen, daher gehe ich davon aus, dass das Problem mit den vollen Festplatten jetzt sowieso behoben ist:

> vielen Dank für Ihre Anfrage.

> Das beschriebene Verhalten sollte durch eine durchgeführte Speicheroptimierung im SCP beim Server unter Medien nachhaltig gelöst werden.

> Ich wünsche Ihnen einen schönen Abend.

Dann probiere ich das gleich mal aus

Well, if you are very close to your plan limit you may run into the issue I talked about earlier.

If you are using Bitlocker (encryption) it is even more likely to occur.

However, we hope the netcup team resolves that issue soon.

Anyhow, what could help in the meantime is:

- do not fill up your SSD space to the last byte

- shutdown your host and start using SCP if the server runs into I/O problems

- Did you install qemu-guest-agent? If your drive is not encrypted I think it tells the host about freed blocks if you delete files...

You might be suffering from the same issue as discussed here (in German) by me and another customer.

The problem is, when disk is full or near-full the I/O performance drops to nearly zero and the server hangs completely.

It seems like customers with disk encryption are suffering more often (because disk is always full from the view of the host).

If you state that usage goes above your plan (your 2nd screenshot is not showing that) it could be the case that you are running into this issue as well.

You can temporarily fix this problem by shutting your server down and start it via SCP (a "normal" reboot does not help). Unfortunately, the problem will reoccur about 24 to 48 hours later.

Zitat von waqaspuri

2a03:4000:9:1cd:54b6:93ff:fe35:219b

So this?

No, your IPv6 IP is 3a03:4000:9:1cd::1 (in case you last post is correct and it starts with a 2 than 2a03:4000:9:1cd::1....)

The gateway should be fe80::1

For example my /etc/network/interfaces looks like this:

iface eth0 inet6 static

address XXXX:XXXX:XXXX:XXXX::1

netmask 64

gateway fe80::1

dns-nameservers 2a03:4000:0:1::e1e6 2a03:4000:8000::fce6

dns-search XXXX

(whereas I am only using one/the first IP ::1 out of the /64 network)

Zitat von waqaspuri

This is my server's IP address

xxxx:54b6:93ff:fe35:219b/10

3a03:4000:9:1cd::/64

Should be mine publicly accessible IP will be 3a03:4000:9:1cd::1 ?

Yes, that is correct.

The first network is for routing purposes and contains your gateway. Probably fe80::1 (?)

Zitat von DatAres

Bisher sind die IOWaits 24 Stunden nach der Speicheroptimierung nicht mehr aufgetreten. Ich werds noch etwas länger beobachten.

Ich drücke die Daumen ... bei mir lief der Server diesmal 42 Stunden, bevor es wieder los ging...

Nochmal eine Rückfrage zur Speicheroptimierung: Wie sieht das bei Dir im SCP genau aus nach der Speicheroptimierung. Steht dann da, dass Du genau die Festplattenkapazität erreicht hat, oder bist Du immer noch über dem Limit Deiner SSD?

Zitat von DatAres

Definitionsfehler von mir: Der Fehler lässt sich durch einen Reboot nicht beseitigen. Nur mit einem Ein- und Ausschalten des kompletten Servers. Ein Reboot bekommt das Hostsystem soweit ich weiß ja nicht mit, aber ein Ein-/Ausschalten schon. Würde daher ja schon dafür sprechen, dass sich auf dem Hostsystem in dem Moment etwas ändert.

Ja, das ist bei mir genauso. Reboot bringt nichts, nur Aus- und wieder Einschalten.

Ich habe jetzt mal meine ganze SSD vollgeschrieben, bis es nicht mehr geht, um zu sehen, ob dies das Problem triggert, dem ist aber nicht so.

Vor dem Vollschreiben im SCP: vda: 302 GiB von 240 GiB belegt

Nach dem Vollschreiben: vda: 343 GiB von 240 GiB belegt

Mehr als 240GiB gingen aber nicht auf die Platte. fio Disk Speed hatte danach völlig normale Werte...

Zitat von DatAres

SiebenG Benutzt du zufälligerweise auch Ubuntu 24.04.3 LTS? Vielleicht gab es ja wirklich eine softwarespezifische Änderung in einem Update.

Nein, ich bin auf Debian 12, Kernel 6.1.0-38. Ich hatte beim ersten Auftreten des Problems ja auch noch den SCSI konfiguriert, (virtio/virtio_blk gar nicht verwendet), daher vermute ich weniger eine OS-Problematik.

Wäre super, wenn Du das Ergebnis Deiner Speicheroptimierung teilst, gerne auch mit Auslastungswerten Deiner vda vorher/nachher im SCP.. Ich habe das noch nie gemacht, nach meinem Verständnis würde das bei einer Vollverschlüsselung auch nichts bringen, da aus Sicht des Hosts halt einfach alle Blöcke belegt sind.

Zitat von SiebenG

Ich werde weiter beobachten und hoffe, dass es das nun war...

Ich habe mich leider zu früh gefreut. Nach genau 47 Stunden uptime tritt das Problem erneut auf, auch mit virtio.

Was ich aber jetzt weiß, es kommt plötzlich.

Hier mein fio Test von 11:47 Uhr:

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mapper/bambus--vg-root):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 114.42 MB/s  (28.6k) | 476.13 MB/s   (7.4k)
Write      | 114.73 MB/s  (28.6k) | 478.63 MB/s   (7.4k)
Total      | 229.15 MB/s  (57.2k) | 954.76 MB/s  (14.9k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 756.62 MB/s   (1.4k) | 852.04 MB/s    (832)
Write      | 796.82 MB/s   (1.5k) | 908.78 MB/s    (887)
Total      | 1.55 GB/s     (3.0k) | 1.76 GB/s     (1.7k)

Und hier mein Test von 12:47 Uhr:

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/mapper/bambus--vg-root):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 744.00 KB/s    (186) | 938.00 KB/s     (14)
Write      | 781.00 KB/s    (195) | 1.01 MB/s       (15)
Total      | 1.52 MB/s      (381) | 1.95 MB/s       (29)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 914.00 KB/s      (1) | 893.00 KB/s      (0)
Write      | 1.02 MB/s        (2) | 1.03 MB/s        (1)
Total      | 1.94 MB/s        (3) | 1.92 MB/s        (1)

Und ja, da steht wirklich KB/s. Und ja, da steht tatsächlich auch 0 IOPS. Der erste Test lief übrigens 34 Sekunden, der zweite 35 Minuten.

DatAres ich habe genau das gleiche beobachtet wie Du, das wait des Prozesses ging auf 98% hoch.

Hat noch irgendjemand eine Idee, was ich tun könnte (außer alle 12 Stunden neu zu booten)?

Zitat von DatAres

Bei einem RS sollte die CPU doch immer gleich abliefern, da dediziert? Gibt es bei Netcup jetzt überhaupt irgendwas Dediziertes? Ich gehe aus dem Thread mit mehr Fragen raus, als ich reingekommen bin

Also der Hauptunterschied zwischen VPS und RS ist, dass beim VPS mehr Kerne pro Knoten verkauft werden, als da sind. Das könnte sich negativ auswirken, indem Dir jemand anders Teile "Deines" Kerns belegt, Das erkennst Du daran, ob Dein VPS einen "CPU Steal" hat, die gelbe Kurve in Deinem Plot bzw. im "top" der Wert "st". Falls der bei Dir hoch ist, könnte sich ein Wechsel auf einen RS lohnen.

Zweiter Unterschied ist, dass beim RS beim Kauf eine garantierte CPU angegeben ist (derzeit EPYC 9634 == Zen4 Architektur), meist die neuste Generation. Beim VPS ist es ein Lotteriespiel, kannst Glück haben, kannst aber auch auf einem bisschen älteren Server landen. Was ich so im Forum lesen, haben VPS derzeit zwischen Zen2 und Zen4 alles dabei (Rome, Milan, Genoa). Will sagen: also neben geteilter CPU auch mindestens eine CPU Gerneration älter. Zen4 schein im Single Core Benchmark grob 100% schneller zu sein als Zen2.

Zu Deiner Frage, warum beim RS Benchmarks schwanken: Zum einen gab es hier wohl vor kurzen eine Konfigurationsänderung beim RS G11, da wohl einige mit der Leistung nicht zufrieden waren und es wohl jetzt besser laufen soll. Zum zweiten können Benchmark-Leistungen auch auf dedizierten RS-Kernen auch Schwanken, tun sie aber selten. Single-Core sollte weniger Schwanken als Multi-Core. Ich habe bei meinen RS auch schon 20% Einbußen im SingleCore gesehen, ist aber wirklich selten (kein steal). Warum? Trotz dediziert zugewiesenen CPU Kern teilst Du Dir einige Komponenten mit anderen Usern, insbesondere die Speicherbandbreite und auch den L3-Cache. Lastet das jemand anders gerade aus, hast Du auch beim RS weniger Performanz. Als drittes gibt es auch noch bei modernen CPUs den sog. "Turbo" Modus, d.h. die können für kurze Zeit (60 Sekunden oder so) extrem stark Hochtakten. Falls Du jetzt einen Benchmark machst und "zufällig" diesen Turbo-Modus erwischt, bekommt Du auch überdurchschnittliche Ergebnisse...

Zitat von DatAres

Disk Speed konnte ich wegen Verschlüsselung auch nicht testen.

Okay, also Verschlüsselung ist der gemeinsamme Nenner. D.h. bei Dir ist auch die Festplatte voll laut SCP?

Bei mir steht da:

Speichernutzung vda: 302 GiB von 240 GiB belegt

Ist eigentlich auch seltsam, wenn man mal so drüber nachdenkt ...240 GiB stimmt aber, laut Vertrag und meine vda ist auch so groß.

Zitat von andreas.

Zum Nachstellen bzw. zum Teststen könntest du auch Local Block Storage (LBS) von 50 GB zu unter einem Euro pro Monat zum Server dazu bestellen.

Das gibt's nicht bei meinem Produkt, das ist zu alt.

Könnte sein, dass wir das gleiche IO-Problem haben? Schau mal hier.

Meine IOPS sind von 32000 auf 800 runter, meine Datenrate von 1,7 GB/s auf 5MB/s, der Server praktisch nicht mehr zu gebrauchen. Allerdings habe ich einen Root-Server.

Mir sind die Probleme Mittwoch aufgefallen und ich versuche es seit dem zu Debuggen. Der Support wollte von mir einen yabs im Rettungssystem haben, funktioniert allerdings nicht richtig. Das Rettungssystem hat keine funktionierende DNS Auflösung und (nach Beheben dieses Problems) meine Festplatte zu wenig freien Speicher (da LUKS verschlüsselt) um den fio Disk Speed von yabs auszuführen.

Ein Reboot (vor dem Gewurschtel mit dem Rettungssystem) hat keine Besserung gebracht, das Aus- und wieder Einschlaten dann schon. Ich dachte erstmal super, Problem gelöst, aber nach ca. 10-12 Stunden war es dann wieder unbenutzbar.

Da ich meinen Server schon vor 8 Jahren aufgesetzt habe, war der HDD-Treiber noch auf SCSI (war ein Server mit SAS Platten und damals so voreingestellt) und ich hatte auch einen Snapshot.

Ich habe jetzt mal den Snapshot gelöscht, den Treiber auf virtio umgestellt (war ein bisschen Bastelei, da der erstmal nicht gebootet hat) und dann hat mir das SCP mitgeteilt, dass meine Festplatte in einem veralteten Format ist und geändert werden muss.

Ich werde weiter beobachten und hoffe, dass es das nun war...

Wie sieht das bei Dir aus? Festplatte recht voll oder verschlüsselt? Ggf auch SCSI-Treiber? Snapshots?

Bei meinem RS ist seit heute morgen komplett die Luft raus. Ist zwar schon eine ältere Generation, aber ich war immer bei >700 MB/s bei 1m Blöcken.

Seit ein paar Stunden sieht es so aus:

---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 11.87 MB/s    (2.9k) | 5.85 MB/s       (91)
Write      | 11.88 MB/s    (2.9k) | 6.16 MB/s       (96)
Total      | 23.75 MB/s    (5.9k) | 12.01 MB/s     (187)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 5.49 MB/s       (10) | 5.49 MB/s        (5)
Write      | 6.20 MB/s       (12) | 6.17 MB/s        (6)
Total      | 11.70 MB/s      (22) | 11.66 MB/s      (11)

Insgesamt bin ich nur drauf gekommen, da sich der Server heute ein wenig zäh anfühlt. Reboot hat nicht geholfen.

Update - wird immer schlimmer:

Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 3.20 MB/s      (801) | 2.93 MB/s       (45)
Write      | 3.22 MB/s      (805) | 3.10 MB/s       (48)
Total      | 6.42 MB/s     (1.6k) | 6.03 MB/s       (93)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 2.99 MB/s        (5) | 2.86 MB/s        (2)
Write      | 3.11 MB/s        (6) | 3.12 MB/s        (3)
Total      | 6.10 MB/s       (11) | 5.98 MB/s        (5)

Ich benutze unbound nur für spamassassin. Einfach in die spamassassin config ein:

dns_server 127.0.0.1

Je nach Distro gibt's ggf auch ein /etc/spamassassin/65_dns.cf

Und die resolv.conf auf netcup DNS lassen. Klappt wunderbar. Generell ist es aber wahrscheinlich eine gute Idee postfix so zu konfigurieren, dass die "Limit"-Fehler den score nicht beeinflussen. Ich verwende Exim und Spamassassin macht das automatisch richtig ...

Gibt ja immer mal ein paar Listen, die einen schnell blockieren, auch bei unbound. Stichwort Validity und die Anbieter, die die aufgekauft haben...

Zitat von tab

Das mag der ursprüngliche Hostname deines Servers sein, der aus welchem Grund auch immer zurückgesetzt wurde. Hatte ich auch mal, da betraf es allerdings nur die Reverse-DNS Einträge für die IPv4 und IPv6, was aber trotzdem für einen Mailserver ziemlich fatal ist, weil er damit nimmer viel zugestellt bekommt. Ist aber bei mir seitdem nicht mehr passiert. Der eigentliche Hostname des Servers war allerdings immer noch der selbe, den ich ihm gegeben hatte.

Hatte ich auch mal, erst ein paar Monate her...

Der IPv4 rDNS war noch okay, meine beiden IPv6 rDNS Einträge aber sang- und klanglos gelöscht!

Bei mir läuft auch ein Mailrelay, und ich habe ewig gesucht ... Fehlerbild war, dass einge Empfänger, die auf IPv6 laufen (z.B. gmail) meine e-mails als Spam markiert haben, bei den meisten, die mit IPv4 only laufen war alles wie immer :-/

Zitat von Askaaron

Wem Performance wichtig ist, der muss beizeiten auch auf neuere Server umstellen.

Kann ich nicht bestätigen.

Mein RS 500 SAS G7SE a1wurde irgendwann mal von einem Xeon E5-2660V3 auf einen AMD EPYC-Rome verschoben. Der hat 1025 Geekbench im Single-Core.

Ich vermute wenn man so 4 Generationen wartet wirft netcup die alten Server weg und es wird deutlich schneller .. jedenfalls ist mein G7 um 20% schneller als G8