Hochfrequente Datenverarbeitung auf dedizierten Servern

Hochfrequente Datenverarbeitung hat eine präzise Definition: Systeme, die Datenströme mit einer Geschwindigkeit erfassen, verarbeiten und darauf reagieren müssen, die die Kapazität einer typischen Webhosting-Infrastruktur übersteigt. Finanzmarkt-Datenfeeds mit 100.000 Aktualisierungen pro Sekunde, industrielle Sensornetzwerke, die gleichzeitig Telemetriedaten von Tausenden von Geräten übertragen, Echtzeit-Aggregationspipelines, die Millionen von Ereignissen pro Minute zu abfragbaren Zusammenfassungen reduzieren müssen – diese Workloads erfordern dedizierte Bare-Metal-Hardware aus Gründen, die über die reine CPU-Kapazität hinausgehen.

Warum Bare Metal für hochfrequente Workloads wichtig ist

Virtualisierte Infrastruktur führt an den ungünstigsten Stellen einer Hochfrequenz-Verarbeitungspipeline zu nicht deterministischer Latenz. Der Scheduler des Hypervisors legt fest, wann die virtuellen CPUs der VM ausgeführt werden. Unter Last kommt es bei einer VM, die mit anderen Mandanten um physische CPU-Zeit konkurriert, zu Scheduling-Verzögerungen von 1–10 ms. Für Webanwendungen sind 5 ms Scheduling-Jitter nicht wahrnehmbar. Für einen Finanzdaten-Feed-Prozessor, der innerhalb von weniger als 1 ms auf Marktereignisse reagieren muss, sind 5 ms Scheduling-Jitter ein Ausschlusskriterium.

Bei Bare-Metal-Dedizierten Servern entfällt die Hypervisor-Ebene vollständig. Deine Prozesse laufen direkt auf der physischen CPU, ohne dass ein Scheduler dazwischenkommt. In Kombination mit den Echtzeit-Kernel-Optionen von Linux, CPU-Affinity-Pinning und NUMA-bewusster Speicherzuweisung können dedizierte Server bei hochfrequenten Workloads eine Verarbeitungslatenz von unter einer Millisekunde erreichen – etwas, das virtualisierte Infrastrukturen nicht zuverlässig leisten können.

In der Dokumentation zur EPYC-Prozessorarchitektur von AMD wird darauf hingewiesen, dass das Chiplet-Design des 4545P eine einheitliche Speicherzugriffslatenz über alle Kerne hinweg bietet – was für NUMA-sensitive, hochfrequente Workloads relevant ist, bei denen Speicherzugriffsmuster die Verarbeitungszeit maßgeblich beeinflussen können.

Anwendungsfall 1: Finanzmarkt-Datenfeeds

Finanzdatenanbieter (Bloomberg, Refinitiv, CME Group) veröffentlichen Marktdaten in einer Geschwindigkeit, die eine spezielle Verarbeitungsinfrastruktur erfordert. Ein Aktien-Feed kann während der aktiven Handelszeiten 50.000 bis 500.000 Aktualisierungen pro Sekunde für Tausende von Instrumenten liefern.

Verarbeitungsanforderungen:

• Netzwerkstack mit geringer Latenz: Kernel-Bypass-Netzwerkfunktionen (DPDK, RDMA) eliminieren den Overhead des TCP-Stacks bei den latenzempfindlichsten Implementierungen; für die meisten Anwendungsfälle unter 1 Million Nachrichten pro Sekunde reicht das Standard-Kernel-Netzwerk aus
• Sperrfreie Datenstrukturen: Herkömmliche, auf Mutexen basierende Warteschlangen führen bei hohen Nachrichtenraten zu Konflikten; sperrfreie Ringpuffer ermöglichen es Produzenten- und Konsumenten-Threads, ohne Blockierungen zu arbeiten
• CPU-Affinität: Den Netzwerk-Empfangsthread und die Verarbeitungs-Threads bestimmten CPU-Kernen zuweisen, um Schwankungen bei der Task-Planung zu vermeiden

Einfache Python-Implementierung einer Nachrichtenwarteschlange mit hohem Durchsatz unter Verwendung von Multiprocessing:

import multiprocessing as mp
from collections import deque
import time
 
class HighFrequencyProcessor:
    def __init__(self, num_workers=8):
        self.queue = mp.Queue(maxsize=100000)
        self.results = mp.Queue()
        self.workers = []
        
        # Pin workers to specific cores for consistent latency
        for i in range(num_workers):
            p = mp.Process(
                target=self._worker,
                args=(self.queue, self.results, i),
                daemon=True
            )
            p.start()
            self.workers.append(p)
    
    def _worker(self, queue, results, worker_id):
        # Set CPU affinity if psutil available
        try:
            import psutil
            psutil.Process().cpu_affinity([worker_id % mp.cpu_count()])
        except ImportError:
            pass
        
        while True:
            try:
                message = queue.get(timeout=0.001)
                result = self._process_message(message)
                results.put(result)
            except Exception:
                continue
    
    def _process_message(self, message):
        # Application-specific processing logic
        return {
            'timestamp': time.time_ns(),
            'symbol': message.get('symbol'),
            'price': message.get('price'),
            'processed': True
        }
    
    def ingest(self, message):
        try:
            self.queue.put_nowait(message)
            return True
        except mp.queues.Full:
            # Queue full - implement backpressure or drop strategy
            return False

import multiprocessing as mp
from collections import deque
import time
 
class HighFrequencyProcessor:
    def __init__(self, num_workers=8):
        self.queue = mp.Queue(maxsize=100000)
        self.results = mp.Queue()
        self.workers = []
        
        # Pin workers to specific cores for consistent latency
        for i in range(num_workers):
            p = mp.Process(
                target=self._worker,
                args=(self.queue, self.results, i),
                daemon=True
            )
            p.start()
            self.workers.append(p)
    
    def _worker(self, queue, results, worker_id):
        # Set CPU affinity if psutil available
        try:
            import psutil
            psutil.Process().cpu_affinity([worker_id % mp.cpu_count()])
        except ImportError:
            pass
        
        while True:
            try:
                message = queue.get(timeout=0.001)
                result = self._process_message(message)
                results.put(result)
            except Exception:
                continue
    
    def _process_message(self, message):
        # Application-specific processing logic
        return {
            'timestamp': time.time_ns(),
            'symbol': message.get('symbol'),
            'price': message.get('price'),
            'processed': True
        }
    
    def ingest(self, message):
        try:
            self.queue.put_nowait(message)
            return True
        except mp.queues.Full:
            # Queue full - implement backpressure or drop strategy
            return False

Für Anwendungen, bei denen es auf Mikrosekunden-Latenz ankommt, Rost ist die Sprache der Wahl unter Linux. Dank ihres Besitzmodells entfallen Garbage-Collection-Pausen, die sonst gerade in den ungünstigsten Momenten zu unvorhersehbaren Latenzspitzen führen würden. Das Ringpuffermuster des LMAX Disruptor bietet eine bewährte sperrfreie Warteschlangenarchitektur, mit Open-Source-Implementierungen in Java (die Referenzimplementierung) und Rust. Los ist eine praktische Alternative für Teams, die einen Durchsatz nahezu in Echtzeit mit einfacheren Parallelitätsprimitiven benötigen; seine goroutine Der Scheduler verarbeitet Tausende von gleichzeitig laufenden Nachrichten-Handlern, ohne dass die manuelle Thread-Verwaltung erforderlich ist, die Python sonst benötigt.

Anwendungsfall 2: Industrielle Sensornetzwerke

IoT-Sensornetzwerke aus Produktionsanlagen, Smart-Grid-Infrastrukturen oder Umweltüberwachungssystemen generieren große Mengen an Telemetriedaten, die in Echtzeit erfasst, validiert und aggregiert werden müssen.

Eine typische industrielle IoT-Implementierung kann beispielsweise 10.000 Sensoren umfassen, die jede Sekunde Messwerte übertragen – das sind 10.000 Nachrichten pro Sekunde, wobei es bei der Erkennung von Anomalien zu Spitzenwerten kommen kann. Die Verarbeitung jeder einzelnen Nachricht umfasst die Normalisierung von Zeitstempeln, die Umrechnung von Einheiten, die Überprüfung des Wertebereichs und die Aggregation in einen Zeitreihenspeicher.

