Optimización del hierro y los recursos

Resumen breve

La optimización no es «acelerar algo», sino equilibrar el rendimiento ↔ el costo ↔ la fiabilidad ↔ la energía. Pasos básicos: medir SLI/SLO y perfiles, encontrar cuellos de botella, «dimensionar correctamente» la potencia, automatizar la escala y consolidar las mejoras en imágenes/listas/políticas.

Objetivos y principios

De UX a hierro: partimos de SLO (p95 latencia, éxito de operaciones) → buscamos un recurso limitante.
Tamaño correcto (rightsizing): recursos y tipos de instancias bajo la naturaleza de la carga.
Caché y proximidad: reduzca los viajes «caros» a almacenes y redes.
Automatización: autoscaling, políticas de ciclo de vida, IaC.
Observabilidad: métricas de «cuatro señales», perfiles de CPU/alloc, treising.
Seguridad = rendimiento: mTLS/firmas/límites - con aceleración de hardware siempre que sea posible.

CPU y planificación

Tareas: minimizar el contenido y los errores de caché, tener en cuenta NUMA e interrupciones.

Conciencia NUMA: pinning por nodos ('numactl --cpunodebind --membind'), para BD/brókers - fijar en el nodo.
IRQ/softirq: distribuir por núcleos (RSS/RPS), fijar colas en caliente por CPU sin competir con los workers.
Hiperfinalidad: para los «sensibles a la latencia» es fijar los workers en los núcleos físicos.
Contexto-Sweets: reducir a través de largas colas/batchings/asinchron.
Compiladores/JIT: incluye perfiles PGO/LTO (C/C + +), Graal/HotSpot (Java), 'GOMAXPROCS' y selección de workers (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 y gestión de alocaciones

THP/HugePages: para JVM/DB, normalmente desactiva THP y usa hugepages manualmente (reduce los errores TLB).
Balance NUMA: para stateful - fijar la memoria en el nodo local.

• JVM: G1/ZGC, '-Xms = -Xmx' igual, razonable 'MaxGCPauseMillis'.
• Go: 'GOGC' (empezar con 100-200), evitar alocaciones superfluas, perfiles 'pprof'.
• Python: utilizar 'uvloop', 'asyncio', extensiones C, agrupación de conexiones.
• Swap/zswap: en venta normalmente swap off para servicios críticos; en nodos de propósito general - zswap para cargas «suaves».

Almacenamiento y I/O

Tipos de disco: NVMe en hot-path, grupos separados para logs/checapoints/tempo.
FS: XFS para archivos/registros de BD grandes; ext4 para pequeños/versátiles.
RAID/EC: RAID10 para latencias bajas, RAID6/EC para datos fríos.
Planificadores I/O: 'ninguno '/' mq-deadline' para NVMe.
Async/Batch: agrupe las entradas, use 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

Red

MTU y offload: 9000 MTU en el datacenter (si end-to-end), habilite GRO/LRO donde sea admisible.
RSS/RPS/RFS: colas multicanal en NIC, distribución por núcleo; irqbalance - bajo control.
SO_REUSEPORT: sockets escalables listen con distribución por núcleos.
Timeout y pullings del cliente: TCP-keepalive corto, límite de conexiones abiertas, backpressure.
TLS: TLS 1. 3, instrucciones de hardware AES-NI, resumen de sesión, stapling 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 (cuando proceda)

GPU: infierno antifroda, recomendaciones, CV; seguir 'util', 'amb', 'sm _ efficiency'.
SmartNIC/eBPF/DPDK: descarga de L4/L7, filtrado, telemetría sin transición al núcleo.
Energía: fijar frecuencias bajo latencia estable; evitar el power-save agresivo.

Aplicaciones y RSBD

Grupos de conexiones: restringir 'max _ conns', aplicar pooling de conexión (PgBouncer/Hikari).
Índices/planificadores: perfiles EXPLAIN/ANALYZE que cubren los índices, particiones.
Almacenamiento en caché: proceso de caché Redis/in, CDN para estática, caché edge para API 'hot'.
Idempotencia y colas: evita las cascadas de retraídas, enciende el dedup.
Gzip/Brotli: compresión de respuestas con costo de CPU; elija el equilibrio.

Contenedores y Kubernetes

Requests/Limits и bin-packing

Requests = «garantía», Límites = «techo». Límites incorrectos por CPU → throttling y p99.
Tenga en cuenta las cargas de burst (picos de torneos/partidos) - stock en p95.
Bin-packing: divide los grupos de nodos (latency-crit, batch, GPU, spot). Utilice topología (anti-affinity, spread).

HPA por métricas personalizadas (RPS/p95, no CPU).
VPA para los worcloads «de larga vida» y «no-pique».
Cluster Autoscaler + grupos node individuales (on-demand/spot).
KEDA para cargas de eventos (colas, Kafka, cron).

Planificador y administradores

Administrador de CPU: 'static' para pintar núcleos completos de podas críticas latency.
Topology Manager: alineación NUMA.
HugePages/Device Plugins: para BD/baja latencia y 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 y costo

Perfiles de tarifas: recoger instancias por CPU/RAM/disco/red (ordenador-optimizado, memoria-optimizado, almacenamiento-optimizado).
Spot/Preemptible: para batch/staging/caches con redundancia multisona.
Reserva/Ahorro: reservas para 1-3 años para la parte «permanente».
Caliente/frío: tiered-storage, objeto para archivos, retoque de registros.
Recursos Idle: paradas nocturnas/de fin de semana de entornos no críticos.

Eficiencia energética (GreenOps)

Power profiles: performance vs balanced por servicios.
Co-colocación: sellado en relojes «fríos», apagado de nudos sin usar.
KPI: vatio a petición, p95/vatio, CO₂-métricas del proveedor.

Observabilidad y pruebas

Метрики: CPU steal/throttle, `cycles/instructions`, LLC miss, RSS/working set, page faults, disk lat p95/99, NIC drops, retransmits.
Senderismo: Tracks distribuidos para «rutas doradas».
Perfil: eBPF/Perf/Flamegraphs, 'pprof '/YourKit/JFR.
Pruebas de carga: orientadas a SLO, con operaciones mix reales, fase de «calentamiento», inyección 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)

