Dimensionați aplicația pe care o rulați efectiv.

Înainte de a măsura

Utilizați o mașină de test Linux pe care o controlați, cu aplicația dvs. și date reprezentative. Comenzile de mai jos inspectează resursele; ele nu reglează kernelul și nu șterg fișiere. Aveți nevoie de procps și GNU coreutils și de permisiunea de a inspecta directorul aplicației ales. Înlocuiți /srv/my-app cu calea sa reală. Dacă aplicația nu rulează încă nicăieri, folosiți mediul său de dezvoltare sau staging pentru a construi o estimare inițială, apoi revizuiți acea estimare pe sistemul dorit.

Notați ce partajează VPS-ul: sistemul de operare, proxy, API, baza de date, workerii și monitorizarea. Înregistrați dacă build-urile de active rulează acolo, dacă backupurile sunt comprimate local și dacă o sarcină programată poate suprapune o implementare. Un proces de aplicație liniștit poate coexista cu un proces de lansare costisitor.

Citiți memoria disponibilă și identificați procesele

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

free -m raportează mebibytes. Concentrați-vă pe available, estimarea memoriei care ar putea susține lucru nou fără swap; free singură exclude memoria reclamabilă utilă. Cache-ul nu este, prin urmare, prin el însuși un motiv pentru a cumpăra mai mult RAM. Consultați definițiile câmpurilor 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

Valorile RSS ale proceselor de mai sus corespund aproximativ cu 384, 180 și 32 MiB. Ele ajută la localizarea utilizării memoriei, dar însumarea fiecărei valori RSS nu este un total exact al mașinii: paginile partajate pot fi numărate de mai multe ori, iar unele costuri de kernel sunt în afara cifrei procesului. Evitați afișarea argumentelor comenzilor sau a mediilor la colectarea unui raport, deoarece acestea pot conține secrete. Manualul ps explică câmpurile sale și comportamentul de snapshot.

Transformați observațiile într-o foaie de lucru

Următoarele alocații ilustrează un API mic cu o bază de date locală și un worker. Sunt valori de planificare inventate, nu benchmark-uri sau cerințe minime pentru un anumit framework. Înlocuiți-le cu măsurătorile dvs. și notați care alocații pot atinge vârful în același timp.

Această foaie de lucru depășește deja un buget de 1,024 MiB. Un mediu de test de 2,048 MiB ar lăsa 676 MiB față de aceste alocații, dar rezultatul util este dacă munca reprezentativă reală se încadrează în timp ce aplicația rămâne receptivă. Dacă alocația de implementare domină, construirea artefactelor în altă parte poate fi o schimbare mai bună decât mărirea serverului permanent. Păstrați ipotezele alături de total.

Urmăriți CPU și swap în timpul lucrului util

vmstat 1 10

Rulați aceasta în timpul unui lot reprezentativ de cereri, al unui job și al unei lansări. Ignorați prima linie când interpretați un interval recent: aceasta rezumă activitatea de la boot. Liniile ulterioare descriu intervalele de eșantionare. Lucru rulabil persistent în r, timp de inactivitate scăzut în id și cererile lente justifică împreună investigarea presiunii CPU. Activitatea repetată de si/so arată swapping; swap-ul alocat singur nu dovedește presiunea curentă. wa și st necesită context mai degrabă decât un upgrade automat de CPU. Aceste câmpuri sunt definite în vmstat.

Înregistrați și timpul de răspuns la nivelul aplicației. Un API extern lent sau o interogare lentă a bazei de date poate face cererile să aștepte în timp ce CPU rămâne în mare parte inactiv. Repetați aceeași sarcină de lucru după o singură modificare, pentru a ști ce modificare a ajutat. Testele de încărcare trebuie să vizeze doar sistemele pe care le controlați, cu o rată și o condiție de oprire care evită perturbarea altor utilizatori.

Bugetați separat creșterea discului și transferul

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

df descrie sistemul de fișiere care conține calea, inclusiv spațiul partajat cu alte directoare; df -i verifică utilizarea inode-urilor acolo unde este acceptat. Un număr mare de fișiere mici poate epuiza inode-urile înainte de capacitatea în octeți. du estimează arborele ales, în funcție de permisiunile de acces. Acestea sunt întrebări diferite, deci totalurile lor nu trebuie să coincidă. Consultați df și du.

Enumerați baza de date curentă, încărcările, jurnalele, artefactele aplicației și orice spațiu local de staging pentru backup. Adăugați spațiul necesar pentru o lansare alături de lansarea anterioară, apoi estimați creșterea pe următorul interval de revizuire. De exemplu, 100 MiB de încărcări noi în fiecare zi adaugă aproximativ 3,000 MiB în 30 zile înainte de replici sau backupuri. Etichetați consecvent GB zecimal și GiB binar când comparați rezultatul cu un catalog.

Pentru transfer, un răspuns ilustrativ de 20 kB trimis de 50,000 ori este de aproximativ 1 GB de payload de răspuns. Adăugați încărcările, fișierele statice, overhead-ul de protocol și traficul de backup. Acea aritmetică estimează volumul, nu debitul sau utilizatorii simultani. Confirmați cum contorizează serviciul traficul și cum gestionează orice exces.

Alegeți următoarea acțiune și verificați-o

• Memorie disponibilă scăzută în timpul vârfurilor normale: inspectați principalii consumatori și testați un buget de memorie mai mare.
• Cereri lente cu presiune susținută pe CPU: profilați calea ocupată, apoi comparați modificările de CPU folosind aceeași sarcină de lucru.
• Utilizare crescândă a discului: identificați directorul responsabil și politica de retenție înainte de a șterge ceva.
• Resursele par confortabile, dar aplicația este lentă: investigați dependențele, interogările și calea cererii.

Salvați foaia de lucru cu descrierea sarcinii de lucru, momentul eșantionării, unitățile și data următoarei revizuiri. Reverificați după o lansare substanțială, o creștere a datelor sau un worker adăugat. Alegeți o configurație din acele observații; niciun nume de plan nu garantează capacitatea de cereri. Continuați cu citirea avertismentelor de memorie și disc sau primul scenariu de resursă API.