InfluxDB ist die Standard-Zeitreihendatenbank für hochfrequente Sensordaten. Ihr Line-Protokoll-Format ist für Schreibvorgänge mit hohem Durchsatz optimiert:

# Mehrere Datenpunkte in einer einzigen HTTP-Anfrage schreiben (Batch-Schreiben)
curl -i -XPOST 'http://localhost:8086/write?db=sensors&precision=ns' \
  --data-binary '
sensor_data,facility=plant1,device=temp_sensor_001 temperature=72.4,humidity=45.2 1675000000000000000
sensor_data,facility=plant1,device=temp_sensor_002 temperature=71.8,humidity=44.9 1675000000000000001
sensor_data,facility=plant1,device=pressure_001 pressure=14,7,flow_rate=125,3 1675000000000000002'

# Write multiple points in a single HTTP request (batch writes)
curl -i -XPOST 'http://localhost:8086/write?db=sensors&precision=ns' \
  --data-binary '
sensor_data,facility=plant1,device=temp_sensor_001 temperature=72.4,humidity=45.2 1675000000000000000
sensor_data,facility=plant1,device=temp_sensor_002 temperature=71.8,humidity=44.9 1675000000000000001
sensor_data,facility=plant1,device=pressure_001 pressure=14.7,flow_rate=125.3 1675000000000000002'

Batch-Schreibvorgänge schneiden bei hohen Nachrichtenraten deutlich besser ab als einzelne Schreibvorgänge. In der Dokumentation von InfluxDB zur Schreibleistung werden für einen maximalen Durchsatz Batches von 5.000 bis 10.000 Punkten pro Schreibanforderung empfohlen.

Kafka ist in den meisten Produktions-Sensor-Pipelines InfluxDB vorgeschaltet und fungiert als dauerhafter Nachrichtenpuffer, der Spitzen bei der Datenaufnahme auffängt und es mehreren Konsumenten ermöglicht, denselben Datenstrom für unterschiedliche Zwecke zu verarbeiten:

# Erstelle ein Kafka-Topic für Sensordaten mit geeigneter Partitionierung
kafka-topics.sh --create \
  --topic sensor-readings \
  --partitions 32 \          # Eine Partition pro Verarbeitungs-Thread
  --replication-factor 1 \   # Bereitstellung auf einem einzelnen Server
  --bootstrap-server localhost:9092

# Create a Kafka topic for sensor data with appropriate partitioning
kafka-topics.sh --create \
  --topic sensor-readings \
  --partitions 32 \          # One partition per processing thread
  --replication-factor 1 \   # Single-server deployment
  --bootstrap-server localhost:9092

32 Partitionen ermöglichen es 32 parallelen Consumer-Threads, Sensordaten gleichzeitig zu verarbeiten. Auf dem 16-Kern-EPYC-Prozessor des Extreme-Servers (32 Threads) entspricht dies genau der maximalen Parallelität ohne Überbelegung.

Anwendungsfall 3: Echtzeit-Aggregationspipelines

Aggregationspipelines wandeln hochfrequente Ereignisströme in abfragbare Zusammenfassungen um: Seitenaufrufe pro Minute, Transaktionssummen pro Stunde, aktive Nutzersitzungen nach Region. Die Herausforderung besteht darin, diese Aggregationen in Echtzeit zu berechnen, während stündlich Millionen von Rohdatenereignissen eingelesen werden.

Apache Flink und Apache Kafka Streams sind die gängigen Open-Source-Tools für die Streaming-Aggregation in großem Maßstab. Bei Ein-Server-Bereitstellungen auf dedizierter Hardware ist Kafka Streams einfacher zu betreiben (kein separater Cluster erforderlich) und bietet dennoch weitgehend dieselben Aggregationsfunktionen.

Eine Kafka-Streams-Aggregationspipeline in Java:

StreamsBuilder builder = new StreamsBuilder();
 
// Read from input topic
KStream<String, PageViewEvent> pageViews = builder.stream("page-views");
 
