danke für dein Feedback. Sehen wir uns an und passen ggf. an was da noch nicht ganz korrekt ist.
Eventuell ist es sinnvoll, diesen Haken, man nutze das System nur als Gewerbetreibender, durch jeweiligen Nutzer eigenständig wieder rausnehmen lassen zu können.
Wie ich zum Zeitpunkt der Anmeldung - aufgrund folgender Bedingungen - festgestellt habe, sieht es so aus, als würde sich dieses Angebot nur an Gewerbetreibende richten.
Wird dieses Angebot später auch für Privatpersonen freigeschaltet werden?
"I am entering into this contract in the course of my business activity and am not acting as a consumer within the meaning of the Austrian Consumer Protection Act."
My little 1,94 Euro/Month G8 VPS
Try running the same test again with a file size of 10 GB instead of 4 GB. You’ll be surprised at how quickly the I/O performance drops off.
Alles anzeigenMy latest FIO test still shows very poor storage performance:
Metric Result
Read IOPS 14,716
Write IOPS 4,922
Combined IOPS ≈19,638
Read bandwidth 57.4 MiB/s
Write bandwidth 19.2 MiB/s
Average read latency 2.99 ms
Average write latency 4.06 ms
99th percentile read latency 10.99 ms
99th percentile write latency 12.63 ms
Disk utilization 64.8%Should netcup be concerned about potential legal consequences in Germany if its servers are advertised as using high-performance NVMe storage while customers receive substantially lower performance, especially when support tickets concerning the issue remain unanswered for several days?
Did you happen to test the RAM instead of the virtual NVMe?
Wenn ich mir auf einem RS 8000 G11 folgendes Ergebnis ([r=475,w=475 IOPS]) so anschaue, so sieht es so aus, dass auf dem Host eher nur SATA SSD´s im RAID 1 Verbund verbaut sind.
fiotest: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=1
fio-3.19
Starting 1 process
fiotest: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [m(1)][100.0%][r=1902KiB/s,w=1902KiB/s][r=475,w=475 IOPS][eta 00m:00s]
fiotest: (groupid=0, jobs=1): err= 0: pid=1146: Thu Jul 30 20:55:39 2026
read: IOPS=450, BW=1803KiB/s (1847kB/s)(106MiB/60001msec)
slat (usec): min=5, max=211, avg=13.17, stdev= 5.70
clat (nsec): min=861, max=8901.3k, avg=185372.90, stdev=95952.63
lat (usec): min=24, max=8926, avg=198.70, stdev=96.80
clat percentiles (usec):
| 1.00th=[ 20], 5.00th=[ 24], 10.00th=[ 29], 20.00th=[ 159],
| 30.00th=[ 178], 40.00th=[ 190], 50.00th=[ 202], 60.00th=[ 215],
| 70.00th=[ 227], 80.00th=[ 241], 90.00th=[ 262], 95.00th=[ 277],
| 99.00th=[ 314], 99.50th=[ 338], 99.90th=[ 537], 99.95th=[ 750],
| 99.99th=[ 1418]
bw ( KiB/s): min= 1304, max= 2208, per=100.00%, avg=1804.93, stdev=185.14, samples=119
iops : min= 326, max= 552, avg=451.23, stdev=46.30, samples=119
write: IOPS=450, BW=1802KiB/s (1845kB/s)(106MiB/60001msec); 0 zone resets
slat (nsec): min=5958, max=70646, avg=14046.75, stdev=5371.07
clat (usec): min=422, max=6578, avg=2003.36, stdev=337.57
lat (usec): min=429, max=6593, avg=2017.56, stdev=338.17
clat percentiles (usec):
| 1.00th=[ 1172], 5.00th=[ 1369], 10.00th=[ 1663], 20.00th=[ 1795],
| 30.00th=[ 1876], 40.00th=[ 1942], 50.00th=[ 2008], 60.00th=[ 2073],
| 70.00th=[ 2147], 80.00th=[ 2245], 90.00th=[ 2376], 95.00th=[ 2507],
| 99.00th=[ 2900], 99.50th=[ 3228], 99.90th=[ 4178], 99.95th=[ 4555],
| 99.99th=[ 5866]
bw ( KiB/s): min= 1552, max= 2144, per=100.00%, avg=1803.80, stdev=116.83, samples=119
iops : min= 388, max= 536, avg=450.95, stdev=29.21, samples=119
lat (nsec) : 1000=0.01%
lat (usec) : 20=0.70%, 50=7.21%, 100=0.18%, 250=34.54%, 500=7.36%
lat (usec) : 750=0.05%, 1000=0.06%
lat (msec) : 2=24.89%, 4=24.95%, 10=0.06%
cpu : usr=0.48%, sys=1.88%, ctx=54076, majf=0, minf=16
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=27050,27024,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
READ: bw=1803KiB/s (1847kB/s), 1803KiB/s-1803KiB/s (1847kB/s-1847kB/s), io=106MiB (111MB), run=60001-60001msec
WRITE: bw=1802KiB/s (1845kB/s), 1802KiB/s-1802KiB/s (1845kB/s-1845kB/s), io=106MiB (111MB), run=60001-60001msec
Disk stats (read/write):
vda: ios=26979/80919, merge=0/26970, ticks=4816/51350, in_queue=105257, util=94.05%
real 1m24,772s
user 0m2,322s
sys 0m15,752sMir ist allerdings immer noch nicht klar, warum der Einsatz einer Virenscanner Software ein Sicherheitsrisiko darstellen soll.
Eventuell könnte es auch ein Trojaner sein?
Habt ihr Ideen?
Eventuell den vServer kündigen und auf echtes Blech wechseln? Denn es gibt einige Provider, die ihre älteren Generationen von Servern über deren Serverbörse sehr günstig vermieten.
Wer sich es zutraut und auch etwas Zeit mitbringt, seinen eigenen vServer zu administrieren, kann sich solche Anwendungen bei Bedarf auch per Knopfdruck über KeyHelp, welches nur ca. 10 Euro / Mon. kostet, auf seinen eigenen vServer installieren.
Angebotene Anwendungen über KeyHalp Pro:
Also der Support ist absolut nicht lösungsorientiert. Hauptsache ein Produkt verkaufen, welches nicht so funktioniert wie dargestellt. Viel schlimmer ist eher, dass mein alter Hoster quasi Netcup beworben hat, und hier ein konkreter Kontakt mit Netcup bestand, bei dem zu meinem Gemfile Umfang mitgeteilt wurde, dass das im Managed Hosting überhaupt kein Problem ist. Genau....
Eventuell hatte dein bisheriger Hoster dir die Produkte Managed Private Server empfohlen. Denn laut der Webseite unter der URL https://www.netcup.com/de/... wird unter anderem auch folgendes dazu geschrieben:
"Managed Private Server bieten die Flexibilität eines eigenen Servers kombiniert mit professioneller Betreuung. Die Server können unter Berücksichtigung der Machbarkeit und Sicherheit individuell eingerichtet werden. Durch das Management von netcup bleiben Systeme stets aktuell, sicher und zuverlässig, während du dich voll auf dein Kerngeschäft konzentrieren kannst."
Danke, aber ich meine diesen Terminal im SCP.
Ja, das Terminal meinte ich auch.
Wie macht ihr das?
Was die Zeichenkette aus der Zwischenablage betrifft, markiere ich den gewünschten Text im CLI- oder Editor-Fenster mit der Maus und kopiere ihn mit Strg + C. Anschließend füge ich die Zeichenkette in der Konsole (im Terminal) mit Strg + V ein.
Da es wahrscheinlich ein VirtIO-Storage-Treiberproblem mit der Version 0.1.285 / 100.101.104.28500 geben wird, würde ich an deiner Stelle mal folgendes ausprobieren:
Wenn nach der Systembeobachtung weiterhin solche oder auch ähnliche Fehler wie PAGE_HASH_ERRORS_0x1a_3f auftreten, würde ich an deiner Stelle netcup mit Dumps, Treiberversionen und Zeitstempeln kontaktieren und Host-/Storage-Node-Migration verlangen.
Meine Fragen an die Community: ...
Damit dir eventuell auch einer aus dem Forum helfen kann:
Auf welchen Server Type bzw. Produktbezeichnung (z.B. RS 4000, G 12) tritt dieses Problem auf? Denn einfach RS/KVM reicht leider nicht aus, da der Provider Netcup mehrere verschiedene Produktvarianten auf diesen Hypervisor betreibt.
Ja die Setup-Gebühren sind echt heftig, aber allgemein die Preiserhöhung bei Subnetzen, Hardware usw. sind ja auch nicht ohne ...
Meines Wissens sind bei denen die Subnetze nicht angehoben worden. Denn von denen ist man als Kunde es gewohnt, als Betroffener vorher diese Preisanpassungen auf sein schon bestehendes Produkt, wie z.B. dem Subnetz, auch persönlich mitgeteilt zu bekommen.
Am 27.05.2026 hat ein Mitbewerber aus Falkenstein in seinem Kundenforum unter der Überschrift Standardisierung und Preisanpassung unserer Server-Produkte ab 15. Juni 2026 eine kurzfristige Preisanpassung angekündigt.
Details dazu findet man im entsprechenden Forum des Anbieters.
Für einige Kundinnen und Kunden könnte das insbesondere dann interessant sein, wenn sie dort beispielsweise eine Storage Box zur Datensicherung nutzen - etwa für Backups eines Netcup Servers.
Eventuell sollte man beim neuen Server-Control-Panel (https://www.servercontrolpanel.de/scp-ui/) auch direkt über eine eigene Zwei-Faktor-Authentifizierung nachdenken.
Aus meiner Sicht wäre das ein sehr sinnvoller Schritt - eventuell sogar wichtiger als eine optische Überarbeitung des Designs. Denn gerade bei einem Server-Control-Panel sollte zusätzliche Sicherheit eine höhere Priorität bekommen.
ifconfig_vtnet0_ipv6="inet6 2a03:4000:5:f44:affe:beef:cafe:deaf/64"
In dieser Zeile gehört inet6 nicht mit rein und müßte von daher wie folgt aussehen: ifconfig_vtnet0_ipv6="2a03:4000:5:f44:affe:beef:cafe:deaf/64"
doch, aber das mache ich ungern ohne Not auf Verdacht in's Blaue. Wäre mein erster 15er, .0 vermeide ich normalerweise und IPv6-only ist auch etwas speziell, aber irgendeiner ist ja der Erste.
P.S.: im Nachhinein ärgerlich, erst kürzlich ging ich 14.3 -> 14.4.
Also eine Version, die mit .0 endet, würde ich auch erst einmal vermeiden zu installieren und eher den derzeitigen Kernel auf eine neuere Version, die nicht auch mit .0 endet, hochziehen.
Dennoch habe ich noch mal meine lokale KI befragt, deren Sprachmodell vor ca. 9 Stunden das letzte Mal aktualisiert / trainiert wurde. Und deren Hinweis auf die Ursache sieht heute wie folgt aus:
Das ist ein klassischer UFS/Softdep-Korruptionscrash unter FreeBSD. Der Backtrace zeigt:
#3 softdep_disk_io_initiation+0x12ae
#4 ffs_geom_strategy+0x13b
...
#9 ffs_fsync+0x22FreeBSD versucht, UFS-Metadaten auf die Platte zu schreiben (via ffs_fsync → softdep), und trifft dabei auf einen ungültigen Eintrag mit dem Typ jnewblk, der im Softdep-Log nicht erwartet wird.
| Ursache | Beschreibung |
|---|---|
| Disk-Fehler / Bad Blocks | Defekte Sektoren korrumppieren Metadaten oder den Softdep-Journal |
| Zu wenig RAM | Softdep benötigt viel Arbeitsspeicher — bei zu wenig wird der Cache korruptiert |
| Host-Storage-Probleme | Bei VMs: falsch konfigurierte VirtIO/SCSI, unzuverlässiger Host-Speicher |
| Bug in FreeBSD 14.4p2 | Möglicher Softdep-Bug in dieser Release |
1. Sofort: Metadumps holen, bevor sie verloren gehen:
# Wenn das System wieder hochfährt und die Partition lesbar ist:
disklabel ad0s1 > /var/tmp/disklabel.txt 2>/dev/null || true
dumpfs -u /dev/ad0s1a > /var/tmp/dumpfs_a.txt 2>/dev/null || true
dumpfs -u /dev/ad0s1b > /var/tmp/dumpfs_b.txt 2>/dev/null || true
# ... für alle Partitionen2. RAM-Tests: Memtest86+ laufen lassen — Softdep-Crash sind häufig ein Symptom von Speicherfehlern.
3. VM-Storage prüfen:
4. Dateisystem prüfen:
# Einmalig und mit -y für automatische Reparatur:
fsck_ufs /dev/ad0s1a5. Falls es sich wiederholt: Auf FreeBSD 14.3 zurückgehen oder ein Upgrade auf 15.x in Betracht ziehen (Softdep wurde dort teilweise überarbeitet).
Am wahrscheinlichsten ist entweder ein defekter Speicherlaufwerk im Host/VM, RAM-Defekt oder Storage-Latenz der VM-Disks. Starte mit Memtest und fsck.
Die Frage "Würde ein Upgrade von der derzeitigen Version auf 15.0 das Problem lösen?" wurde wie folgt beantwortet:
Ja, ein Upgrade auf FreeBSD 15.0 hat gute Chancen, das Problem zu lösen — aber mit wichtigen Einschränkungen.
In FreeBSD 14.x wurde der Softdep-Mechanismus mehrfach mit Bugs gelandet. In 15.0 gab es folgende relevante Änderungen:
Der Softdep-Crash mit jnewblk hat sehr oft eine unterliegende Hardwareursache:
| Typ | Lösung durch 15.0? |
|---|---|
| Defekte Platte / Host-Storage | ❌ Nein — Problem bleibt |
| RAM-Bugs im System/Host | ❌ Nein |
| VirtIO-Gast-Treiber Bug | ⚠️ Möglicherweise (neuer Treiber) |
| Softdep-Race Condition | ✅ Wahrscheinlich gelöst |
Upgrade auf 15.0, aber mit Vorsicht:
freebsd-update upgrade -r 15.0-RELEASE
# ... nach Installation
freebsd-update install
# ... Neustart und nochmal
freebsd-update installEin Upgrade auf 15.0 löst es in ~60-80% der Fälle, wenn die Ursache ein reiner Softwarebug war. Bei Storage-/RAM-Problemen bleibt der Crash gleich — nur unter Umständen mit einer anderen Fehlermeldung. Prüfe also zuerst die Hardware, dann upgrade.
Nein, woran denkst Du?
Es gibt im SCP unter dem Menüpunkt "Medien" auch eine Unterfunktion "Speicher optimieren", die sich auch auf dem Host auswirkt und dazu führen kann, dass das Hostsystem erkennt, dass es für deine VM die Quota anpassen muß und somit deiner VM wieder mehr Festplattenspeicher freigibt.
also
- Single-User Boot via VNC und FreeBSD Boot-Menü
- fsck wiederholt bis "clean"
- reboot in reguläre Sitzung
- 2GB File erzeugt per dd -> Crash
auch mit den sysctl.conf und rc.conf Halluzinationen der Homunculi.
Hast du schon eine Speicheroptimierung durchgeführt?