Ottimizzazione di ferro e risorse

Breve riepilogo

Ottimizzare non è accelerare una cosa, ma bilanciare prestazioni, costi, affidabilità e energia. I passaggi principali sono misurare SLI/SLO e profili, trovare colli di bottiglia, ridimensionare la potenza correttamente, automatizzare la scalabilità e fissare i miglioramenti in immagini/liste/regole.

Obiettivi e principi

Da UX a ferro: partiamo da SLO (p95 latency, successo delle operazioni) cercando una risorsa limitante.
Dimensione corretta (rightsizing) - Risorse e tipi di istanze per il tipo di carico.
Cache e intimità: ridurre le escursioni di storage e reti «costose».
Automazione: autoscaling, criteri del ciclo di vita, IaC.
Osservabilità: metriche dei quattro segnali, profili CPU/alloc, trailing.
Sicurezza = prestazioni: mTLS/firma/limiti - con accelerazione hardware quando possibile.

CPU e pianificazione

Attività: ridurre al minimo il contest e la cache, tenere conto di NUMERA e interruzioni.

NUMA-consapevolezza: pinning per nodi ('numactl -cpunodebind --membind'), per database/broker - fissare sul nodo.
IRQ/softirq: distribuisci su core (RSS/RPS), fissa le code hot per CPU senza concorrenza con i worker.
Iperfluenza: per «sensibili alla latitanza», fissare i worker sui nuclei fisici.
Contesto-maglie: riduce attraverso lunghe code/batching/asincron.
Compilatori/JIT - Includi PGO/LTO (C/C + +), profili Java, GOMAXPROCS e selezione worker (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

Memoria e gestione delle allocazioni

THP/HugePages: per JVM/DB - di solito disabilita il THP e usa l'hugepage manualmente (riduce i mancamenti TLB).
Bilanciamento NUMERICO - Per stateful, fissare la memoria sul nodo locale.

• JVM: G1/ZGC, '-Xms = -Xmx', ragionevole '.
• Go: «GOGC» (inizia con 100-200), evitare allocazioni eccessive, profili «pprof».
• Python: usa «uvloop», «asyncio», estensioni C, pool di connessioni.
• Swap/zswap: in vendita solitamente swap off per servizi critici; sui nodi generici - zswap per carichi «morbidi».

Memorizzazione e I/O

Tipi di unità: NVME sotto hot-path, pool separati per logi/checkapoint/ritmo.
FS: XFS per file/registri database di grandi dimensioni ext4 per piccoli/versatili.
RAID/CE: RAID10 per ritardi bassi, RAID6/CE per dati freddi.
Pianificatori I/O: «none »/« mq-deadline» per NVMe.
Async/Batch: raggruppa i record, usa 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

Rete

MTU e offload: 9000 MTU nel datacentro (se end-to-end), abilitare GRO/LRO dove è consentito.
RSS/RPS/RFS: code multicanale per NIC, distribuzione per core; irqbalance - sotto controllo.
SO _ REUSEPORT - listen-socket scalabili con distribuzione nei nuclei.
Timeout client e pulling: corti TCP-keepalive, limite connettori aperti, backpressure.
TLS: TLS 1. 3, istruzioni hardware AES-NI, sessione respumption, OCSP stapling.

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 (se necessario)

GPU: antifrode infernale, raccomandazioni, CV; monitorare «util», «mem», «sm _ efficiency».
SmartNIC/eBPF/DPDK: scarica L4/L7, filtra, telemetria senza passare al nucleo.
Energoprofili: fissa le frequenze in una latitanza stabile; evitare il power-save aggressivo.

Applicazioni e RSUBD

Pool di connessioni: limita 'max _ conns', applica connection pooling (PgBouncer/Hikari).
Indici/pianificatori: profili EXPLORER/ANALYZE che coprono indici, partizionamento.
Cache: Redis/in processo cache, CDN statico, edge cache API hot.
Idampotenza e code: evitate le cascate dei retrai, accendete i devup.
Gzip/Brotli: compressione delle risposte in base al valore CPU; scegli un equilibrio.

Contenitori e Kubernets

Requests/Limits и bin-packing

Richiesti = «garanzia», Limits = «soffitto». Limits non validi per CPU di throttling e p99.
Tieni conto del carico di lavoro burst (picchi tornei/partite) - una scorta di p95.
Bin-packing - Separa i pool di nodi (latency-crit, batch, GPU, spot). Utilizzate la topologia (anti-affinity, spread).

Scalabilità automatica

HPA per metriche di custome (RPS/p95, non CPU).
VPA per i worcload «longevi» e «nepici».
Cluster Autocaler + gruppi node separati (on-demand/spot).
KEDA per carichi di eventi (code, Kafka, cron).

Pianificatore e manager

CPU Manager: «static» per il pinning dei nuclei completi latency-critical spam.
Topology Manager: allineamento NUMERA.
HugePages/Device Plugins: per database/bassa latenza e 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 e costo

I profili tariffari includono le istruzioni CPU/RAM/disco/rete (compute-ottimized, memory-ottimized, storage-ottimized).
Spot/Preemptible: per batch/steading/cache con ridondanza multi-isonica.
Riserva/Savings: riserve di 1-3 anni per la parte «permanente».
Caldo/freddo: tiered-storage, oggetto di archiviazione, retino di logi.
Idle-risorse: notturni/weekend-fermate di ambienti non critici.

Efficienza energetica (GreenOps)

Power profiles: performance vs balanced per servizi.
Co-posizionamento: compattamento in orologi freddi, spegnimento dei nodi inutilizzati.
KPI: watt per richiesta, p95/watt, del provider.

Osservabilità e test

Метрики: CPU steal/throttle, `cycles/instructions`, LLC miss, RSS/working set, page faults, disk lat p95/99, NIC drops, retransmits.
Tracing, roulotte distribuite per le vie d'oro.
Profilassi: eBPF/Perf/Flamegraphs, «pprof »/ YourKit/JFR.
Test di carico: SLO-orientati, con interventi reali mix, fase di riscaldamento, iniezione fault.

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)

