Posts by Hamsterbacke

Quote from m_ueberall

Es gab gerade Neustarts in der nclabs-Umgebung – Vielleicht ein Notfallupgrade der Hosts? Der Wiener G11 läuft hier ruhig weiter …

Danke für die schnelle Rückmeldung!

Ja hat mir gerade einen kompletten Schrecken eingejagt weil mein Loadbalancer gefühlt bei allem Failure angezeigt hat.

Ich wurde jetzt mittlerweile auch schriftlich per Email über die Ausfälle benachrichtigt.

Wäre wirklich teuer für mich ausgegangen hätte ich das erst noch später bemerkt 😵‍💫

Ist bei jemanden sonst der Root Server G11 down?

Ob sich was daran ändern wird oder nicht ich will letztlich auch nur den Gedankengang dahinter verstehen. Das bereitet einem schon wirklich Kopfzerbrechen.

Halt in aller Ernsthaftigkeit das ist schon echt maximal absurd. Mich würde es auch interessieren wie jeder in dem Augenblick reagiert wenn er liest das die Server stundenbasiert sind und keine 3 Sekunden später rausfindet das die Grundgebühr höher ausfällt als der Server selbst. Häääää

Da hat die stundenbasierte Abrechnung mal absolut gar keine Darseinsberechtigung. Auf welche Zielgruppe zielt das bitte schön ab?

Entweder haben die sich zu viel dabei gedacht oder gar nix.

Sehr gewagt von dir als Laie in einem deutschen Forum nach Hilfe zu fragen.

Mehr als eine öffentliche Hinrichtung kannst du in der typisch deutschen Forenkultur im Normalfall nicht erwarten

Anyways, ein Ratschlag von mir was solche Fragen angeht, zukünftig einfach auf ChatGPT o.Ä. zurück zu greifen. Die sind relativ gut bei genau solchen Problemstellungen und außerdem geben sie dir gute Anhaltspunkte wo du weiter nachforschen / dranschrauben musst. Außerdem wirst du da zügig geholfen und das auch noch passend zu deiner Situation und all das ohne dich bei irgendwem rechtfertigen zu müssen

Fehler

Quote

Netzwerkkonfiguration

Code

networks:  application-network:    aliases:      - mariadb-docker

Dies war unnötig komplex. Ein einfaches networks: - application-network reicht aus.

Falsche Certbot-Volumes:

Code

volumes:  - '/opt/application/server.pem:/etc/nginx/server.pem'  - '/opt/application/server.key:/etc/nginx/server.key@@@WCF_PRE_LINEBREAK@@@

Diese Pfade stimmten nicht mit den Let's Encrypt-Standardpfaden überein.

Fehlende Certbot-Konfiguration:

Code

certbot:  command: certonly --webroot -w /var/www/certbot --force-renewal --email {$mail} -d {domain.tld} --agree-tos

Hier fehlten die konkreten Werte für E-Mail und Domain.

Nginx hatte keinen Zugriff auf Certbot-Volumes:

Code

nginx:  volumes:    - '/opt/application/application-nginx.conf:/etc/nginx/conf.d/application-nginx.conf'

Unklare Service-Abhängigkeiten:

Code

depends_on:  - application@@@WCF_PRE_LINEBREAK@@@links:  - application@@@WCF_PRE_LINEBREAK@@@

links ist veraltet, und depends_on allein stellt keine vollständige Initialisierung sicher.

Display More

Korrigierte docker-compose.yml u. nginx.conf

version: '3.8'
services:
  mariadb:
    image: mariadb:lts
    container_name: docker_mariadb
    environment:
      - MYSQL_DATABASE=application
      - MYSQL_ROOT_PASSWORD=password
      - MYSQL_USER=application
      - MYSQL_PASSWORD=password
    volumes:
      - mariadb_data:/var/lib/mysql
      - ./application.cnf:/etc/mysql/conf.d/application.cnf
    networks:
      - application-network

  application:
    image: application/application:latest
    container_name: docker_application
    depends_on:
      - mariadb
    environment:
      - TZ=Europe/Berlin
    expose:
      - '8080'
      - '8099'
    volumes:
      - ./application.yml:/opt/application/application.yml
    networks:
      - application-network

  nginx:
    image: nginx:stable
    container_name: docker_nginx
    depends_on:
      - application
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
      - ./dhparams.pem:/etc/nginx/dhparams.pem
    networks:
      - application-network
    command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"

  certbot:
    image: certbot/certbot
    volumes:
      - ./certbot/conf:/etc/letsencrypt
      - ./certbot/www:/var/www/certbot
    depends_on:
      - nginx
    command: certonly --webroot -w /var/www/certbot --force-renewal --email your@email.com -d domain.tld --agree-tos