// Aggregate into 1-minute tumbling windows
KTable<Windowed<String>, Long> viewCounts = pageViews
    .groupBy((key, value) -> value.getPageId())
    .windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofMinutes(1)))
    .count(Materialized.as("page-view-counts"));
 
// Write aggregated results to output topic
viewCounts.toStream()
    .map((windowedKey, count) -> KeyValue.pair(
        windowedKey.key(),
        new AggregatedCount(windowedKey.window().startTime(), count)
    ))
    .to("page-view-aggregates");

StreamsBuilder builder = new StreamsBuilder();
 
// Read from input topic
KStream<String, PageViewEvent> pageViews = builder.stream("page-views");
 
// Aggregate into 1-minute tumbling windows
KTable<Windowed<String>, Long> viewCounts = pageViews
    .groupBy((key, value) -> value.getPageId())
    .windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofMinutes(1)))
    .count(Materialized.as("page-view-counts"));
 
// Write aggregated results to output topic
viewCounts.toStream()
    .map((windowedKey, count) -> KeyValue.pair(
        windowedKey.key(),
        new AggregatedCount(windowedKey.window().startTime(), count)
    ))
    .to("page-view-aggregates");

Zustandsdaten für Aggregationen mit Zeitfenstern beanspruchen viel Speicherplatz. Eine Pipeline, die rollierende 1-Stunden-Fenster über 100.000 eindeutige Seiten-IDs hinweg verwaltet, benötigt pro Pipeline-Stufe etwa 1 bis 2 GB an Zustandsdaten. Die 192 GB DDR5-RAM des Extreme-Servers bieten genügend Spielraum, um mehrere Aggregationsstufen mit großzügiger Zustandszuweisung ohne Speicherengpässe auszuführen.

Hardware-Optimierung für hochfrequente Workloads unter Linux

Einige Optionen für den Linux-Kernel und die Hardwarekonfiguration sind speziell auf hochfrequente Verarbeitungsaufgaben zugeschnitten.

CPU-Taktfrequenzanpassung: Die Hochgeschwindigkeitsverarbeitung profitiert von konstanten CPU-Taktfrequenzen. Deaktiviere die Taktfrequenzanpassung, um zu verhindern, dass die Kerne zwischen den Bursts mit reduzierter Frequenz laufen:

# Leistungsregler einstellen (immer mit maximaler Frequenz laufen)
for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
    echo performance > $cpu
done
 
# Über cpupower dauerhaft festlegen
cpupower frequency-set -g performance

# Set performance governor (run at maximum frequency always)
for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
    echo performance > $cpu
done
 
# Make persistent via cpupower
cpupower frequency-set -g performance

NUMA-Bewusstsein: Der AMD EPYC 4545P nutzt eine Chiplet-Architektur, bei der die Latenz beim Speicherzugriff davon abhängt, welchem NUMA-Knoten der Speicher zugeordnet ist – im Verhältnis zu dem Kern, der darauf zugreift. Bei latenzempfindlichen Workloads solltest du die Verarbeitungs-Threads an Kerne innerhalb desselben NUMA-Knotens binden, dem auch der Speicher angehört, auf den sie zugreifen:

# NUMA-Topologie prüfen
numactl --hardware
 
# Einen Prozess mit NUMA-Affinität ausführen (an die CPUs und den Speicher von Knoten 0 binden)
numactl --cpunodebind=0 --membind=0 ./your_processor

# Check NUMA topology
numactl --hardware
 
# Run a process with NUMA affinity (bind to node 0 CPUs and memory)
numactl --cpunodebind=0 --membind=0 ./your_processor

Huge Pages: Die standardmäßigen 4-KB-Speicherseiten des Linux-Kernels erfordern bei großen Arbeitsspeichersätzen viele TLB-Einträge. Durch die Aktivierung von 2-MB-Huge-Pages lassen sich TLB-Fehler bei speicherintensiven Verarbeitungsprozessen reduzieren:

# 512 Huge Pages zuweisen (512 × 2 MB = 1 GB)
echo 512 > /proc/sys/vm/nr_hugepages
 
# Beibehaltung über Neustarts hinweg
echo "vm.nr_hugepages = 512" >> /etc/sysctl.conf

