Dimensiona la app que realmente ejecutas.

Než začnete měřit

Použijte testovací stroj Linux, který ovládáte, s vaší aplikací a reprezentativními daty. Níže uvedené příkazy zkoumají prostředky; neladí jádro ani neodstraňují soubory. Potřebujete procps a GNU coreutils a oprávnění prozkoumat zvolený adresář aplikace. Nahraďte /srv/my-app jeho skutečnou cestou. Pokud aplikace zatím nikde neběží, použijte její vývojové nebo testovací prostředí k sestavení počátečního odhadu a poté tento odhad přehodnoťte na zamýšleném systému.

Zapište si, co sdílí VPS: operační systém, proxy, API, databázi, workery a monitorování. Zaznamenejte, zda se tam spouštějí sestavení assetů, zda jsou zálohy komprimovány lokálně a zda se naplánovaná úloha může překrývat s nasazením. Tichý proces aplikace může koexistovat s nákladným procesem vydání.

Přečtěte si dostupnou paměť a identifikujte procesy

free -m
ps -eo pid,comm,rss --sort=-rss | head -n 12

free -m uvádí mebibyty. Zaměřte se na available, odhad paměti, která by mohla podpořit novou práci bez swapování; free samotné vylučuje užitečnou uvolnitelnou paměť. Cache tedy sama o sobě není důvodem k zakoupení větší RAM. Viz definice polí free.

Illustrative selected fields — not an OffVPS measurement
Mem total: 2048 MiB
Mem free:   180 MiB
Mem available: 800 MiB

Illustrative ps rows
  PID COMMAND     RSS
 2100 postgres 393216
 2140 node     184320
  920 caddy     32768

Hodnoty RSS procesů výše odpovídají přibližně 384, 180 a 32 MiB. Pomáhají lokalizovat využití paměti, ale sčítání všech hodnot RSS není přesný součet celého stroje: sdílené stránky mohou být započítány vícekrát a některé náklady jádra jsou mimo údaj procesu. Při sběru reportu se vyhněte vypisování argumentů příkazů nebo proměnných prostředí, protože mohou obsahovat tajné údaje. manuálová stránka ps vysvětluje svá pole a chování snímku.

Převeďte pozorování do pracovního listu

Následující příděly ilustrují malé API s lokální databází a jedním workerem. Jsou to vymyšlené plánovací hodnoty, nikoli benchmarky ani minimální požadavky pro konkrétní framework. Nahraďte je svými měřeními a poznamenejte, které příděly mohou kulminovat současně.

Tento pracovní list již překračuje rozpočet 1,024 MiB. Testovací prostředí 2,048 MiB by proti těmto přídělům ponechalo 676 MiB, ale užitečným výsledkem je, zda se skutečná reprezentativní práce vejde, zatímco aplikace zůstane responzivní. Pokud dominuje příděl na nasazení, sestavování artefaktů jinde může být lepší změnou než zvětšování trvalého serveru. Předpoklady uchovávejte vedle součtu.

Sledujte CPU a swap během užitečné práce

vmstat 1 10

Spusťte to během reprezentativní dávky požadavků, úlohy a vydání. Při interpretaci nedávného intervalu ignorujte první řádek: shrnuje aktivitu od spuštění. Další řádky popisují intervaly vzorkování. Trvalá spustitelná práce v r, nízká doba nečinnosti v id a pomalé požadavky společně ospravedlňují prošetření tlaku na CPU. Opakovaná si/so aktivita ukazuje swapování; samotná přidělená swap paměť neprokazuje současný tlak. wa y st potřebují kontext, nikoli automatický upgrade CPU. Tato pole jsou definována v vmstat.

Zaznamenejte také dobu odezvy v aplikaci. Pomalé externí API nebo databázový dotaz mohou zdržovat požadavky, zatímco CPU zůstává převážně nečinné. Po jedné změně zopakujte stejnou zátěž, abyste věděli, která změna pomohla. Zátěžové testy by měly cílit pouze na systémy, které ovládáte, s rychlostí a podmínkou zastavení, které nebudou narušovat ostatní uživatele.

Rozpočtujte růst disku a přenos zvlášť

df -h /srv/my-app
df -i /srv/my-app
du -sh /srv/my-app

df popisuje souborový systém obsahující cestu, včetně místa sdíleného s jinými adresáři; df -i kontroluje využití inodů tam, kde je to podporováno. Velké množství malých souborů může vyčerpat inody dříve než bajtovou kapacitu. du odhaduje zvolený strom s výhradou přístupových oprávnění. Jde o různé otázky, takže jejich součty se nemusí shodovat. Viz df y du.

Seznamte aktuální databázi, nahrávané soubory, protokoly, artefakty aplikace a jakýkoli lokální prostor pro přípravu záloh. Přidejte prostor potřebný pro vydání vedle předchozího vydání a poté odhadněte růst za další kontrolní interval. Například 100 MiB nových nahrávek každý den přidá přibližně 3,000 MiB za 30 dní před replikami nebo zálohami. Při porovnávání výsledku s katalogem označujte desetinné GB a binární GiB konzistentně.

Pro přenos je ilustrativní odpověď 20 kB odeslaná 50,000 krát přibližně 1 GB datové zátěže odpovědi. Přidejte nahrávání, statické soubory, režii protokolu a provoz záloh. Tato aritmetika odhaduje objem, nikoli propustnost nebo souběžné uživatele. Ověřte, jak služba počítá provoz a jak zachází s případným přebytkem.

Zvolte další krok a ověřte jej

• Nízká dostupná paměť během běžných špiček: prozkoumejte hlavní spotřebitele a otestujte větší rozpočet paměti.
• Pomalé požadavky s trvalým tlakem na CPU: profilujte vytíženou cestu a poté porovnejte změny CPU při stejné zátěži.
• Rostoucí využití disku: před odstraněním čehokoli identifikujte odpovědný adresář a zásady uchovávání.
• Prostředky vypadají pohodlně, ale aplikace je pomalá: prozkoumejte závislosti, dotazy a cestu požadavku.

Uložte pracovní list s popisem zátěže, časem vzorkování, jednotkami a datem příští kontroly. Zkontrolujte znovu po významném vydání, růstu dat nebo přidání workeru. Zvolte konfiguraci na základě těchto pozorování; žádný název plánu nezaručuje kapacitu požadavků. Pokračujte čtením varování o paměti a disku nebo prvním scénářem API zdroje.