Egy kis VPN-átjáró átmegy egy sebességteszten, jól érzi magát, aztán ebéd után lassulni kezd. Az instance nem hazudott a teszt alatt; olyan krediteket költött el, amelyeket tétlenség közben keresett. A burstable instance-eket pontosan erre tervezték, ezért egy rövid benchmark rossz előrejelzője egy délutáni átvitelnek. A két kreditmód ráadásul másképp hibázik, és a kettő közötti választás az igazi döntés.

Honnan kölcsönözte a sebességteszt az eredményt

Egy CPU-kredit egy vCPU teljes kihasználtságon egy percig. A burstable instance az alapszintjének ütemében keres krediteket, és akkor költi el őket, amikor meghaladja ezt az alapszintet. Egy tétlen éjszaka egyenleget épít; egy zsúfolt reggel lecsapolja.

Ezért tűnik jónak az első teszt. Az instance-nek volt félretett kerete, elkötötte a titkosítási munkára, és egészséges rátát jelentett. Az eredmény semmit sem mond arról, mi történik, amikor az egyenleg nullára csökken. A benchmark egy burstöt mért, és a burst az, amit az instance nyújtani hivatott. Soha nem mérte azt az állandósult állapotot, amelyre most támaszkodni fog.

A számítás, amit el kell végeznie

A bemenetek az alapszint százaléka vCPU-nként, a vCPU-k száma, a felhalmozott egyenleg és a várható terhelés. Csak szemléltetésképpen vegyünk egy hipotetikus, két vCPU-s instance-t tíz százalékos vCPU-nkénti alapszinttel, 24 felhalmozott kredittel, ahol az egyik vCPU teljesen foglalt, a másik pedig tétlen. Ezek a számok megadott bemenetek, nem egy adott instance-méret specifikációja.

Earn rate:       2 x 10% x 60 = 12 credits/hour
Workload usage:  1 x 100% x 60 = 60 credits/hour
Net draw:        60 - 12 = 48 credits/hour
Accrued budget:  24 / 48 = 0.5 hours

Ezekkel a feltevésekkel a keret nagyjából fél óra alatt elfogy. A háttérmunka, a változó terhelés és az instance saját elszámolása elmozdítja az eredményt, és mindez nem jósolja meg a VPN átviteli sebességét. Azt jósolja meg, mikor kezd el számítani a tartós korlát.

Figyeljünk a második olvasatra is: ebben a példában egy foglalt vCPU nagyjából a teljes CPU-kapacitás fele. Egy mérsékelt összesített százalék elrejthet egy telített magot, ezért nézzük a magonkénti viselkedést a kreditadatok mellett.

Standard és Unlimited: ugyanaz a nulla, más jelentés

Standard módban a kimerült egyenleg az alapszint felé szorítja a tartós CPU-t. Az instance tovább dolgozik, csak lassabban, és a plafon kiszámítható. Unlimited módban az instance a nulla elérése után is meríthet a többletkreditekből, és az alapszint feletti tartós használat díjakat eredményezhet a szolgáltatás elszámolási szabályai szerint.

Tehát egy CPUCreditBalance nulla értéke az egyik módban szabályozást, a másikban lehetséges számlázást jelent. Ez a teljes összehasonlítás, és ezért félrevezető a mutatót a mód nélkül olvasni.

A többlet sem egyszerű kreditenkénti számla. A későbbi, alapszint alatti működés csökkentheti a többlethasználatot, és más díjazási feltételek is érvényesek. Ellenőrizze a beállított módot és az aktuális szolgáltatási szabályokat, ahelyett hogy egy régi blogbejegyzés ingyenes csomagra vonatkozó állítására hagyatkozna.

Mire figyeljünk valódi munka közben

Rögzítse a CPUCreditUsage és a CPUCreditBalance értékét az átvitel időtartama és rátája mellett. Unlimited esetén adja hozzá a CPUSurplusCreditBalance és a CPUSurplusCreditsCharged értékét. Az AWS CPU-kredit monitoring útmutatója elmagyarázza, mit jelent mindegyik, és milyen gyakran frissül.

Teszteljen újra reprezentatív párhuzamossággal és elég hosszú ideig, hogy lássa a trendet, és jegyezze fel a kezdő egyenleget. A tétlen reggel és a zsúfolt délután nem ugyanaz a kísérlet, még azonos parancsokkal sem.

Korlátok, amelyek nem CPU-k

A hálózati sávszélességnek saját alapszintje és burst-viselkedése van, és a csomagráta- vagy kapcsolatszám-korlátok előbb szűkíthetnek, mint a CPU. A memória számít, ha a VPN-implementáció kapcsolatonkénti állapotot tart, és egy kis instance jóval előbb kifogyhat belőle, mint a kreditekből.

Az egészséges kreditegyenleg tehát egy dolgot bizonyít: a CPU-keret nem a jelenlegi korlát. Semmit sem mond a hálózati útvonalról, és semmit sem mond arról, mi történik kétszeres párhuzamosság mellett. Nézze a hálózati mutatókat ugyanabban az ablakban, mint a kreditmutatókat, hogy egy átviteli sebesség-csökkenésnek legyen jelölt oka, ne csak elmélete.

Válasszunk alapszintet tudatosan

A mért tartós terhelés alapján válasszon alapszintet, vagy vállalja kifejezetten a burstöt, és tervezze be a költségét. Mindkét válasz védhető, ha le van írva; egyik sem védhető, ha valaki más sikeres videóstreamjéből következtetik ki.

Ha az átjáró terhelést hordoz, kezelje a kreditmódot a kapacitásterv részeként, ne pedig olyan alapértelmezettként, amelyet soha nem nyitott meg. Az a mód, amelyet választ, az a hiba, amelyet előre jelezhet.

Kapcsolódó cikkek