Vierstappenmethode voor het verlagen en vervangen van cloudserverconfiguratie: hoe je een overbodige hoge configuratie veilig naar beneden brengt

Bepaal of het een groot paard is dat een kleine kar trekt, en downgrade dan zonder prestatieverlies.

Bijgewerkt 2026-08-09 · CloudWorth

Cloudserver downgradenGroot paard, kleine karBetaalbaar alternatiefFinOpsEchte benchmarksCloudWorthSteal TimeVPS oversellingVPS benchmark

Alleen met echte benchmarks en Steal Time-verificatie kun je veilig downgraden en de helft van het budget besparen.

Hoe bepaal je of het 'groot paard voor een kleine kar' is

Haast je niet om te downgraden. Eerst moet je bevestigen of je cloudserver echt een 'groot paard voor een kleine kar' is – CPU al lange tijd onder 10%, geheugen minder dan de helft gebruikt, schijf-IO vrijwel inactief, maar de maandelijkse rekening wordt tegen hoge specificaties in rekening gebracht. Dit scenario is heel typisch: destijds kocht je 8C16G voor 'toekomstige uitbreiding', maar na een half jaar gebruik je pas 2C4G.

Mijn beoordelingsmethode is niet om naar de CPU-curves in de console te kijken, maar om met CloudWorth drie sets gegevens op te halen: echte benchmarks, Steal Time, schijf-Cache-prestaties.

• Echte benchmark vs. gespecificeerde configuratie: Bij dezelfde cloudserver is het aantal vermelde vCPU's niet gelijk aan de rekenkracht die je krijgt. Draai 30 minuten sysbench en vergelijk de score met andere merken in dezelfde prijsklasse. Als het verschil meer dan 30% is, betekent dit dat je een premie betaalt voor 'papieren specificaties' – dit is precies de typische 'prijs-prestatieval' in FinOps.

• Steal Time is de spiegel voor oververkoop: Kijk in Linux direct naar het steal-veld in /proc/stat of %st in top. Als dit langere tijd boven de 5% ligt, betekent dit dat buren je CPU aftroggelen en je hoge configuratie mogelijk 'opgeblazen' is. In dit geval moet je vóór het downgraden eerst op een andere machine testen, anders kan het steeds trager worden.

• Schijf-Cache-klif-test: Schrijf met dd een bestand van 2 GB. De eerste 200 MB haalt 1,2 GB/s, daarna zakt het naar 150 MB/s – dit is de typische curve wanneer de cache is uitgeput. Vergelijk bij het downgraden de stabiele IO van oude en nieuwe abonnementen; laat je niet misleiden door 'de eerste seconden snel te zijn'.

Kortom: eerst bewijs verzamelen, dan pas downgraden. Pas als je met echte benchmarks en Steal Time kunt aantonen dat je een overkill-configuratie hebt, voorkom je de illusie van 'groot paard voor een kleine kar' en komt het bespaarde budget echt in je zak terecht.

Echte benchmarks en opgegeven configuratie

Bij het kopen van een cloudserver kijken naar het opgegeven aantal CPU-kernen, geheugen en bandbreedte is als naar een cv kijken met 'afgestudeerd aan een prestigieuze universiteit' — het klinkt mooi, maar of het echt kan presteren moet je in een sollicitatiegesprek ontdekken. Ik laat gewoonlijk sysbench, Geekbench en Steal Time even rondrennen, vooral als je vermoedt dat je een 'groot paard voor een kleine kar' hebt.

Laat me een valkuil noemen: ik heb een 8C16G-instantie gezien waarvan de single-core score slechts 1,2 keer de basislijn was en Steal Time constant boven de 20%. Oppervlakkig gezien is het een krachtige machine die stof verzamelt, maar in werkelijkheid is er overbezetting door buren en is de echte rekenkracht minder dan die van een 2C4G. Deze 'groot paard voor een kleine kar' is een illusie — niet omdat de workload klein is, maar omdat de machine zwak is. Dus voordat je downgradet, moet je eerst bewijzen verzamelen: gebruik echte benchmarks om de oude instantie tot op het bot te strippen, kijk naar CPU-scores, schijf 4K random en of de cache van een klif valt.

Een ander kruispunt is de FinOps-premie. Veel 'high cost/performance'-instanties hebben een lage prijs en goede specificaties, maar zodra de schijfcache opraakt, vallen ze terug naar de ruwe schijfsnelheid. Dat is een nep-lage prijs. Voor een echt betaalbaar alternatief moet je tegelijkertijd kijken naar de stabiele benchmark over 30 minuten en Steal Time, een ronde draaien met CloudWorth, en 'nominaal → gemeten → premie' in een tabel zetten. Alleen als de getallen kloppen, is downgraden niet van een groot paard naar een mager paard.

Veilig downgraden in vier stappen

Downgraden is geen kwestie van nattevingerwerk; ik heb het samengevat in vier stappen, elke stap om die klassieke valkuil te vermijden: van een overboekte high-end machine naar een normale low-end machine gaan, en het blijkt slechter dan voorheen.