networks:
  application-network:

volumes:
  mariadb_data:

server {
    listen 80;
    server_name domain.tld;
    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }
    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name domain.tld;

    ssl_certificate /etc/letsencrypt/live/domain.tld/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/domain.tld/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

    location / {
        proxy_pass http://application:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Quote

1. Erstelle ein Projektverzeichnis für deine Docker-Umgebung.
2. Platziere die korrigierte docker-compose.yml und nginx.conf in diesem Verzeichnis.
3. Erstelle die Dateien application.yml und application.cnf im selben Verzeichnis. Diese sollten die spezifischen Konfigurationen für deine Anwendung enthalten.
4. Erstelle die Unterverzeichnisse certbot/conf und certbot/www. Diese werden für die Let's Encrypt-Zertifikate benötigt.
5. Generiere eine dhparams.pem-Datei mit folgendem Befehl:
6. Code

   openssl dhparam -out dhparams.pem 2048

7. Ersetze in beiden Dateien (docker-compose.yml und nginx.conf) alle Vorkommen von domain.tld durch deine tatsächliche Domain.
8. Stelle sicher, dass die DNS-Einstellungen für deine Domain korrekt konfiguriert sind und auf den Server zeigen, auf dem du diese Docker-Umgebung einrichtest.
9. Starte die Docker-Container mit:
   Code

   docker-compose up -d@@@WCF_PRE_LINEBREAK@@@@@@WCF_PRE_LINEBREAK@@@

10. Warte einige Minuten, bis die initiale Zertifikatsgenerierung abgeschlossen ist.
11. Starte den Nginx-Container neu, um die neuen Zertifikate zu laden:
    Code

    docker-compose restart nginx@@@WCF_PRE_LINEBREAK@@@

Beachte dabei folgende Punkte:

• Stelle sicher, dass die Dateiberechtigungen korrekt gesetzt sind.
• Konfiguriere deine Firewall so, dass die Ports 80 und 443 erreichbar sind.
• Die Zertifikatserneuerung erfolgt automatisch, aber behalte sie im Auge.
• Sichere regelmäßig das certbot/conf-Verzeichnis.
• Passe bei Bedarf die Rate-Limits und andere Einstellungen in der Nginx-Konfiguration an deine spezifischen Anforderungen an.

Ich hab den Schritt einfach schon mal für dich gemacht. Habs nur kurz überflogen, sah aber auf dem ersten Blick schon richtig aus. Das sollte eine solide Grundlage bilden womit du dein Problem besser eingrenzen kannst oder auf es auf den Grund zu gehen.

Hol dir eine Subscription für irgendein GPT und wenn du noch Fragen hast würde ich Foren oder Communitys empfehlen die sich genau in dem Gebiet spezialisieren.

Vorzugsweise englischsprachige Communitys

Quote from aRaphael

Die Unterschiede sind sichtbar.

Apache-Zugriffe:

pasted-from-clipboard.png

Interessanterweise sind in der map trotzdem einige Zugriffe aus USA und Finnland dargestellt.

Entweder liegt also RIPE (das geoip-shell genutzt wird) bei einigen IP-Subnetzen falsch oder ipinfo.io (Die Seite, die die Karte erstellt hat)

Bei den echten Attacken (festgestellt mit modsecurity) ist der Unterschied noch deutlicher. Da kommt nun kaum noch was an:

pasted-from-clipboard.png

Display More

Ja das wollte ich noch anmerken. Unter Umständen kann es auch sein das vereinzelte - in den meisten Fällen amerikanische - Netzwerke nicht augeschlossen sind, weil die IP Subnetze nicht immer tagesaktuell sind oder anders oder falsch hinterlegt sind.

z.B. europäischer Hosting Anbieter dessen ASN auch für die Server in der USA verwendet werden

Quote from m_ueberall

Ich selbst verwende kein Geoblocking, würde aber zuerst einen Blick auf https://github.com/friendly-bits/geoip-shell werfen.

Kann ich empfehlen

Es lässt sich auch von nftables auf iptables umstellen

Das Installationsskript Wireguard Road Warrior sollte dir dabei helfen Wireguard ohne Probleme handumdrehend aufzusetzen.

https://github.com/Nyr/wireguard-install

Hat sich in den Communitys als Standard etabliert bei der Installation von Wireguard. Probier es mal darüber

Quote from KaKi87

• Does the 2.5 Gbps virtual network card actually amounts to 2.5 Gbps of Internet bandwith ?
  
  • If yes, is it dedicated ?

I'm getting the full 2.5Gbps basically 24/7. No matter what time, whether it be day time or at night.

As long as you stay within your bandwith limit.

Quote from excalibur

Finde interessant das die ARM VPS eine andere Traffic Flatrate Regelung hat.

im Vergleich zu

1000(Mbit/s) / 8(MB/s) / 1000(GB/s) / 1000(TB/s) * (24(h)*60(min)*60(s)) = 10,8TB ?

Wenn ich mich gerade nicht vertue

In Klammern ist immer die Einheit angeben um welche es sich nach der Umrechnung handelt.

Display More

Ja die Rechnung stimmt schon.

125mb x 60s = 7,5GB pro Minute

7,5gb x 60m = 450GB pro Stunde

450gb x 24h = 10,8TB pro Tag

EDIT:

In der Beschreibung steht es echt drin . Hab mal zugeschlagen

Quote from RAD750

Schon wieder Wien, sehr schade.

Beide Server haben die gleiche Produktnummer wie am Tag davor. Wenn du also beim ersten Mal Wien bekommen hast dann wirst du fortan für diese Produktnummer immer Wien bekommen. Das wird sich dann auch nicht mehr ändern.

Quote from nitram

Dachte das war ein Witz bevor ich dann auf den Link gegangen bin

Mir ist vorhin um 21:30 Uhr beim Konfiguieren des Servers irgendwie aufgefallen das die Performance von meinem Server stark angestiegen ist. Das war gefühlt unmittelbar nachdem ich einige Tweaks am Server vorgenommen habe, aber wie dadurch ganze 20% Leistung zustande kamen konnte ich mir nicht erklären.

Wie ihr vielleicht aus meinem bisherigen Post entnehmen könnt, war die Leistung für eine Zeit lang sehr stark eingebrochen und anscheinend durch Miner beeinträchtigt. Über die Tage hat sich die request per second von meiner Applikation bei 1000 eingependelt und heute Nachmittag mit Tendenz zur 1100. Um 21:30 Uhr aus dem nichts waren es dann plötzlich 1400 Anfragen. Etwas später dann 1500. Mittlerweile ist es fast bei 1800 angelangt?!?Screenshot 2024-06-06 at 03.09.46@2x.png

Spiegelt sich dementsprechend im YABS wider:

Basic System Information:
---------------------------------
Uptime     : 0 days, 0 hours, 1 minutes
Processor  : AMD EPYC 9634 84-Core Processor
CPU cores  : 8 @ 2246.622 MHz
AES-NI     : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM        : 15.6 GiB
Swap       : 0.0 KiB
Disk       : 503.8 GiB
Distro     : Ubuntu 24.04 LTS
Kernel     : 6.9.3-x64v3-xanmod1
VM Type    : KVM
IPv4/IPv6  : ✔ Online / ✔ Online

IPv6 Network Information:
---------------------------------
ISP        : netcup GmbH
ASN        : AS197540 netcup GmbH
Host       : NETCUP-GMBH
Location   : Nuremberg, Bavaria (BY)
Country    : Germany

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 293.20 MB/s  (73.3k) | 515.69 MB/s   (8.0k)
Write      | 293.98 MB/s  (73.4k) | 518.40 MB/s   (8.1k)
Total      | 587.19 MB/s (146.7k) | 1.03 GB/s    (16.1k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 492.02 MB/s    (960) | 719.70 MB/s    (702)
Write      | 518.16 MB/s   (1.0k) | 767.63 MB/s    (749)
Total      | 1.01 GB/s     (1.9k) | 1.48 GB/s     (1.4k)

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value
                |
Single Core     | 1880
Multi Core      | 9511

Die Werte werden über Zeit zunehmend besser, aber mal schauen wie lange das so noch anhält. Zwar einerseits schön anzusehen, andererseits auch irgendwie erschreckend zu sehen wie stark die Werte schwanken können, obwohl von dedizierten Ressourcen die Rede ist. Im LowEndTalk hat ein Anbieter selber Tests durchgeführt mit einer "EPYC 7702" (CPU von der vorherigen Generation G9.5) um dieses Phänomen auf den Grund zu gehen:

Quote

As you may know, a lot of people run Geekbench5 and Geekbench6 tests, and some people notice that the score doesn't exactly scale with the amount of cores available in the system. For example, an 8 core system with a CPU that scores 1000 GB5 points in single threaded won't exactly score 8000 points in multi-threaded. This is probably because of a number of reasons, but I suspect that it's due to hyperthreading and all-core CPU clock speeds being lower.

EPYC 7702 Testing (64 cores, 128 threads)

I have an EPYC 7702 for a short period of time, so I thought I would start with this processor in particular. Threads are basically equivalent to what most providers call vCPU cores.

I'll be testing with:

0 threads loaded (0%)

16 threads loaded (12.5%)

32 threads loaded (25%)

48 threads loaded (37.5%)

64 threads loaded (50%)

96 threads loaded (75%)

120 threads loaded

The BIOS was set to default values, and the CPU is theoretically rated for a 200W TDP. In practice, I only saw up to 185W on the CPU.

In each test, a VM will be used to run a stress test using the stress -c command to stress these amount of threads. Then, another VM with 8 threads allocated will be running a Geekbench5 tests to see the changes in results.

It's important to note that this may not be representative of real world results. The benchmarks are purely artificial, and most virtualization solutions typically schedules the VM to certain threads rather than evenly distributing it across all of the cores.

In this case, we are testing with the following configuration:

AMD EPYC 7702 (64c/128t)

GIGABYTE MZ32-AR0 REV 1.0

16 x 64GB 2400 MHz DDR4 ECC RDIMM

4 x 3.84TB NVMe SSD + 2 x 512GB NVMe SSD + 1TB NVMe SSD

40G ConnectX-3 Pro NIC

Test VM:

Host Passthrough (8 vCPU Cores)

16GB DDR4 ECC Memory

60GB NVMe SSD Storage

0 threads loaded

Idle usage is approximately 145W-180W of power on the host node.

Single Core: 1037

Multi Core: 7892

16 threads loaded

Upon loading the test VM, the server has a power usage between 290-300W.

Single Core: 1047

Multi Core: 7519

Full Test: https://browser.geekbench.com/v5/cpu/22231694

Most of the cores that were loaded by the stress test seem to be at around 3.2 GHz.

32 threads loaded

Upon loading the test VM, the server has a power usage between 290-300W.

Single Core: 938

Multi Core: 6672

Full Test: https://browser.geekbench.com/v5/cpu/22231637

Most of the cores that were loaded by the stress test seem to be at around 3.05 GHz.

48 threads loaded

Upon loading the test VM, the server has a power usage around 300-305W.

Single Core: 860

Multi Core: 5606

Full Test: https://browser.geekbench.com/v5/cpu/22231663

Most of the cores that were loaded by the stress test seem to be at around 2.71 GHz.

64 threads loaded

Upon loading the test VM, the server has a power usage around 310W.

Single Core: 550

Multi Core: 4082

Full Test: https://browser.geekbench.com/v5/cpu/22231650

Most of the cores that were loaded by the stress test seem to be at around 2.45 GHz.

96 threads loaded

Upon loading the test VM, the server has a power usage around 315-320W.

Single Core: 544

Multi Core: 4139

Full Test: https://browser.geekbench.com/v5/cpu/22231672

Most of the cores that were loaded by the stress test seem to be at around 2.43 GHz.

120 threads loaded

Upon loading the test VM, the server has a power usage around 315-320W.

Single Core: 536

Multi Core: 3639

Full Test: https://browser.geekbench.com/v5/cpu/22231683

Most of the cores that were loaded by the stress test seem to be at around 2.39 GHz.

Conclusion

As you can see from the testing above, at the half way point where 50% of the CPU is utilized, we can see a 50% reduction in the CPU single core and multi core values in the 8 core VM running GB5 tests. Despite almost 50% of the CPU being free and 64 threads (64 vCPU cores) literally sitting unutilized, we still see low results. There's a dramatic drop in clock speed to 2.45 GHz, and it seems to stay around there as more cores are loaded, which is probably the culprit behind the lower Geekbench results.

Display More

Ich schätze auf meiner Node ist wohl ein bisschen Platz frei geworden

Danke für die Aufklärung! Ich kenne es tatsächlich auch genau so wie du es beschrieben hattest, aber ich dachte ich frage lieber nochmal nach ob das bei Netcup eventuell irgendwie anders gehandhabt wird und man da potenziell etwas beachten sollte. Ich war eigentlich nur verwirrt weil da "Unverschlüsseltes VLan" stand, da Netzwerke an sich ja unverschlüsselt sind, aber das war mehr eine Gegenüberstellung zur Wireguard.

Quote from H6G

Vorteil:

• MTU 1500
• Verbraucht keinen Traffic
• Zweiter Host benötigt kein Netz
• Einfaches Firewalling
• L2
• Benötigt keine Rechenleistung

Nachteil:

• Unverschlüsseltes VXLAN
• Nur innerhalb eines Standortes möglich

Sorry der Nachfrage aber wie ist das genau gemeint mit "Unverschlüsseltes VXLAN"? Im Vergleich zu Wireguard?

Ich habe VLan bis dato noch nicht wirklich benutzt, aber ich gehe mal davon aus das sonst keiner im gleichen Netzwerk ist außer ich. Könnte abgesehen von Netcup jemand sonst das Netzwerk mitlesen wenn ich zwei Server mithilfe von VLan zusammenschalte?

Vielen Dank im Voraus

RS 2000 G11 Nürnberg

Bevor Neustart

# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
#              Yet-Another-Bench-Script              #
#                     v2024-04-22                    #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Sat Jun  1 09:27:14 AM CEST 2024

Basic System Information:
---------------------------------
Uptime     : 2 days, 11 hours, 54 minutes
Processor  : AMD EPYC 9634 84-Core Processor
CPU cores  : 8 @ 2246.622 MHz
AES-NI     : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM        : 15.6 GiB
Swap       : 0.0 KiB
Disk       : 503.8 GiB
Distro     : Ubuntu 24.04 LTS
Kernel     : 6.8.0-31-generic
VM Type    : KVM
IPv4/IPv6  : ✔ Online / ✔ Online

IPv6 Network Information:
---------------------------------
ISP        : netcup GmbH
ASN        : AS197540 netcup GmbH
Host       : NETCUP-GMBH
Location   : Nuremberg, Bavaria (BY)
Country    : Germany

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 177.47 MB/s  (44.3k) | 358.65 MB/s   (5.6k)
Write      | 177.94 MB/s  (44.4k) | 360.53 MB/s   (5.6k)
Total      | 355.41 MB/s  (88.8k) | 719.18 MB/s  (11.2k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 353.56 MB/s    (690) | 553.61 MB/s    (540)
Write      | 372.34 MB/s    (727) | 590.48 MB/s    (576)
Total      | 725.90 MB/s   (1.4k) | 1.14 GB/s     (1.1k)

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value
                |
Single Core     | 1481
Multi Core      | 7268
Full Test       | https://browser.geekbench.com/v6/cpu/6343434

Nach Neustart über SCP

# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
#              Yet-Another-Bench-Script              #
#                     v2024-04-22                    #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Sat Jun  1 09:56:18 AM CEST 2024

Basic System Information:
---------------------------------
Uptime     : 0 days, 0 hours, 17 minutes
Processor  : AMD EPYC 9634 84-Core Processor
CPU cores  : 8 @ 2246.622 MHz
AES-NI     : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM        : 15.6 GiB
Swap       : 0.0 KiB
Disk       : 503.8 GiB
Distro     : Ubuntu 24.04 LTS
Kernel     : 6.8.0-31-generic
VM Type    : KVM
IPv4/IPv6  : ✔ Online / ✔ Online

IPv6 Network Information:
---------------------------------
ISP        : netcup GmbH
ASN        : AS197540 netcup GmbH
Host       : NETCUP-GMBH
Location   : Nuremberg, Bavaria (BY)
Country    : Germany

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 166.08 MB/s  (41.5k) | 358.03 MB/s   (5.5k)
Write      | 166.52 MB/s  (41.6k) | 359.92 MB/s   (5.6k)
Total      | 332.61 MB/s  (83.1k) | 717.95 MB/s  (11.2k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 348.43 MB/s    (680) | 522.81 MB/s    (510)
Write      | 366.94 MB/s    (716) | 557.63 MB/s    (544)
Total      | 715.38 MB/s   (1.3k) | 1.08 GB/s     (1.0k)

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value
                |
Single Core     | 1526
Multi Core      | 7632
Full Test       | https://browser.geekbench.com/v6/cpu/6343719

Mein vorheriger Stresstest:

Quote

GESTERN

----------------------------------------

Success rate: 100.00%

Total: 30.0040 secs

Slowest: 0.5103 secs

Fastest: 0.0178 secs

Average: 0.0980 secs

Requests/sec: 1021.5973

Total data: 12.50 MiB

Size/request: 429 B

Size/sec: 426.60 KiB

Status code distribution:

[200] 30552 responses

----------------------------------------

HEUTE

----------------------------------------

Success rate: 100.00%

Total: 30.0062 secs

Slowest: 2.2295 secs

Fastest: 0.0239 secs

Average: 0.3306 secs

Requests/sec: 302.7041

Total data: 2.96 MiB

Size/request: 345 B

Size/sec: 100.86 KiB

[200] 8983 responses

----------------------------------------

Display More

JETZT

----------------------------------------

Success rate: 100.00%

Total: 30.0051 secs

Slowest: 0.5791 secs

Fastest: 0.0167 secs

Average: 0.0789 secs

Requests/sec: 1268.5504

Total data: 12.49 MiB

Size/request: 345 B

Size/sec: 426.28 KiB

----------------------------------------

Wild. Es ist jetzt nicht nur besser sondern jetzt auch gleich auf mit der Konkurrenz bei gleicher vCore Anzahl. Es handelt sich hierbei um die günstigste Operation in diesem Kontext. Bei der teureren Operation sieht man ebenfalls eine ordentliche Leistungssteigerung!

DAVOR

----------------------------------------

Success rate: 100.00%

Total: 30.0051 secs

Slowest: 0.8162 secs

Fastest: 0.0500 secs

Average: 0.3394 secs

Requests/sec: 295.1160

Total data: 4.63 MiB

Size/request: 555 B

Size/sec: 158.14 KiB

----------------------------------------

JETZT

----------------------------------------

Success rate: 100.00%

Total: 30.0061 secs

Slowest: 1.1426 secs

Fastest: 0.0332 secs

Average: 0.1765 secs

Requests/sec: 566.9517

Total data: 8.95 MiB

Size/request: 555 B

Size/sec: 305.53 KiB

----------------------------------------

Hier ist es auch fast gleich auf wie bei der Konkurrenz. Wobei aber erwähnt werden muss, dass es am Anfang vom Stresstest mit der Konkurrenz mithalten kann mit 680rps und über Zeit auf unter 480rps fällt. Das ist ein bisschen komisch. Ich werde das mal im Auge behalten.

Alles in allem eine ordentliche Steigerung festzustellen. Ein Lob geht an die Techniker raus

Quote from crowdkinect

Hey Folks General question, The server performance issue is only limited to RS 1000 G11 or RS 2000 G11 are impacted as well. I would really appreciate if someone can give a feedback, i am having a really bad time with some of my woocommerce site which are very slow to the point my customers are considering to move providers.

If RS 2000 is not impacted i will simply upgrade to resolve this issue.

Take a look at my recent yabs benchmark of the RS 2000 G11 Nuremberg here. You may further take a look at all the benchmarks done on Netcup servers here.

So far the entire RS G11 line up seems to be affected. For example the RS 16000 G11 here has a whopping 3493 in multi core performance.

Quote from Falzo

Wie man in anderen Foren lesen kann, findet aktuell wohl ein run speziell auf kleine RS mit 4 'dedizierten' cores statt. Hintergrund scheint zu sein, dass dies die Mindestkonfiguration darstellt, um Quilibrium crypto nodes zu betreiben.

Offenbar gibt es einen täglichen Reward um 0,5€, wenn der node ominöse Mindestanforderungen erfüllt. Somit wird das Ganze zu einem Rechenexempel, bei man theoretisch rund 5-7€ pro Monat verdienen kann mit einem RS 1000.

Netcup gehört zu einer short list an empfohlenen Providern dafür und es gibt offenbar Leute die dann hunderte RS bestellen.

Überflüssig zu erwähnen, dass die Nodes 24/7 auf die CPU hämmern und vermutlich auch nicht wenig IO verursachen. Insofern also kein Wunder, dass netcup ausverkauft ist, bzw. die Performance einbricht, da dieser unerwartete Anstieg in der abgerufenen Performance die Hostcluster entsprechend ans Limit bringt.

Das ein single core geekbench6 von ~1000 Punkte übrigbleibt ist hier vermutlich eher positiv zu sehen ...

Auch dass die ältere Generation weniger betroffen ist wird dann klarer. die kann man einfach nicht mehr kaufen und somit kommt da kein son Mist mehr in die Cluster. Spannend wird, wie lange netcup das mitmacht oder wann jemand auf die Idee kommt, sich das genauer anzusehen und diese use-cases zu verbannen. ist jedenfalls mining related und ja auch nicht das erste Mal das diese schemes aufkommen.

Display More

Das ist die schlüssigste Erklärung bisher und würde weitaus mehr Sinn machen als das Argument mit den Benchmarks. Es wäre sehr besorgniserregend gewesen wenn vereinzelte Benchmarks mehrere Nodes durchgängig in die Knie zwingen würden. Naja, die Benchmarks on top in dieser Situation haben sicherlich auch nicht geholfen

Ich bin mir nicht mehr ganz sicher, aber ich dachte Mining wäre bei Netcup verboten oder war das bei der Konkurrenz? Und ja deinen Namen kenne ich auch vom LowEndTalk

NACHTS

# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
#              Yet-Another-Bench-Script              #
#                     v2024-04-22                    #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Fri May 31 02:00:14 AM CEST 2024

Basic System Information:
---------------------------------
Uptime     : 1 days, 4 hours, 27 minutes
Processor  : AMD EPYC 9634 84-Core Processor
CPU cores  : 8 @ 2246.622 MHz
AES-NI     : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM        : 15.6 GiB
Swap       : 0.0 KiB
Disk       : 503.8 GiB
Distro     : Ubuntu 24.04 LTS
Kernel     : 6.8.0-31-generic
VM Type    : KVM
IPv4/IPv6  : ✔ Online / ✔ Online

IPv6 Network Information:
---------------------------------
ISP        : netcup GmbH
ASN        : AS197540 netcup GmbH
Host       : NETCUP-GMBH
Location   : Nuremberg, Bavaria (BY)
Country    : Germany

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 48.23 MB/s   (12.0k) | 147.10 MB/s   (2.2k)
Write      | 48.29 MB/s   (12.0k) | 147.87 MB/s   (2.3k)
Total      | 96.52 MB/s   (24.1k) | 294.97 MB/s   (4.6k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 174.51 MB/s    (340) | 271.40 MB/s    (265)
Write      | 183.78 MB/s    (358) | 289.48 MB/s    (282)
Total      | 358.30 MB/s    (698) | 560.88 MB/s    (547)

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value
                |
Single Core     | 923
Multi Core      | 2659
Full Test       | https://browser.geekbench.com/v6/cpu/6327919

HEUTE MORGEN

# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
#              Yet-Another-Bench-Script              #
#                     v2024-04-22                    #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #

Fri May 31 09:05:45 AM CEST 2024

Basic System Information:
---------------------------------
Uptime     : 1 days, 11 hours, 32 minutes
Processor  : AMD EPYC 9634 84-Core Processor
CPU cores  : 8 @ 2246.622 MHz
AES-NI     : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM        : 15.6 GiB
Swap       : 0.0 KiB
Disk       : 503.8 GiB
Distro     : Ubuntu 24.04 LTS
Kernel     : 6.8.0-31-generic
VM Type    : KVM
IPv4/IPv6  : ✔ Online / ✔ Online

IPv6 Network Information:
---------------------------------
ISP        : netcup GmbH
ASN        : AS197540 netcup GmbH
Host       : NETCUP-GMBH
Location   : Nuremberg, Bavaria (BY)
Country    : Germany

fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/vda3):
---------------------------------
Block Size | 4k            (IOPS) | 64k           (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 49.46 MB/s   (12.3k) | 208.85 MB/s   (3.2k)
Write      | 49.55 MB/s   (12.3k) | 209.95 MB/s   (3.2k)
Total      | 99.01 MB/s   (24.7k) | 418.80 MB/s   (6.5k)
           |                      |
Block Size | 512k          (IOPS) | 1m            (IOPS)
  ------   | ---            ----  | ----           ----
Read       | 201.52 MB/s    (393) | 292.15 MB/s    (285)
Write      | 212.23 MB/s    (414) | 311.60 MB/s    (304)
Total      | 413.76 MB/s    (807) | 603.75 MB/s    (589)

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value
                |
Single Core     | 920
Multi Core      | 2571
Full Test       | https://browser.geekbench.com/v6/cpu/6330953

Ein Benchmark nachts und in der früh bei der RS 2000 G11. Auch nachts deutscher Zeit wo nicht viel los sein sollte sind die Werte miserabel.

Quote from Schupp

anfangen und am Benchmarken sind, sieht das io halt erstmal nicht so gut aus.

Das scheint echt ein Totschlagargument zu sein hier. Haben vermutlich alle Brückentag gemacht um länger aufzubleiben damit sie die Server zu Tode benchmarken können.

Zumindest sind die Werte jetzt stabil. 8 dedizierte vCores entsprechen hier also

Geekbench 6 Benchmark Test:
---------------------------------
Test            | Value
                |
Single Core     | 920
Multi Core      | 2571
Full Test       | https://browser.geekbench.com/v6/cpu/6330953

Quote from Schupp

Requests/sec: 1021.5973

Ich würde nicht im Traum drauf kommen einem RS2000, geschweige denn einem ETH0 so etwas anzutun (Jedenfalls nicht als normalem Homepage server)

Hä, was ist das für Argument? 😂

Willst du damit andeuten das Netcup Server nur für Spielereien sind oder was?

Es ist keine Homepage sondern eine eigene entwickelte API Server die dann im Verbund zusammenarbeiten sollen jeder mit eigenen Tasks für hohe Redundanz und Höhe Verfügbarkeit. Da mietet man sich nicht den stärksten Server an sondern unterteilt die Aufgaben auf mehrere kleine Server auf.

Netcup wirbt mit 99,9 Prozent Verfügbarkeit, dedizierte Ressourcen und NVMe. Für mein Use Case wäre das optimal würde das stimmen womit Netcup wirbt. Ich könnte die Server auslasten ohne die Nachbarn zu stören.

Das ist ganz normale Prozedere wenn es um horizontale Skalierung geht. Es geht hier also nicht um WordPress oder whatever 😜 was man man auch anhand vom Traffic Verbraucht sehen kann.

Total data: 12.50 MiB

Quote from Schupp

So isses wahrscheinlich, und naja.. ich sehe das dann lockerer weil Preis/Leistung stimmen muss.

Vserver/Rootserver zu benchmarken sehe ich da eher als Nutzlos.

Wie gedenkst du soll man das Preis-Leistungsverhältnis bestimmen wenn man es nicht benchmarked? Es ist doch komplett wayne was der Anbieter auf der Produktseite angibt wie man hier schön daran erkennen kann.

Quote from Schupp

Wenn 100 Freaks ihre neuen Server 3 mal am tag benchmarken ist bestimmt auch nicht so toll für die harmonisierte Verteilung.

Und selbst wenn wieso hat das was der Nachbar auf seinen Server tut einen so großen Einfluss auf die Performance von meinem Server wenn der Anbieter dedizierte Ressourcen verspricht. Das geht so nicht! Wir dürfen sowas doch nicht normalisieren. Die meisten anderen Anbieter haben keine 12 Monate Verträge deshalb haben die Benchmarks durchaus ihre Darseinsberechtigung um zu sehen auf was man sich einlässt.

Bei mir war nun mal nicht nur ein Benchmark sondern ein Stresstest im Real Life Szenario und das kann sich auf jeden fall nicht sehen lassen.