Foglio di assegno di ottimizzazione

• Definiti SLO e «vie d'oro» (API/pagamenti/pagamenti).
• I profili CPU/alloc/IO/rete sono stati raccolti e sono stati trovati i colli di bottiglia top-n.
• NUMERA/IRQ/RSS sono configurati su siti critici latency.
• THP off (se necessario), hugepages per i servizi di database/Java.
• NVMe hot data, XFS/IO-sched configurato, fio-bench confermato.
• Stack di rete: MTU, RPS/RFS, SO _ REUSEPORT; timeout/pool.
• Kubernets: I richiesti sono corretti, Limits non soffocati, HPA per metriche aziendali, VPA/CA inclusi.
• Cache e CDN su percorsi «costosi» Redis/edge-cache.
• FinOps: rightsizing/riserve/spot-pool; fermate gli ambienti idle.
• Autostop prestazioni in CI, regressione su p95/p99.

Specifico per iGaming/Fintech

Picchi pianificati: tornei/partite/promozioni, pool di fronti «elastico», pre-riscaldamento cache/CDN, HPA RPS/Latence.
Pagamenti e pagamenti: singoli «oro» IP/domini, code prioritarie, isolamento delle risorse (taints/tolerations), riserva di base.
Antibot/antifrode: modelli heavy - su worker GPU; ≤ on-line 50 ms p95; la cache di fiocchi.
Regolazione: i fogli e la crittografia invariati non devono rompere lo SLO - includere accelerazioni hardware e pipline asincroni.

Mini playbook

1. Incrocia burn-rate SLO; 2) profili «cpu/alloc»; 3) rimborso/ficchflag; 4) Aumentare le repliche/API 5) RCA e fissa il test.

1. Scaldare CDN/cache; 2) sollevare il minReplicas; 3) attivare i limiti burst; 4) Spargere le code; 5) Abilitare la modalità read-only per le funzioni secondarie.

Errori tipici

I limits CPU «soffocano» gli orcloadi di picco del p99.
Pool di nodi non valido: mescolano criticità latency e batch.
Nessuna configurazione NUMERA/IRQ su database/broker.
«Curiamo i sintomi» (aggiungiamo CPU) invece di correggere algoritmi/cache/SQL.
L'HPA CPU invece di RPS/latency screen tardi.
Non ci sono test di regressione a CHI.

Totale

L'ottimizzazione è un lavoro di sistema: misurare SLI/SLO, profilare, correggere algoritmi, regolare il ferro (NUMERA/IRQ/IO/rete), ridimensionare correttamente le risorse e automatizzare la scalabilità. Consolidare i miglioramenti nei modelli (immagini, charts, policy), controllare costi ed energia e mantenere la piattaforma veloce, economica e sostenibile anche in picchi estremi.