Stap 1: Bewijs eerst dat het echt 'een groot paard dat een kleine kar trekt' is
Kijk niet alleen naar het aantal cores en GB in de console; trek eerst een week aan CPU-, geheugen-, disk-IO- en netwerkcurven. Als de CPU langdurig onder de 10% blijft en het schijflees-/schrijfverkeer bijna platligt, is het feitelijk verspilling. Maar let op: gebruik echte benchmarks om te verifiëren, laat je niet misleiden door de opgegeven specificaties. Draai YABS en sysbench, vergelijk met CloudWorth's Steal Time-gegevens. Als de Steal Time van de high-end machine langdurig boven de 10% ligt, is de 'prestatie' mogelijk schijn; downgraden kan dan juist stabieler zijn.

Stap 2: Kies het doelpakket op basis van prijs-kwaliteit, niet alleen op basis van de eenheidsprijs
Deel de maandelijkse kosten van het oude en nieuwe pakket door de echte benchmark (bijv. Geekbench single-core score) om te berekenen welke prestatie je krijgt voor elke cent. Dit is eigenlijk de 'premium ratio'-gedachte uit FinOps: betaal niet voor ongebruikte overcapaciteit, en koop ook niet voor geldbesparing een 'overboekingskoning' met een dramatisch lagere score. Vergelijk vooral de prestaties van de schijfcache: gebruik dd om continu 1GB en 10GB te lezen en kijk of de eerste seconden en daarna plotseling dalen. Als de cache van de downgrademachine normaal is, is de ervaring vaak vloeiender.

Stap 3: Verifieer direct na de migratie de Steal Time
Verwijder na het downgraden niet te snel de oude machine; draai eerst 30 minuten stress en houd tegelijkertijd de st-kolom in de gaten met vmstat. Als de Steal Time van het nieuwe exemplaar >15% is, betekent dit dat de buren te luidruchtig zijn; wissel dan onmiddellijk van regio of provider. Deze stap is de ondergrens van veilig downgraden.

Stap 4: Observeer twee weken en houd een terugdraaiplan klaar
Bewaar een snapshot van de oude machine en observeer ten minste twee bedrijfspiekcycli. Als het verkeer toeneemt, schaal dan terug omhoog; forceer het niet. Mijn eigen ervaring: met deze werkwijze daalden de maandelijkse kosten van $40 naar $18, terwijl de benchmarkscore juist met 12% steeg - omdat ik het 'opgeblazen' gevoel van de overboekte high-end machine kwijtraakte.

Samenvatting in één zin: De kern van downgraden is niet het bezuinigen op het budget, maar het met data bewijzen dat je 'een klein paard voor een kleine kar' bent, en dan een ander niet-overboekt klein paard hetzelfde karretje laat trekken.

Hoe controleer je overselling na een downgrade

Het grootste risico na een downgrade is niet dat de prestaties afnemen, maar dat je geld uitgeeft en de prestaties slechter worden — dit ligt meestal niet aan de downgrade zelf, maar aan een nieuwe instantie die last heeft van overselling. CloudWorth's aanpak: vertrouw niet op de nominale configuratie, doe eerst een praktijktest van 30 minuten.

Begin met Steal Time. Voer op de instantie een continue steekproef uit:

vmstat 5 60 | awk '$22'  # kolom 22 is st, sample elke 5 seconden, 60 keer

Als het st-gemiddelde boven de 5% ligt, betekent dat dat de buren op de host CPU-tijd afsnoepen en is er een grote kans op overselling. Als het langdurig boven de 15% ligt, is het advies om over te stappen naar een andere provider of een ander abonnement.

Kijk vervolgens naar de echte benchmarks en de cache-curve van de schijf. De benchmarks vóór de downgrade kunnen zijn beïnvloed door resourceconcurrentie van een high-end virtuele machine; na de downgrade kan het juist sneller zijn — dit bevestigt indirect dat je vorige configuratie een typisch geval was van 'met een kanon op een mug schieten'. Gebruik hetzelfde script (zoals sysbench + fio) om oud en nieuw te vergelijken, met focus op:

• Veranderingen in single-core en multi-core scores, niet het totaal
• De eerste 10 seconden cache-lezen/-schrijven vs. willekeurig schrijven na stabilisatie
• Of het geheugenbandbreedte de opgegeven frequentie haalt

Als het verschil tussen de score van de nieuwe instantie en de 'nominale configuratie' meer dan 30% bedraagt, wees dan alert op overselling; als het onder de 20% blijft, is de prijs-kwaliteitverhouding in deze prijsklasse al behoorlijk goed.

Hier nog een FinOps-perspectief: noem de gemeten prestaties / maandelijkse kosten na de downgrade de 'prijs-kwaliteitratio'. Bijvoorbeeld: de oude machine kost 200 yuan per maand en scoort 8000 punten, ratio 40; de nieuwe machine kost 100 yuan per maand en scoort 6000 punten, ratio 60 — hoewel de score 25% lager is, is de prestatie per eenheid kosten met 50% gestegen. Dat is de sweet spot van een downgrade als goedkoop alternatief.

Vergeet tot slot niet om na een herstart te verifiëren. Veel downgrades worden 'hot' doorgevoerd; na een herstart worden CPU-quota en schijflimieten opnieuw geladen. Start opnieuw en draai nog een ronde vmstat en fio om te controleren of Steal en IOPS niet dramatisch zijn gedaald; pas dan is de downgrade echt geslaagd.