Optimization of hardware and resources
Brief Summary
Optimization is not about "accelerating one thing," but balancing performance ↔ cost ↔ reliability ↔ energy. Basic steps: Measure SLI/SLO and profiles, find bottlenecks, "properly dimension" capacities, automate scaling, and anchor improvements in imagery/charts/policies.
Goals and principles
From UX to hardware: starting from SLO (p95 latency, success of operations) → looking for a limiting resource.
Rightsizing: resources and instance types for the nature of the load.
Cash and proximity: reduce "expensive" trips to storage and networks.
Automation: autoscaling, life cycle policies, IaC.
Observability: four-signal metrics, CPU/alloc profiles, tracing.
Security = performance: mTLS/signatures/limits - hardware accelerated where possible.
CPU and scheduling
Tasks: minimize content and cache misses, take into account NUMA and interrupts.
NUMA awareness: pinning by nodes ('numactl --cpunodebind --membind'), for databases/brokers - fix on the node.
IRQ/softirq: distribute by cores (RSS/RPS), secure hot queues for the CPU without competing with workers.
Hyperflow: for "latency sensitive" - fix workers on physical cores.
Context switches: reduce through long queues/butchings/asynchron.
Compilers/JIT: include PGO/LTO (C/C + +), Graal/HotSpot profiles (Java), 'GOMAXPROCS', and worker allocation (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
Memory and Allocation Management
THP/HugePages: for JVM/DB - usually disable THP and use hugepages manually (reduces TLB misses).
NUMA balance: for stateful - commit memory to the local node.
- JVM: G1/ZGC, '-Xms = -Xmx' equal, reasonable 'MaxGCPauseMillis'.
- Go: 'GOGC' (start with 100-200), avoid unnecessary allocations, 'pprof' profiles.
- Python: use 'uvloop', 'asyncio', C-extensions, connection pool.
- Swap/zswap: on sale, usually swap off for critical services; on general-purpose nodes - zswap for "soft" loads.
Storage and I/O
Disk types: NVMe for hot-path, separate pools for logs/checkpoints/tempo.
FS: XFS for large files/DB logs; ext4 for small/versatile.
RAID/EC: RAID10 for low latency, RAID6/EC for cold data.
I/O schedulers: 'none '/' mq-deadline' for NVMe.
Async/Batch: group records, 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
Network
MTU and offload: 9000 MTU in the data center (if end-to-end), enable GRO/LRO where allowed.
RSS/RPS/RFS: multichannel queues on the NIC, distribution by cores; irqbalance - under control.
SO_REUSEPORT: scalable listen sockets distributed across cores.
Client timeouts and pullings: short TCP keepalive, limit of open connections, backpressure.
TLS: TLS 1. 3, AES-NI hardware instructions, session resumption, 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 (where appropriate)
GPU: anti-fraud inference, recommendations, CV; monitor 'util', 'mem', 'sm _ efficiency'.
SmartNIC/eBPF/DPDK: L4/L7 offload, filtering, telemetry without transitions to the kernel.
Energy profiles: fix frequencies for stable latency; avoid aggressive power-save.
Applications and RDBMS
Connection pools: limit 'max _ conns', apply connection pooling (PgBouncer/Hikari).
Indexes/schedulers: EXPLAIN/ANALYZE profiles covering indexes, partitioning.
Caching: Redis/in-process cache, CDN for statics, edge cache for hot APIs.
Idempotence and queues: avoid cascades of retreats, turn on dedup.
Gzip/Brotli: compression of responses taking into account the CPU cost; choose balance.
Containers and Kubernetes
Requests/Limits и bin-packing
Requests = "guarantee," Limits = "ceiling." Incorrect Limits by CPU → throttling and p99.
Consider burst loads (tournament/match peaks) - margin in p95.
Bin-packing: separate host pools (latency-crit, batch, GPU, spot). Use topology (anti-affinity, spread).
Autoscaling
HPA by custom metrics (RPS/p95, not CPU).
VPA for "long-lived" and "off-peak" workers.
Cluster Autoscaler + individual node groups (on-demand/spot).
KEDA for event loads (queues, Kafka, cron).
Scheduler and Managers
CPU Manager: 'static' for pinning full cores to latency-critical feeds.
Topology Manager NUMA alignment.
HugePages/Device Plugins: for DB/low latency and 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 and cost
Tariff profiles: select instances by CPU/RAM/disk/network (compute-optimized, memory-optimized, storage-optimized).
Spot/Preemptible: for batch/staging/caches with multi-zone redundancy.
Reservation/Savings: reserves for 1-3 years for the "permanent" part.
Hot/cold: tiered-storage, archive object, log retention.
Idle resources: night/weekend stops of non-critical environments.
Energy Efficiency (GreenOps)
Power profiles: performance vs balanced by service.
Co-location: compaction during cold hours, turning off unused nodes.
KPI: watt per request, p95/watt, CO₂ - provider metrics.
Observability and testing
Метрики: CPU steal/throttle, `cycles/instructions`, LLC miss, RSS/working set, page faults, disk lat p95/99, NIC drops, retransmits.
Tracing: distributed trails for "golden paths."
Profiling: eBPF/Perf/Flamegraphs, 'pprof '/YourKit/JFR.
Load tests: SLO-oriented, with a real mix of operations, a "warm-up" phase, 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)
Optimization checklist
- SLOs and Golden Paths (APIs/Payments/Disbursements) are defined.
- CPU/alloc/IO/network profiles collected, top-N bottlenecks found.
- NUMA/IRQ/RSS are configured on latency-critical nodes.
- THP off (if necessary), hugepages for DB/Java services.
- NVMe for hot data, XFS/IO-sched configured, fio-bench confirmed.
- Network stack: MTU, RPS/RFS, SO_REUSEPORT; timeouts/pools.
- Kubernetes: Requests correct, Limits do not stifle, HPA by business metrics, VPA/CA included.
- Caching and CDN on "expensive" paths; Redis/edge cache.
- FinOps: rightsizing/reserves/spot pools; stopping idle environments.
- Performance autotests in CI, regressions on p95/p99.
iGaming/fintech specific
Scheduled peaks: tournaments/matches/promotions → "elastic" pool of fronts, pre-warming of caches/CDN, HPA by RPS/latency.
Payments and payments: individual "gold" IP/domains, priority queues, resource isolation (tains/tolerations), base reserve.
Antibot/antifraud: heavy-models - on GPU-workers; online scoring ≤ 50 ms p95; cache of features.
Regulatory: unchangeable logs and encryption should not break SLO - turn on hardware accelerations and asynchronous pipelines.
Mini playbooks
↑ latency after release:1. Check burn-rate SLO; 2) 'cpu/alloc' profiles; 3) rollback/feature flag; 4) increase replica/API cache; 5) RCA and test fixation.
Peak load (match/tournament):1. Warm up CDN/cache; 2) lift minReplicas; 3) include burst limits; 4) post queues; 5) enable read-only mode for secondary functions.
Common mistakes
Limits CPU "suffocate" peak workloads → high p99.
Invalid node pool: mix latency-critical and batch.
Absence of NUMA/IRQ settings on databases/brokers.
"Treating symptoms" (adding CPU) instead of fixing algorithms/caches/SQL.
HPA by CPU instead of RPS/latency → scales late.
No performance tests in CI → regression in prod.
Total
Optimization is a systematic job: measure SLI/SLO, profile, fix algorithms, tune hardware (NUMA/IRQ/IO/network), "size" resources correctly and automate scaling. Capture improvements in templates (images, charts, politics), control cost and energy - and your platform will remain fast, economical and sustainable even at extreme peaks.