Een CPU kiezen voor CI/CD, virtualisatie en Kubernetes-nodes
Kort antwoord
Match het aantal cores en de klokfrequentie met waar de workload daadwerkelijk op vastloopt: CI/CD-buildnodes hebben vooral baat bij hoge single-thread performance en genoeg cores om jobs parallel te draaien, terwijl virtualisatie- en Kubernetes-nodes meer hebben aan het aantal cores en consistente prestaties per core dan aan een hoge klokfrequentie, omdat resources over veel tenants of pods worden verdeeld.
Sizen per type workload
| Workload | Wat telt het zwaarst | Waarom |
|---|---|---|
| CI/CD, buildnodes | Hoge single-thread performance, genoeg cores voor parallelle jobs | Compilers en testsuites zijn per job vaak single-threaded; meerdere jobs tegelijk draaien vraagt genoeg cores om wachtrijen te voorkomen |
| Virtualisatie (Proxmox, VMware) | Aantal cores, consistente prestaties per core | Elke VM krijgt een deel van de CPU; meer cores betekent meer VM's zonder contentie, en consistentie telt hier zwaarder dan piekklokfrequentie |
| Kubernetes worker nodes | Aantal cores, marge boven toegewezen pod-requests | Kubernetes plant pods in op basis van de aangevraagde CPU, niet het werkelijke gebruik; te krap gedimensioneerde nodes leiden tot throttling onder belasting |
| Databases, IO-intensieve services | Snelle single-core performance, gecombineerd met NVMe-storage | Veel database-engines zijn nog grotendeels single-threaded per query; storagesnelheid telt hier net zo zwaar als CPU, zie Storagemedia kiezen |
Sizen voor gemengde workloads
Draait één machine een mix (bijvoorbeeld een handvol VM's plus een buildpipeline), ga dan uit van de eis van de drukste losse workload en tel daar marge voor de rest bovenop, in plaats van alles samen te middelen. Een bruikbaar startpunt: tel de vCPU's op die je van plan bent toe te wijzen aan VM's of pods, reken marge bij voor de overhead van de hypervisor of het control plane zelf, en dimensioneer storage-IOPS op de workload met de hoogste I/O-vraag, niet op het gemiddelde.
Troubleshooting: hoge belasting, maar de CPU lijkt inactief
Voelt je applicatie traag terwijl de CPU-gebruiksgrafieken volop vrije capaciteit tonen, kijk dan naar CPU steal time voordat je ervan uitgaat dat de applicatie zelf het probleem is. Steal time is het percentage tijd dat een virtuele CPU klaarstaat om te draaien maar moet wachten tot de fysieke host hem inplant, iets wat vaak voorkomt op gedeelde gevirtualiseerde infrastructuur onder contentie.
- Controleer op Linux de steal time met
mpstat -P ALL 1(de kolom%steal) ofsar -u 1. - Correleer dit met p95/p99-latency op applicatieniveau, niet alleen met gemiddelden: steal time uit zich meestal in incidentele latency-piekjes, niet in een gestage vertraging.
- Is de steal time structureel hoog, dan zit de oplossing meestal in meer dedicated resources (een groter VPS-tier, of een dedicated/Bare Metal Compute server), niet in verder tunen van de applicatie.