Az operációs rendszerhez, az állandó szolgáltatásokhoz és a valósághű párhuzamossághoz tartalékkal válasszon memóriát. A CPU-t azután válassza ki, hogy megmérte, mely feladatok telítettek, párhuzamosan futnak-e, és milyen késleltetéseket tapasztalnak a felhasználók.
Írja le külön a normál és a csúcsidőszaki munkát
Az önmagában vett látogatószám gyenge méretezési bemenet. Egy kérés kiszolgálhat egy gyorsítótárazott fájlt, míg egy másik jelentést készít vagy sok táblát kérdez le. Sorolja fel azokat a webes munkásokat, adatbázist, gyorsítótárat, sorfogyasztókat és karbantartási feladatokat, amelyek megosztják majd a VPS-t. Írja le a normál párhuzamosságot és a várható legforgalmasabb műveletet. Vegye bele az ütemezett exportokat, csomagfrissítéseket és telepítéseket, ahelyett hogy láthatatlan háttértevékenységként kezelné őket.
Egy meglévő projekt esetében gyűjtsön egy reprezentatív időszakot, amely tartalmaz egy forgalmas ablakot. A válaszidőket és a hibákat az erőforrás-használat mellett rögzítse. Egy új projekt esetében készítsen kis tesztet valósághű kérésformákkal és adatméretekkel. A kezdeti becslése tökéletlen lesz; a hasznos cél egy dokumentált kiindulópont, amelyet a szállítás után a mért viselkedéssel össze tud hasonlítani.
A memóriaköltségvetést a folyamatok hozzáadása előtt állítsa össze
A memóriaigény a rendszerből, az állandó alkalmazásszolgáltatásokból, a munkásonkénti használatból és az ideiglenes műveletekből származik. Egy munkás lábnyomának megszorzása egy tervezett párhuzamossággal durva tervezési eszköz, nem garancia, mert a megosztott memória és a gyorsítótárak bonyolítják az összeget. Figyelje a tényleges folyamatokat terhelés alatt. Hagyjon elegendő helyet, hogy egy karbantartási feladat ne kényszerítse az alkalmazást minden maradék lapért versengeni.
Az adatbázis-beállítások váratlanul megsokszorozhatják a memóriahasználatot. A PostgreSQL dokumentálja, hogy a work_mem a lekérdezési műveletekre vonatkozik, és több művelet vagy munkamenet futhat párhuzamosan. Egy önmagában szerénynek tűnő beállításnak ezért nagyobb rendszerszintű hatása lehet. Olvassa el az adatbázis saját útmutatását, tesztelje a valósághű párhuzamosságot, és kerülje, hogy minden hirdetett gigabájtot egyetlen gyorsítótárnak rendeljen.
Különböztesse meg a CPU kihasználtságát a hasznos párhuzamosságtól
A processzorszám megmutatja, hány végrehajtási erőforrás jelenik meg a vendég számára, nem pedig azt, hogy a szoftvere milyen hatékonyan tudja használni azokat. Egy telített szál korlátozhatja az alkalmazást, míg más magok csendben maradnak. A munkások hozzáadása segíthet a független kéréseknél, de növelheti az adatbázis-versengést és a memóriaigényt is. A kétszeres magszám kétszeres átviteli sebességének feltételezése előtt ellenőrizze az alkalmazás párhuzamossági modelljét.
A KVM saját virtuális hardverrel rendelkező virtuális gépeket biztosít. Nem teszi minden vCPU-címkét azonos benchmarkká a gazdagépek és processzorgenerációk között. Ahol elérhető, hasonlítsa össze a felsorolt CPU modellt és a kiosztási feltételeket, majd értékelje a szolgáltatást a saját munkaterhelésével. Kerülje, hogy egy rövid szintetikus pontszámból vonjon le beszerzési következtetést, amely nem hasonlít az alkalmazásra.
Keressen nyomást és várakozást, ne csak átlagokat
A rendszer lassúnak tűnhet anélkül, hogy magas átlagos CPU százalékot tartana fenn. A folyamatok tárolásra, memóriavisszanyerésre vagy egy másik szolgáltatásra várhatnak. A Linux kernel Pressure Stall Information funkciója a CPU, a memória és az I/O várakozási információit teszi elérhetővé a támogatott rendszereken. Ezek a jelek segíthetnek az erőforrás-versengés azonosításában a normál kihasználtsági mutatók és az alkalmazásidőzítések mellett.
A mutatókat együtt olvassa. A tartós memórianyomás, a lapozás, a sikertelen foglalások és a lassú kérések más beavatkozásra utalnak, mint egyetlen telített számítási munkás. A tárolási várakozások lekérdezésmódosításokat vagy más lemezprofilt indokolhatnak. Egy külső API késleltetést nem javít meg a helyi RAM hozzáadása. A választott erőforrás növelése előtt magyarázza meg a megfigyelt szűk keresztmetszetet.
| Megfigyelt viselkedés | Vizsgálandó kérdés | Lehetséges következő lépés |
|---|---|---|
| Egy szál telített, a tartalék magok csendben | Futhat ez a munka párhuzamosan? | Javítsa a feladatot vagy változtassa meg a munkás kialakítását |
| Memórianyomás egy jelentés közben | Hány művelet fedi át egymást? | Korlátozza a párhuzamosságot vagy adjon hozzá tesztelt tartalékot |
| Lassú kérések I/O-várakozásokkal | Mely olvasások vagy írások késlekednek? | Vizsgálja meg a lekérdezéseket és a tárolási viselkedést |
| CPU és memória alacsony, a kérések lassúak | Egy függőség késlelteti a válaszokat? | Mérje meg a downstream hívásokat |
Tervezési példa kifejezett feltételezésekkel
Képzeljen el egy kis alkalmazást két webes munkással, egy adatbázissal és egy sorfogyasztóval. A csapat ezeket a szolgáltatásokat méri a szokásos kérések és egy jelentéskészítési feladat során. Felfedezi, hogy négy jelentés egyidejű engedélyezése élesen megnöveli a memóriaigényt, miközben késlelteti a normál forgalmat. Ahelyett hogy azonnal a legnagyobb csomagot vásárolná meg, korlátozza a jelentések párhuzamosságát, és újra méri az eredményt.
Ha a módosított munkaterhelés továbbra is több memóriát igényel, a frissítés most egy megfigyelt követelményre válaszol. Ha a sor továbbra is CPU-höz kötött, és a független feladatok párhuzamosan futhatnak, több végrehajtási erőforrás lehet megfelelő. Ezek példabeli döntések, nem a SwissOctet csomagok teljesítményszámai. Tartsa meg saját méréseit és korlátait a választott konfiguráció mellett.
Hagyjon világos utat a következő méréshez
Határozza meg azokat a jeleket, amelyek felülvizsgálatot váltanak ki: a válaszidő romlása, ismétlődő memórianyomás, növekvő sorok vagy megváltozott munkaterhelés. A monitorozást tartsa elég könnyűnek ahhoz, hogy ne váljon új szűk keresztmetszetté. Egy funkció vagy egy nagy adathalmaz hozzáadása után értékelje újra, és kerülje az ismételt frissítéseket, amikor a valódi probléma egy korlátlan folyamat vagy egy lassú lekérdezés.
A SwissOctet VPS családjai CPU és memóriaspecifikációkat, valamint kiválasztott erőforrás-beállításokat tesznek elérhetővé. Olvassa el a végleges konfigurációt a kiegészítők hozzáadása után, beleértve a számlázási időszakot és a végösszeget. A frissítési feltételeket az élő szolgáltatóval erősítse meg, mielőtt azokra támaszkodna. Hasznos VPS méret az, amely a mért munkaterhelést ésszerű tartalékkal és érthető következő lépéssel futtatja.
Az Ön gyakorlati ellenőrzőlistája.
- Szolgáltatások és karbantartási munkák leltározása.
- A normál és a forgalmas időszak párhuzamosságának mérése.
- Az állandó és ideiglenes memória tervezése.
- Annak ellenőrzése, hogy a CPU munka futtatható-e párhuzamosan.
- A nyomás, a kihasználtság és az alkalmazásidők összehasonlítása.
- Annak meghatározása, mikor kell felülvizsgálni a konfigurációt.
A fontos részletek.
A VPS méretezését a havi látogatók alapján kell végezni?+
A látogatószámot használja kontextusként, majd mérje a kérések összetettségét, a párhuzamosságot, az adatméretet és a háttérmunkát. Az azonos látogatószámok eltérő terhelést eredményezhetnek.
A több RAM mindig gyorsabbá teszi a szolgáltatást?+
Nem. Segít, amikor a memória szűkös, vagy hasznos gyorsítótárazást tesz lehetővé, de nem old fel minden CPU, tárolási vagy külső függőségi késleltetést.
A kétszeres vCPU-szám megduplázza a teljesítményt?+
Nem. A párhuzamosság, a processzor jellemzői, a versengés és az alkalmazás tervezése határozza meg, mennyi többletkapacitás hasznos.
Menjen a forráshoz.
Ezek a hivatkozások támogatják az útmutató műszaki fogalmait. Kövesse az aktuális dokumentációt, mielőtt éles rendszert módosítana.
- Linux kernel: Pressure Stall Information docs.kernel.org
- PostgreSQL: Erőforrás-fogyasztás www.postgresql.org
- KVM projekt: Kernel Virtual Machine www.linux-kvm.org
Szerkesztői útmutatás: SwissOctet. A példák tájékoztató jellegűek. A szolgáltatási specifikációkat, az elérhető opciókat és a szerződéses feltételeket külön kell ellenőrizni.