# Allocate 512 huge pages (512 x 2MB = 1GB)
echo 512 > /proc/sys/vm/nr_hugepages
 
# Persistent across reboots
echo "vm.nr_hugepages = 512" >> /etc/sysctl.conf

IRQ-Zuordnung: Für eine Netzwerkverarbeitung mit hohem Durchsatz solltest du die Bearbeitung von Netzwerk-Interrupts bestimmten CPU-Kernen zuweisen, um Cache-Thrashing zu vermeiden, das auftritt, wenn Interrupts auf verschiedenen Kernen bearbeitet werden:

# NIC-Interrupts den Kernen 0–3 zuweisen
# Zuerst die Interrupt-Nummern der Netzwerkkarte ermitteln
cat /proc/interrupts | grep eth0
 
# Affinität festlegen (Beispiel: Interrupt 23 auf Kern 0)
echo 1 > /proc/irq/23/smp_affinity

# Pin NIC interrupts to cores 0-3
# First identify NIC interrupt numbers
cat /proc/interrupts | grep eth0
 
# Set affinity (example for interrupt 23 to core 0)
echo 1 > /proc/irq/23/smp_affinity

Speicher für hochfrequente Daten

Hochfrequente Workloads erzeugen oft erhebliche Datenmengen. Ein Finanzdaten-Feed, der 100.000 Aktualisierungen pro Sekunde verarbeitet und jedes Ereignis mit einer Größe von 200 Byte speichert, erzeugt 20 MB pro Sekunde – das sind 1,7 TB pro Tag.

Der Extreme-Server InMotion Hostingverfügt über 2×3,84 TB NVMe , was bei dieser Rate etwa 4 Tage Rohspeicherplatz bietet, bevor eine Archivierung erforderlich wird. Für eine längere Aufbewahrungsdauer solltest du eine mehrstufige Speicherstrategie konfigurieren:

• Hot-Speicher (NVMe): Die letzten 48–72 Stunden an Rohdaten, vollständig abfragbar
• Warm-Speicher (Objektspeicher): 30–90 Tage, komprimiert, abfragbar mit etwas Latenz
• Langzeitarchivierung: Länger als 90 Tage, komprimiert, langsamer Abruf

Das Apache-Parquet-Format bietet eine spaltenorientierte Komprimierung, die Finanz- und Sensor-Zeitreihendaten auf 10 bis 20 % ihrer ursprünglichen Größe reduziert, während sie weiterhin mit Analysetools wie Apache Spark, DuckDB oder ClickHouse abgefragt werden können.

Die dedizierte Infrastruktur InMotion Hostingfür hochfrequente Workloads

Die Kombination aus AMD EPYC 4545P (16 Kerne, 32 Threads), 192 GB DDR5-ECC-RAM, 2×3,84 TBSSD und einer Basisportgeschwindigkeit von 3 Gbit/s (auf 10 Gbit/s aufrüstbar) im Extreme-Server ist speziell auf die Anforderungen der hochfrequenten Datenverarbeitung zugeschnitten: CPU-Parallelität für die gleichzeitige Nachrichtenverarbeitung, Speicherbandbreite für große Zustandsspeicher, NVMe für schnelle Schreibvorgänge und Netzwerkkapazität für die Datenerfassung aus externen Quellen.

Der 3-Gbit/s-Basisport eignet sich besonders für Sensornetzwerke und Finanzdaten-Aggregatoren, bei denen das eingehende Datenvolumen eher konstant als sporadisch ist. Teams, die eher einen garantierten Durchsatz als Kapazität für Spitzenauslastungen benötigen, können die Portgeschwindigkeit in Schritten von 1 Gbit/s erhöhen.

Da es sich um reine Hardware handelt, gibt es keine Schwankungen bei der Hypervisor-Planung – genau das macht dedizierte Server besonders geeignet für latenzempfindliche Rechenaufgaben, die Cloud-VMs nicht zuverlässig bewältigen können. Für Anwendungen, bei denen die Verarbeitungslatenz im Mikrosekunden- statt im Millisekundenbereich liegt, bietet das Angebot an dedizierten Servern von InMotion die Hardware-Grundlage, die hochfrequente Workloads erfordern.