Cloudserver-benchmarks en overdreven configuraties: verouderde CPU's herkennen en valkuilen vermijden
Drie bewijsmethoden ontmaskeren de leugen van de meerprijs voor verouderde CPU's
Gebruik Steal Time + disk-cache + echte benchmarks voor drievoudige validatie en weiger een meerprijs te betalen voor verouderde CPU's.
Hoe ver ligt de benchmark van de opgegeven specificatie?
De kloof tussen de benchmark van een cloudserver en de opgegeven configuratie is vaak groter dan je denkt. Vooral oudere CPU's met een 'hoge klokfrequentie', zoals de Xeon E5-2690 v4 en E5-2680 v4 uit ongeveer 2016, lijken een redelijke single-core frequentie te hebben, maar een single-thread benchmark kan in werkelijkheid maar de helft zijn van een nieuwere generatie Xeon. Er zijn twee belangrijkste oorzaken voor deze 'opgeblazen' benchmarkcijfers: de ene is het generatieverschil in hardware, de andere is de sterke stijging van Steal Time als gevolg van overboeking (overselling).
Wanneer een ouder platform wordt gevirtualiseerd, vertelt het steal-veld in /proc/stat je hoeveel tijd de CPU door de hypervisor wordt ingenomen. Als je via mpstat -P ALL 1 ziet dat %steal langdurig boven de 10% ligt, betekent dit dat buren met je concurreren om resources; in dat geval is de benchmark, hoe hoog de specificaties ook zijn, onstabiel. Een andere verborgen indicator is de abrupte daling van de schijfcache: bij oudere opslag die bij oudere CPU's hoort, halveert de IOPS direct zodra de cache vol is, en de benchmarkcurve vertoont dan een duidelijk dal.
Om het verschil te kwantificeren, kun je yabs of sysbench cpu --threads=1 run draaien en vergelijken met de officiële specificaties. Ik heb meegemaakt dat een ouder platform met een opgegeven 3,5 GHz een daadwerkelijke single-core benchmark had die 40% lager lag dan een nieuw platform van 2,9 GHz. Met andere woorden: voor het geld dat je betaalt voor 'hoge klokfrequentie + oude configuratie' is mogelijk de helft een premie voor gebruikte hardware. Dit is precies het meest typische negatieve kostenpatroon in FinOps: met hetzelfde budget, door te kiezen voor een nieuwer platform of officieel gecertificeerde instanties, zijn de kosten per rekeneenheid lager.
Dus kijk niet alleen naar de opgegeven parameters. Het advies is om in CloudWorth instanties te filteren op basis van werkelijke benchmarks en Steal Time-drempels, en je budget uit te geven aan echte prestaties.
Steal Time opsporen van overselling
Om door de opgeblazen configuratie van cloudservers heen te kijken, begin je met steal time. Deze metriek is het geheime teken dat de hypervisor je geeft: wanneer de fysieke CPU door de 'huisbaas' aan de virtuele machine van de buren wordt gegeven, kan jouw vCPU alleen maar wachten. Gebruik top en druk op C om naar de CPU-lijst te schakelen, druk vervolgens op t om de steal-kolom te zien, of voer direct vmstat 1 uit en kijk naar het st-veld. Neem een paar minuten monsters. Als het gemiddelde van st boven de 5% ligt, of zelfs pieken tot 20%+ vertoont, gefeliciteerd, dan deel je een fysieke kern met een stel vervelende buren.
# 连续采样 10 次,每次间隔 1 秒,取 st 平均值
vmstat 1 10 | awk 'NR>3 {sum+=$16} END {print "avg steal:", sum/(NR-3), "%"}'Een piek in Steal Time is alarmerender dan een stabiele hoge waarde – het geeft aan dat de overselling dynamisch is en dat je responstijden tijdens piekuren willekeurig kunnen fluctueren als een ECG. In combinatie met de disk-cache-afgrond uit de vorige sectie, kun je hiermee bevestigen dat dit een host is die herhaaldelijk wordt onderverhuurd op een oude fysieke machine.
Vanuit een FinOps-perspectief is dit typische premiefraude: je betaalt de prijs van nieuwe hardware, maar krijgt de resten van een oude CPU die aan stukken is gesneden, met een opslag die bijna drie keer die van de publieke cloud is. Geloof niet blindelings in hoge klokfrequenties; hoe krachtig de oude Xeon-kern ook is, hij kan de sprint van de buren niet weerstaan. Kijk vóór het benchmarken eerst naar steal, anders is een mooi Geekbench-getal slechts een luchtspiegeling op het oversell-zandbak. Deze metriek is gratis en reproduceerbaar, en eerlijker dan welke belofte van een verkoper dan ook.
Bewijsvoering voor diskcache-afgrond
Eerder gebruikten we Steal Time om oververkoop op te sporen, maar sommige oude datacenters voeren de CPU-planning zo gelijkmatig uit dat de Steal-gegevens er niet slecht uitzien. Trek dan niet te snel conclusies — verleg je aandacht naar de diskcache, een van de hardwarecomponenten die het minst liegt.
In de praktijk draai ik meestal twee fio-rondes achter elkaar: eerst de buffered write met Page Cache, daarna de direct write die de cache omzeilt. De commando's zien er ongeveer zo uit:
# 第一轮:缓冲写(吃内存Cache)
fio --name=cache-test --rw=write --bs=1M --size=2G --direct=0 --ioengine=libaio --runtime=30 --time_based
# 第二轮:直写(绕Cache,直接落盘)
fio --name=direct-test --rw=write --bs=1M --size=2G --direct=1 --ioengine=libaio --runtime=30 --time_basedLet vooral op de 'afgrond-verhouding' tussen de twee waarden. Bij een nieuwe NVMe-cloudschijf ligt direct write rond de 60–80% van buffered write; bij een oude mechanische schijf of gedeelde opslag kan direct write zakken tot onder de 10%. Als de schijf een nominale snelheid van 2000 MB/s heeft, maar direct write slechts 150 MB/s haalt, dan is dat een typische cache-afgrond — de cijfers flatteren je, pas bij het wegschrijven zie je de bodem.
Deze bewijsvoering moet je samen met Steal Time bekijken. Hoge Steal betekent dat de buren CPU-tijd inpikken; een schijfafgrond betekent dat het opslagkanaal ook overbelast is — als deze twee bewijzen samenkomen, kun je vrijwel zeker concluderen dat er sprake is van oververkoop, en niet zomaar een, maar een waarbij de onderliggende hardware oud en versleten is.
Vanuit FinOps-perspectief zouden dergelijke machines op 'restwaarde' gewaardeerd moeten worden. Als de meerprijs voor de gespecificeerde configuratie meer dan 30% boven die van een nieuwe machine ligt, eis dan onmiddellijk een prijsverlaging; lukt dat niet, stap dan over op een andere machine. Je betaalt immers voor specificaties, niet voor een luchtspiegeling op de cache. De volledige checklist om valkuilen te vermijden vind je in de Handleiding voor zelfcontrole van opgeblazen cloudserverconfiguraties.
Premiepercentage en beslissingsboom om valkuilen te vermijden
Als je een cloudserver met een 'oude CPU met hoge kloksnelheid' krijgt, haast je dan niet om te betalen. Bereken eerst het premiepercentage: (werkelijke maandelijkse betaling - marktprijs van een nieuwe CPU met dezelfde configuratie) / marktprijs van een nieuwe CPU met dezelfde configuratie. Als de premie meer dan 30% bedraagt, kun je er in principe van uitgaan dat je een domme belasting betaalt voor afgedankte hardware. Een nog hardere aanpak is om het direct te kwantificeren vanuit een FinOps-perspectief: kun je met hetzelfde geld een AMD EPYC met 2 keer zoveel kernen of een 3 jaar nieuwe Intel kopen? Als dat kan, betekent dit dat deze aankoop niet goedgekeurd mag worden.
Ga vervolgens door mijn drievoudige forensische beslissingsboom:
- Steal Time om slechte buren te vangen
vmstat 1 10 | awk '{print $17}' # 看 st 列Als het st-gemiddelde bij continue steekproeven > 5% is, of als er pieken van meer dan 20% optreden, duidt dit op ernstige overboeking van de host; CPU-tijd wordt gestolen door buren, en het verlagen van de configuratie is de enige manier om verliezen te stoppen.
- Disk Cache-klif-test
dd if=/dev/zero of=/tmp/test bs=1M count=1024 conv=fdatasyncDe eerste keer schrijft de cache 1,5 GB/s, de tweede keer zakt het direct naar 150 MB/s; de cache laat het afweten, typisch voor overboekte gedeelde opslag. Oude configuratie + disk-klif = dubbele misleiding.
- Echte benchmarkvergelijking
curl -sL yabs.sh | bashIs de single-core Geekbench 5 lager dan 700, maar de opgegeven kloksnelheid 3,5 GHz? Ga dan direct met dit rapport naar de klantenservice en vraag om een terugbetaling van het prijsverschil met een nieuwe 4-core CPU of om migratie.
Tot slot een harde regel: als elke promotiepagina 'hoge prestaties' claimt, maar pre-sales geen link naar echte benchmarks levert, behandel het dan in alle gevallen als een misleidende specificatie. Vertrouw alleen je eigen benchmarks en betaal alleen premie voor nieuwe CPU's.
FAQ
Hoe herken ik of de CPU van een cloudserver verouderd is?
Gebruik het commando 'cat /proc/cpuinfo' om het model te bekijken en vergelijk het met het jaar van uitgave; gebruik vervolgens Steal Time-monitoring. Als de steal hoog is, duidt dit op oververkoop en zijn de prestaties van een verouderde CPU slechter.
Hoe verifieer ik de echte prestaties bij overdreven configuraties?
Gebruik sysbench voor CPU-tests en vergelijk met de officiële benchmarkscores; controleer ook de disk-cache en IOPS, want verouderde schijven verlagen de echte prestaties.