Danke für den Hinweis auf Navidrome, ich hatte mal Jellyfin auf's heimische NUC geworfen - das hat aber diverse Mediathek-Inhalte sehr merkwürdig sortiert: Feuer und Flamme vom WDR ist offenbar eine Anime-Serie. 
Beiträge von bjo
-
-
Ein Piko als Podman-Host für paar kleine Webanwendungen, beispielsweise Elk als Mastodon-Client.
-
RS1000 G11 - das ist nicht wirklich besser als bei der G9:
Code
Alles anzeigenfio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sda3): --------------------------------- Block Size | 4k (IOPS) | 64k (IOPS) ------ | --- ---- | ---- ---- Read | 171.18 MB/s (42.7k) | 320.11 MB/s (5.0k) Write | 171.63 MB/s (42.9k) | 321.80 MB/s (5.0k) Total | 342.81 MB/s (85.7k) | 641.91 MB/s (10.0k) | | Block Size | 512k (IOPS) | 1m (IOPS) ------ | --- ---- | ---- ---- Read | 373.94 MB/s (730) | 487.87 MB/s (476) Write | 393.81 MB/s (769) | 520.36 MB/s (508) Total | 767.76 MB/s (1.4k) | 1.00 GB/s (984) -
Mal einen näheren Speedtest-Server in Frankfurt oder beim Roten H probiert? Vielleicht ist zu manchen Zeiten auch der Downstream von Wilhelm-Tel dicht.
-
Especially if you are a new customer. I think the activation is faster when customers who have already a product order more products.
-
Das kommt davon, wenn man sich weigert, ANX84 in BUD01 umzubenennen!
Die Pings nach Budapest sind ja auch schlechter!
-
Heute Vormittag Routingprobleme zwischen l0**S und der Open-Telekom-Cloud, die Fritzbox meiner Oma ist seit 10 Uhr offline (2&2), meine Tante schreibt mir, dass Geldautomaten der VR-Bank in ihrem Dorf ausgefallen sind und jetzt das hier. Ich möchte jetzt keine Verschwörungstheorien lostreten, aber eigentlich schon.
Was lernen wir daraus? Marcel Davis ist immer Schuld!
-
Zitat
Der Client hängt an einem Telekom DSL (500Mbit Download, 100Mbit Upload).
Was soll das denn sein? Dachte DSL kann max 250/40.
-
Und: Tritt es im Rettungssystem auch auf?
-
Zu den Servern die ihre Anbindung verlieren gab es hier ja auch schon einige Threads.
-
OMG, Du lebst meinen Traum!
Ansich ist das schon sehr angenehm, vor allem weil man Speicherkisten quasi mal als NAS einbinden kann oder dergleichen. Zugleich möchte man aber auch zuhause nichts kritisches hosten, wenn im NUC nur eine SSD ist und man im Grunde alles wieder aus dem Backup ziehen müsste, wenn diese den Geist aufgibt.
-
Eine defekte Festplatte z.B. fällt denen gar nicht auf.
Das muss man selbst überwachen und beim Ausfall einer Platte muss man sie selbst aus dem RAID nehmen und dem Support Bescheid geben. (Und nicht die falsche Platte angeben
) Der Austausch geht dann aber sehr fix. Ich hatte das (zum Glück) erst einmal und das war innerhalb von Minuten (am Wochenende!) erledigt.Ich meinte bei der Cloud, nicht bei den Dedis. Dass man das bei den Dedis selbst überwachen muss, ist klar.
-
Fairerweise muss man sagen dass der normale Support auch bei *etzner zu ähnlichen Zeiten arbeitet wie bei netcup.
Das betrifft auch den Cloud Support.
Hast du ne Sperrung oder deine Cloudmaschine läuft nicht wartest du also auch auf normale Öffnungszeiten.
Das was ihr hier meint ist die Vor-Ort Besetzung im Rechenzentrum die bei Hardware-Problemen mit den dedicated Servern bereit steht!
Vermutlich fällt denen aber eher kaputte Hardware auf im Vergleich zu hier wo ein Hardwaredefekt zu IO-Last führt oder VMs ihre Konnekivität verlieren und "kein Fehler feststellbar ist", es zufälligerweise dann aber wieder funktioniert.
Da scheinen Mitbewerber transparenter zu sein und es gibt selbst bei einem 2min-Ausfall nachträglich eine Mail.
Ich bin jedenfalls wieder nach Falkenstein gezogen, auch aufgrund der Nähe zur Storagebox (als Nextcloud-Space) und da ich Akkoma und Matrix auch daheim als Single-User-Instanz auch auf dem NUC laufen lassen kann, 1 Gbit symmetrisch FTTH mit statischer IP machts möglich.
-
Hallo bjo,
danke für dein Feedback.
Ich habe es an das zuständige Team weitergegeben und darum gebeten, das zu prüfen. Das genannte Tool hdparm ist (neben anderen nützlichen Tools für Tests dieser Art, wie z.B. fio) bereits standardmäßig im Rettungssystem enthalten. Ich kann den Wunsch nach neueren und aktuellen Versionen, sowie der Möglichkeit, ohne Umwege Pakete zu installieren, aber natürlich gut nachvollziehen.
Wegen eines Durchsatzproblems wurde ich mal vom Support gebeten, iperf3 vom Rettungssystem auszuführen - das ist jedoch nicht im Rettungssystem vorhanden und ließ sich aus og. Gründen auch nicht nachinstallieren.
-
-
-
- Ausgaben von I/O-Speedtests / anderen geeigneten Nachweisen des Problems, falls leicht erstellbar (z.B. wenn das Problem dauerhaft besteht), idealerweise im Rettungssystem erstellt.
Vielleicht wäre es dafür von Vorteil, wenn ihr das Rettungssystem mal aktualisiert. Momentan basiert es auf Debian oldoldoldoldstable, sodass man keinerlei Tools wie bspw. hdparm nachinstallieren kann.
-
resolvconf hat ja auch nichts mit systemd-resolve zu tun.
-
Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:
Meinst du damit, der Storage läuft auf irgendwelchen SAN mit entsprechenden Caching welches dann die Grätsche macht?
-
Auch aus meiner Sicht wird ein Umzug mittlerweile nicht wirklich helfen. Denn schaut man sich folgendes Ergebnis genauer an, so rieht es eher danach aus, als werden mittlerweile aus Kostengründen die virtuellen Platten der virtuellen Server, egal ob VPS oder RS, auf sogenannte "Block Storage Volumes" ausgelagert. Mehr siehe folgendes Meßergebnis, welches ich auf einen RS 4000 G9.5 erstellt habe:
Habe ich gerade auch mal ausgeführt:
Code
Alles anzeigentime fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=test --bs=4k --iodepth=64 --size=8G --readwrite=randrw test: (g=0): rw=randrw, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=64 fio-3.35 Starting 1 process test: Laying out IO file (1 file / 8192MiB) Jobs: 1 (f=1): [m(1)][100.0%][r=7819KiB/s,w=7875KiB/s][r=1954,w=1968 IOPS][eta 00m:00s] test: (groupid=0, jobs=1): err= 0: pid=2910712: Thu Oct 19 20:53:19 2023 read: IOPS=8703, BW=34.0MiB/s (35.7MB/s)(4098MiB/120546msec) bw ( KiB/s): min= 880, max=112432, per=100.00%, avg=34907.31, stdev=13562.80, samples=240 iops : min= 220, max=28108, avg=8726.83, stdev=3390.70, samples=240 write: IOPS=8693, BW=34.0MiB/s (35.6MB/s)(4094MiB/120546msec); 0 zone resets bw ( KiB/s): min= 824, max=109568, per=100.00%, avg=34866.91, stdev=13447.36, samples=240 iops : min= 206, max=27392, avg=8716.73, stdev=3361.84, samples=240 cpu : usr=4.63%, sys=22.98%, ctx=1069407, majf=2, minf=10 IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0% issued rwts: total=1049199,1047953,0,0 short=0,0,0,0 dropped=0,0,0,0 latency : target=0, window=0, percentile=100.00%, depth=64 Run status group 0 (all jobs): READ: bw=34.0MiB/s (35.7MB/s), 34.0MiB/s-34.0MiB/s (35.7MB/s-35.7MB/s), io=4098MiB (4298MB), run=120546-120546msec WRITE: bw=34.0MiB/s (35.6MB/s), 34.0MiB/s-34.0MiB/s (35.6MB/s-35.6MB/s), io=4094MiB (4292MB), run=120546-120546msec Disk stats (read/write): sda: ios=1050099/1050854, merge=0/44, ticks=6735232/905732, in_queue=7641603, util=99.39% fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test 7.14s user 35.24s system 31% cpu 2:12.46 total
