Optimizarea hardware-ului și a resurselor
Scurt rezumat
Optimizarea nu înseamnă „accelerarea unui lucru”, ci echilibrarea performanței ↔ costurilor ↔ fiabilității ↔ energiei. Pași de bază: Măsurați SLI/SLO și profilurile, găsiți blocaje, capacități de „dimensiune corespunzătoare”, automatizați scalarea și îmbunătățiți ancora în imagini/diagrame/politici.
Obiective și principii
De la UX la hardware: pornind de la SLO (latență p95, succesul operațiunilor) → în căutarea unei resurse limitatoare.
Rightsizing: resurse și tipuri de instanțe pentru natura încărcăturii.
Numerar și proximitate: reduceți călătoriile „scumpe” la stocare și rețele.
Automatizare: autoscaling, politici de ciclu de viață, IaC.
Observabilitate: măsurători cu patru semnale, profile CPU/allocare, trasare.
Securitate = performanță: mTLS/semnături/limite - hardware accelerat acolo unde este posibil.
Procesor și programare
Sarcini: minimizați ratările conținutului și memoriei cache, luați în considerare NUMA și întrerupeți.
Conștientizarea NUMA: fixarea prin noduri ('numactl --cpunodebind --membind'), pentru baze de date/brokeri - fixați pe nod.
IRQ/softirq: distribuiți pe nuclee (RSS/RPS), asigurați cozi la cald pentru CPU fără a concura cu lucrătorii.
Hiperflow: pentru „latență sensibilă” - fixați lucrătorii pe miezuri fizice.
Comutatoare de context: reduceți prin cozi lungi/butchings/asynchron.
Compilatoare/JIT: includ PGO/LTO (C/C + +), profile Graal/HotSpot (Java), „GOMAXPROCS”, și alocarea lucrătorilor (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
Gestionarea memoriei și a alocării
THP/HugePages: pentru JVM/DB - dezactivați de obicei THP și utilizați manual hugepages (reduce ratările TLB).
Echilibrul NUMA: pentru starea - comite memorie la nodul local.
- JVM: G1/ZGC, '-Xms = -Xmx' egal, rezonabil 'MaxGCPauseMillis'.
- Go: „GOGC” (începeți cu 100-200), evitați alocările inutile, profilurile „pprof”.
- Python: utilizați „uvloop”, „asyncio”, C-extensii, piscină de conexiune.
- Swap/zswap: la vânzare, de obicei, swap off pentru servicii critice; pe noduri de uz general - zswap pentru sarcini „moi”.
Stocare și I/O
Tipuri de discuri: NVMe pentru hot-path, piscine separate pentru busteni/puncte de control/tempo.
FS: XFS pentru fișiere mari/jurnale DB; ext4 pentru mici/versatile.
RAID/CE: RAID10 pentru latență scăzută, RAID6/EC pentru date reci.
Programatori I/O: „none ”/„ mq-deadline” pentru NVMe.
Async/Lot: înregistrări de grup, utilizați Write-Behind/Group-Commit.
bash fio --name=randread --filename=/data/test --size=20G --bs=4k \
--iodepth=64 --rw=randread --ioengine=libaio --numjobs=4 --time_based --runtime=60
Rețea
MTU și offload: 9000 MTU în centrul de date (dacă end-to-end), activați GRO/LRO acolo unde este permis.
RSS/RPS/RFS: cozi multicanal pe CNI, distribuție pe nuclee; irqbalance - sub control.
SO_REUSEPORT: prize de ascultare scalabile distribuite în nuclee.
Timeouts client și pullings: scurt TCP keepalive, limita de conexiuni deschise, backpressure.
TLS: TLS 1. 3, instrucțiuni hardware AES-NI, reluarea sesiunii, capsare OCSP.
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 (dacă este cazul)
GPU: inferență antifraudă, recomandări, CV; monitor „util”, „mem”, „sm _ efficiency”.
SmartNIC/eBPF/DPDK: descărcare L4/L7, filtrare, telemetrie fără tranziții la nucleu.
Profile energetice: fixați frecvențele pentru o latență stabilă; evita agresiv putere-economisi.
Aplicații și RDBMS
Piscine de conexiune: limita 'max _ conns', se aplică conexiune pooling (PgBouncer/Hikari).
Indici/programatori: EXPLICA/ANALIZA profiluri care acoperă indexuri, partiționare.
Caching: memorie cache Redis/în proces, CDN pentru statici, memorie cache pentru API-uri fierbinți.
Idempotența și cozile: evitați cascadele de retrageri, porniți dedup.
Gzip/Brotli: comprimarea răspunsurilor ținând cont de costul procesorului; alege echilibrul.
Containere și Kubernetes
Cereri/Limite и ambalare
Cereri = "garanție", Limite = "plafon. "Limite incorecte prin CPU → accelerarea și p99.
Luați în considerare sarcinile de spargere (vârfuri de turneu/meci) - marja în p95.
Bin-ambalare: piscine gazdă separate (latență-crit, lot, GPU, la fața locului). Utilizați topologia (anti-afinitate, răspândire).
Autoscaling
HPA prin valori personalizate (RPS/p95, nu CPU).
VPA pentru lucrătorii „de lungă durată” și „în afara vârfului”.
Cluster Autoscaler + grupuri individuale de noduri (la cerere/la fața locului).
KEDA pentru încărcături de evenimente (cozi, Kafka, cron).
Programator și manageri
Manager CPU: „static” pentru fixarea miezurilor complete la fluxurile critice de latență.
Topologie Manager NUMA aliniere.
Plugin-uri HugePages/Device: pentru DB/latență scăzută și 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 și costul
Profiluri tarifare: selectați instanțe după procesor/RAM/disc/rețea (optimizat pentru calcul, optimizat pentru memorie, optimizat pentru stocare).
Spot/Preventibil: pentru lot/staging/cache cu redundanță multi-zone.
Rezervare/Economii: rezerve pentru 1-3 ani pentru partea „permanentă”.
Fierbinte/rece: depozitare pe niveluri, obiect de arhivă, retenție jurnal.
Resurse inactive: opriri de noapte/weekend ale mediilor non-critice.
Eficiență energetică (GreenOps)
Profile de putere: performanță vs echilibrat de serviciu.
Co-locație: compactare în timpul orelor reci, oprirea nodurilor neutilizate.
KPI: watt pe cerere, p95/watt, CO₂ - furnizor de măsurători.
Observabilitate și testare
Метрики: CPU fura/accelerație, 'cicluri/instrucțiuni', LLC dor, RSS/set de lucru, defecte de pagină, disc lat p95/99, picături NIC, retransmise.
Urmărire: trasee distribuite pentru „căi de aur”.
Profilare: eBPF/Perf/Flamegraphs, 'pprof '/YourKit/JFR.
Teste de încărcare: orientate spre SLO, cu un amestec real de operații, o fază de „încălzire”, injecție de defecțiuni.
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)
Lista de verificare a optimizării
- SLO-urile și căile de aur (API-uri/plăți/plăți) sunt definite.
- CPU/allocare/IO/profile de rețea colectate, blocaje de top-N găsite.
- NUMA/IRQ/RSS sunt configurate pe noduri critice de latență.
- THP off (dacă este necesar), hugepages pentru servicii DB/Java.
- NVMe pentru date fierbinți, XFS/IO-sched configurat, fio-banc confirmat.
- Stiva de rețea: MTU, RPS/RFS, SO_REUSEPORT; pauze/piscine.
- Kubernetes: Cereri corecte, Limitele nu înăbușă, HPA de metrici de afaceri, VPA/CA inclus.
- Caching și CDN pe căi „scumpe”; Redis/memorie cache.
- FinOps: rightsizing/reserves/spot pools; oprirea mediilor inactive.
- Autotesturi de performanță în CI, regresii pe p95/p99.
iGaming/fintech specific
Vârfuri programate: turnee/meciuri/promoții → bazin „elastic” de fronturi, pre-încălzirea caches/CDN, HPA de RPS/latență.
Plăți și plăți: IP/domenii individuale „aur”, cozi prioritare, izolarea resurselor (cauciucuri/toleranțe), rezervă de bază.
Antibot/antifraudă: modele grele - pe lucrătorii GPU; punctaj online ≤ 50 ms p95; cache de caracteristici.
Reglementare: jurnalele neschimbabile și criptarea nu ar trebui să rupă SLO - porniți accelerațiile hardware și conductele asincrone.
Mini playbook-uri
↑ latență după eliberare:1. Verificați SLO burn-rate; 2) profiluri „cpu/allocare”; 3) rollback/feature flag; 4) creșterea cache-ului replica/API; 5) RCA și fixarea testului.
Sarcina maximă (meci/turneu):1. Încălziți CDN/cache; 2) ridicare minReplici; 3) includ limitele de spargere; 4) cozi post; 5) activați modul read-only pentru funcțiile secundare.
Greșeli comune
Limitează procesorul „sufocă” volumul de lucru de vârf → p99 ridicat.
Nod pool nevalid: se amestecă latență critică și lot.
Absența setărilor NUMA/IRQ pe baze de date/brokeri.
„Tratarea simptomelor” (adăugarea CPU) în loc de fixare algoritmi/cache/SQL.
HPA de CPU în loc de RPS/latență → scalează târziu.
Nu există teste de performanță în CI → regresie în prod.
Total
Optimizarea este o activitate sistematică: măsurarea SLI/SLO, profil, fixarea algoritmilor, reglarea hardware-ului (NUMA/IRQ/IO/rețea), „dimensiunea” resurselor în mod corect și automatizarea scalării. Capturați îmbunătățiri în șabloane (imagini, diagrame, politică), costuri de control și energie - iar platforma dvs. va rămâne rapidă, economică și durabilă chiar și la vârfuri extreme.