Lista de verificación de optimización

• SLO y «rutas de oro» (API/pagos/pagos) están definidos.
• Los perfiles de CPU/alloc/IO/red se recogen, encontrándose cuellos de botella Top-N.
• NUMA/IRQ/RSS están configurados en nodos críticos latency.
• THP off (si es necesario), hugepages para servicios de BD/Java.
• NVMe bajo datos calientes, XFS/IO-sched configurado, fio-bench confirmado.
• Pila de red: MTU, RPS/RFS, SO_REUSEPORT; Timeout/pools.
• Kubernetes: Las solicitudes son correctas, Limits no estrangulan, HPA por métricas de negocio, VPA/CA incluido.
• Almacenamiento en caché y CDN en caminos «caros»; Redis/edge-caché.
• FinOps: rightsizing/reservas/spot-pools; Detener los alrededores idle.
• Autotestas de rendimiento en CI, regresión en p95/p99.

Características específicas para iGaming/Fintech

Picos programados: torneos/partidos/promociones → grupo de frentes «elásticos», cash pre-calentamiento/CDN, HPA por RPS/latencia.
Pagos y desembolsos: IP/dominios de oro individuales, colas prioritarias, aislamiento de recursos (taints/tolerations), reserva por base.
Antibot/antifraude: modelos heavy - en workers GPU; puntuación en línea ≤ 50 ms p95; caché de fichas.
Regulación: los registros inmutables y la encriptación no deben romper el SLO: incluya aceleraciones de hardware y pipelines asíncronos.

Minibuses

1. Conciliar SLO burn-rate; 2) perfiles 'cpu/alloc'; 3) retroceso/fichflag; 4) aumentar las réplicas/caché API; 5) RCA y fijación de la prueba.

1. Calentar CDN/caché; 2) elevar minReplicas; 3) incluir los límites de burst; 4) separar las colas; 5) habilite el modo read-only para funciones menores.

Errores típicos

Los límites de la CPU «asfixian» los puestos de trabajo máximos → p99 altos.
Grupo de nodos incorrecto: mezclar latency-crítico y batch.
No hay ajustes NUMA/IRQ en el DAB/brókers.
«Tratamos los síntomas» (agregamos CPU) en lugar de corregir algoritmos/caché/SQL.
HPA por CPU en lugar de por RPS/latencia → se patinará tarde.
No hay pruebas de rendimiento en CI → regresión en la venta.

Resultado

La optimización es el trabajo del sistema: medir SLI/SLO, perfilar, corregir algoritmos, ajustar el hierro (NUMA/IRQ/IO/red), «dimensionar correctamente» los recursos y automatizar la escala. Consolide las mejoras en las plantillas (imágenes, listas, políticas), controle el costo y la energía, y su plataforma seguirá siendo rápida, económica y sostenible incluso en picos extremos.