Optimierung von Eisen und Ressourcen
Kurze Zusammenfassung
Bei der Optimierung geht es nicht darum, „eine Sache zu beschleunigen“, sondern Leistung ↔ Kosten ↔ Zuverlässigkeit ↔ Energie auszugleichen. Grundlegende Schritte: SLI/SLO und Profile messen, Engpässe finden, Kapazitäten „richtig messen“, Skalierung automatisieren und Verbesserungen in Images/Charts/Policies verankern.
Ziele und Grundsätze
Von UX zu Hardware: Wir beginnen von SLO (p95 Latency, Operations Success) → suchen nach einer limitierenden Ressource.
Richtige Größe (Rightsizing): Ressourcen und Instanztypen für die Art der Last.
Cache und Nähe: Reduzieren Sie „teure“ Wanderungen zu Tresoren und Netzwerken.
Automatisierung: Autoscaling, Lifecycle Policies, IaC.
Beobachtbarkeit: „vier Signale“ Metriken, CPU/alloc Profile, Tracing.
Sicherheit = Leistung: mTLS/Signaturen/Limits - mit Hardwarebeschleunigung wo möglich.
CPU und Planung
Aufgaben: Minimieren Sie Inhalte und Cache-Fehler, berücksichtigen Sie NUMA und Interrupts.
NUMA-Awareness: pinning nach Knoten ('numactl --cpunodebind --membind'), für DB/Broker - fix nach Knoten.
IRQ/softirq: Verteilen Sie auf Kerne (RSS/RPS), sichern Sie heiße Warteschlangen für die CPU, ohne mit Workern zu konkurrieren.
Hyperthreading: Für „latenzsensible“ ist es, Worker auf physikalische Kerne zu fixieren.
Kontext-Switches: Reduzieren durch lange Warteschlangen/Batchings/Asynchron.
Compiler/JIT: Aktivieren Sie PGO/LTO (C/C + +), Graal/HotSpot-Profile (Java), 'GOMAXPROCS' und Worker-Hervorhebung (Go).
bash
IRQ affinity: bind NIC queue to specific CPU echo 2 >/ proc/irq/XX/smp_affinity # kernel mask
Softirq balance on sysctl -w net network cores. core. netdev_budget=600 sysctl -w net. core. netdev_max_backlog=5000
Speicher und Allokationsverwaltung
THP/HugePages: für JVM/DB - Deaktivieren Sie normalerweise THP und verwenden Sie hugepages manuell (reduziert TLB-Fehler).
NUMA-Balance: für stateful - Speicher auf dem lokalen Knoten fixieren.
- JVM: G1/ZGC, '-Xms = -Xmx' gleich, vernünftig 'MaxGCPauseMillis'.
- Gehen Sie: 'GOGC' (beginnen Sie mit 100-200), vermeiden Sie unnötige Allokation, 'pprof' Profile.
- Python: 'uvloop', 'asyncio', C-Erweiterungen, Verbindungspool verwenden.
- Swap/zswap: Auf dem Markt normalerweise Swap Off für kritische Dienste; auf Allzweckknoten - zswap für „weiche“ Lasten.
Lagerung und I/O
Laufwerkstypen: NVMe unter Hot-Path, separate Pools für Logs/Checkapoints/Tempo.
FS: XFS für große Dateien/DB-Protokolle; ext4 für klein/vielseitig.
RAID/EC: RAID10 für niedrige Latenz, RAID6/EC für kalte Daten.
I/O-Planer: 'none '/' mq-deadline' für NVMe.
Async/Batch: Datensätze gruppieren, Write-Behind/Group-Commit verwenden.
bash fio --name=randread --filename=/data/test --size=20G --bs=4k \
--iodepth=64 --rw=randread --ioengine=libaio --numjobs=4 --time_based --runtime=60
Netzwerk
MTU und Offload: 9000 MTU im Rechenzentrum (bei End-to-End), GRO/LRO dort einschalten, wo es zulässig ist.
RSS/RPS/RFS: Mehrkanal-Warteschlangen auf NICs, Verteilung auf Kerne; irqbalance - unter Kontrolle.
SO_REUSEPORT: Skalierbare Listen-Sockets mit Kernelverteilung.
Client-Timeouts und Pullings: kurze TCP-Keepalive, Begrenzung der offenen Anschlüsse, Backpressure.
TLS: TLS 1. 3, Hardware-Anweisungen AES-NI, Sitzungsrückgewinnung, OCSP Stapeln.
bash sysctl -w net. core. rmem_max=268435456 sysctl -w net. core. wmem_max=268435456 sysctl -w net. ipv4. tcp_rmem="4096 87380 134217728"
sysctl -w net. ipv4. tcp_wmem="4096 65536 134217728"
GPU/FPGA/SmartNIC (falls zutreffend)
GPU: Inference von Anti-Fraud, Empfehlungen, CV; auf "util'," mem "," sm _ efficiency "achten.
SmartNIC/eBPF/DPDK: Entladen von L4/L7, Filtern, Telemetrie ohne Übergänge in den Kernel.
Energieprofile: Frequenzen unter stabiler Latenz fixieren; Vermeiden Sie aggressive Power-Save.
Anwendungen und RSUBDs
Verbindungspools: 'max _ conns' einschränken, Verbindungspooling anwenden (PgBouncer/Hikari).
Indizes/Planer: EXPLAIN/ANALYZE Profile, die Indizes abdecken, Partitionierung.
Caching: Redis/in-Prozess-Cache, CDN für Statik, Edge-Cache für Hot-APIs.
Idempotenz und Warteschlangen: Vermeiden Sie Kaskaden von Retrays, schalten Sie Dedup ein.
Gzip/Brotli: Komprimierung der Antworten unter Berücksichtigung der CPU-Kosten; Wählen Sie das Gleichgewicht.
Container und Kubernetes
Requests/Limits и bin-packing
Requests = „Garantie“, Limits = „Decke“. Falsche CPU-Limits → throttling und p99.
Berücksichtigen Sie Burst-Loads (Turnier-/Match-Peaks) - die Marge in p95.
Bin-packing: Trennen Sie Knotenpools (Latency-Crit, Batch, GPU, Spot). Verwenden Sie die Topologie (anti-affinity, spread).
Automatische Skalierung
HPA nach benutzerdefinierten Metriken (RPS/p95, nicht CPU).
VPA für „langlebige“ und „Off-Peak“ Workloads.
Cluster Autoscaler + einzelne Node-Gruppen (on-demand/spot).
KEDA für Ereignislasten (Warteschlangen, Kafka, cron).
Planer und Manager
CPU Manager: 'static' zum Pinning kompletter Kerne von latenzkritischen Pods.
Topology Manager: Ausrichtung nach NUMA.
HugePages/Device Plugins: für DB/Low Latency und GPU/FPGA.
yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: { name: api-gw }
spec:
scaleTargetRef:
apiVersion: apps/v1 kind: Deployment name: api-gw minReplicas: 6 maxReplicas: 60 metrics:
- type: Pods pods:
metric:
name: http_latency_p95_ms target:
type: AverageValue averageValue: 120
FinOps und Kosten
Tarifprofile: Abgleich der Instanzen über CPU/RAM/Laufwerk/Netzwerk (compute-optimiert, memory-optimiert, storage-optimiert).
Spot/Preemptible: für Batch/Staging/Caches mit Multi-Zone-Redundanz.
Reservation/Einsparungen: Reserven für 1-3 Jahre für den „konstanten“ Teil.
Heiß/kalt: tiered-storage, Objekt für Archive, retention logs.
Idle-Ressourcen: Nacht/Wochenende-Stopps von nicht-kritischen Umgebungen.
Energieeffizienz (GreenOps)
Leistungsprofile: Leistung gegen ausbalancierte Leistungen.
Co-Platzierung: Verdichtung in „kalten“ Stunden, Ausschalten ungenutzter Knoten.
KPI: Watt pro Anfrage, p95/Watt, CO₂-Metriken des Anbieters.
Beobachtbarkeit und Tests
Метрики: CPU steal/throttle, `cycles/instructions`, LLC miss, RSS/working set, page faults, disk lat p95/99, NIC drops, retransmits.
Traising: Verteilte Trails für die „goldenen Wege“.
Profiling: eBPF/Perf/Flamegraphs, 'pprof '/YourKit/JFR.
Belastungstests: SLO-orientiert, mit echtem Operations-Mix, Aufwärmphase, Fault-Injection.
promql
CPU throttling доля sum(rate(container_cpu_cfs_throttled_seconds_total[5m])) by (pod)
/ sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)
Network loss sum (rate (node_net_dropped_total[5m])) by (instance)
Checkliste für die Optimierung
- SLOs und „goldene Pfade“ (APIs/Zahlungen/Auszahlungen) sind definiert.
- CPU/alloc/IO/Netzwerkprofile gesammelt, Top-N Engpässe gefunden.
- NUMA/IRQ/RSS sind auf latenzkritischen Knoten konfiguriert.
- THP off (falls erforderlich), hugepages für DB/Java-Dienste.
- NVMe für heiße Daten, XFS/IO-sched konfiguriert, fio-bench bestätigt.
- Netzwerk-Stack: MTU, RPS/RFS, SO_REUSEPORT; Zeiträume/Pools.
- Kubernetes: Anfragen korrekt, Limits nicht ersticken, HPA nach Geschäftskennzahlen, VPA/CA enthalten.
- Caching und CDN auf „teuren“ Pfaden; Redis/Edge-Cache.
- FinOps: rightsizing/Reserven/Spot-Pools; Stoppen von Idle-Umgebungen.
- Performance Autotests in CI, Regressionen auf p95/p99.
Spezifität für iGaming/Fintech
Planmäßige Spitzen: Turniere/Matches/Aktionen → „elastischer“ Frontpool, Pre-Warming-Caches/CDN, HPA durch RPS/Latenz.
Zahlungen und Auszahlungen: separate „goldene“ IPs/Domains, Prioritätswarteschlangen, Ressourcenisolierung (Taints/Tolerations), Basisreserve.
Anti-Bot/Anti-Fraud: Heavy-Modelle - auf GPU-Worker; Online-Scoring ≤ 50 ms p95; Cache von Daten.
Regulatory: Unveränderliche Protokolle und Verschlüsselung sollten SLO nicht brechen - Hardware-Beschleunigungen und asynchrone Pipelines einschließen.
Mini-Playbooks
Latenz ↑ nach der Veröffentlichung:1. Vergleichen Sie Burn-Rate SLO; 2) "cpu/alloc' Profile; 3) Rollback/Fichlag; 4) Replikate/API-Cache vergrößern; 5) RCA und Testfixierung.
Spitzenlast (Match/Turnier):1. CDN/Cache aufwärmen; 2) heben minReplicas; 3) Burst-Limits aktivieren; 4) Verteilen Sie die Warteschlangen; 5) Aktivieren Sie den Read-Only-Modus für sekundäre Funktionen.
Typische Fehler
CPU-Limits „ersticken“ Spitzenvorkloaden → hohe p99.
Falscher Knotenpool: Mischen Sie Latency-Critical und Batch.
Keine NUMA/IRQ-Einstellungen auf DB/Brokern.
„Symptome behandeln“ (CPU hinzufügen) statt Algorithmen/Caches/SQL zu korrigieren.
HPA auf der CPU anstelle von RPS/Latenz wird → spät verteilt.
Keine Leistungstests in CI → Regression in der Produktion.
Summe
Optimierung ist Systemarbeit: SLI/SLO messen, profilieren, Algorithmen korrigieren, Hardware konfigurieren (NUMA/IRQ/IO/Netzwerk), Ressourcen „richtig dimensionieren“ und Skalierung automatisieren. Sichern Sie Verbesserungen in Vorlagen (Bilder, Charts, Richtlinien), kontrollieren Sie Kosten und Energie - und Ihre Plattform bleibt auch bei extremen Spitzen schnell, wirtschaftlich und nachhaltig.