Dobierz rozmiar do aplikacji, którą faktycznie uruchamiasz.

Zanim zaczniesz mierzyć

Użyj kontrolowanej maszyny testowej Linux, na której masz swoją aplikację i reprezentatywne dane. Poniższe polecenia sprawdzają zasoby; nie dostrajają jądra ani nie usuwają plików. Potrzebujesz procps i GNU coreutils oraz uprawnień do sprawdzenia wybranego katalogu aplikacji. Zastąp /srv/my-app jej rzeczywistą ścieżką. Jeśli aplikacja nigdzie jeszcze nie działa, użyj jej środowiska deweloperskiego lub stagingowego do zbudowania wstępnego szacunku, a następnie zweryfikuj ten szacunek w docelowym systemie.

Zapisz, co współdzieli VPS: system operacyjny, proxy, API, bazę danych, workery i monitoring. Odnotuj, czy budowanie zasobów odbywa się tam, czy kopie zapasowe są kompresowane lokalnie i czy zaplanowane zadanie może nakładać się na wdrożenie. Spokojny proces aplikacji może współistnieć z kosztownym procesem wydania.

Odczytaj dostępną pamięć i zidentyfikuj procesy

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

free -m podaje mebibajty. Skup się na available, szacunku pamięci, która mogłaby obsłużyć nową pracę bez swapowania; free sam wyklucza użyteczną pamięć podlegającą odzyskaniu. Cache nie jest więc sam w sobie powodem, by kupować więcej RAM. Zobacz definicje pól 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

Wartości RSS procesów powyżej odpowiadają w przybliżeniu 384, 180 i 32 MiB. Pomagają zlokalizować użycie pamięci, ale sumowanie wszystkich wartości RSS nie daje dokładnego wyniku dla całej maszyny: strony współdzielone mogą być liczone więcej niż raz, a niektóre koszty jądra są poza wartością procesu. Unikaj drukowania argumentów poleceń lub środowisk podczas zbierania raportu, ponieważ mogą zawierać sekrety. podręcznik ps wyjaśnia jego pola i zachowanie przy migawkach.

Zamień obserwacje w arkusz roboczy

Poniższe przydziały ilustrują małe API z lokalną bazą danych i jednym workerem. Są to wymyślone wartości planistyczne, nie benchmarki ani minimalne wymagania dla konkretnego frameworka. Zastąp je swoimi pomiarami i odnotuj, które przydziały mogą osiągać szczyt jednocześnie.

Ten arkusz roboczy już przekracza budżet 1,024 MiB. Środowisko testowe 2,048 MiB pozostawiłoby 676 MiB względem tych przydziałów, ale użytecznym wynikiem jest to, czy rzeczywista reprezentatywna praca mieści się w nim, gdy aplikacja pozostaje responsywna. Jeśli przydział wdrożeniowy dominuje, budowanie artefaktów gdzie indziej może być lepszą zmianą niż powiększanie stałego serwera. Zachowaj założenia obok sumy.

Obserwuj CPU i swap podczas użytecznej pracy

vmstat 1 10

Uruchom to podczas reprezentatywnej partii żądań, zadania i wydania. Ignoruj pierwszy wiersz przy interpretacji ostatniego interwału: podsumowuje aktywność od rozruchu. Kolejne wiersze opisują interwały próbkowania. Utrzymująca się praca gotowa do uruchomienia w r, niski czas bezczynności w id i wolne żądania razem uzasadniają zbadanie presji CPU. Powtarzająca się si/so aktywność wskazuje na swapowanie; sam przydzielony swap nie dowodzi bieżącej presji. wa oraz st wymagają kontekstu, a nie automatycznej modernizacji CPU. Te pola są zdefiniowane w vmstat.

Rejestruj także czas odpowiedzi w aplikacji. Wolne zewnętrzne API lub zapytanie do bazy danych może sprawić, że żądania czekają, podczas gdy CPU pozostaje w większości bezczynny. Powtórz to samo obciążenie po jednej zmianie, aby wiedzieć, która zmiana pomogła. Testy obciążeniowe powinny być wymierzone tylko w systemy, które kontrolujesz, z tempem i warunkiem zatrzymania, które nie zakłócą innych użytkowników.

Budżetuj wzrost dysku i transfer oddzielnie

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

df opisuje system plików zawierający ścieżkę, w tym przestrzeń współdzieloną z innymi katalogami; df -i sprawdza użycie i-węzłów tam, gdzie jest obsługiwane. Duża liczba małych plików może wyczerpać i-węzły przed pojemnością bajtową. du szacuje wybrane drzewo, z zastrzeżeniem uprawnień dostępu. To różne pytania, więc ich sumy nie muszą się zgadzać. Zobacz df oraz du.

Wymień bieżącą bazę danych, przesłane pliki, logi, artefakty aplikacji i wszelką lokalną przestrzeń stagingową kopii zapasowych. Dodaj przestrzeń potrzebną na wydanie obok poprzedniego wydania, a następnie oszacuj wzrost w następnym interwale przeglądu. Na przykład 100 MiB nowych przesłanych plików każdego dnia dodaje około 3,000 MiB przez 30 dni przed replikami lub kopiami zapasowymi. Etykietuj spójnie dziesiętne GB i binarne GiB przy porównywaniu wyniku z katalogiem.

Dla transferu ilustracyjna odpowiedź 20 kB wysłana 50,000 razy to około 1 GB ładunku odpowiedzi. Dodaj przesłane pliki, pliki statyczne, narzut protokołu i ruch kopii zapasowych. Ta arytmetyka szacuje wolumen, nie przepustowość ani jednoczesnych użytkowników. Potwierdź, jak usługa liczy ruch i obsługuje ewentualny nadmiar.

Wybierz następne działanie i sprawdź je

• Niska dostępna pamięć podczas normalnych szczytów: sprawdź głównych konsumentów i przetestuj większy budżet pamięci.
• Wolne żądania przy utrzymującej się presji CPU: profiluj zajętą ścieżkę, a następnie porównaj zmiany CPU przy tym samym obciążeniu.
• Rosnące użycie dysku: zidentyfikuj odpowiedzialny katalog i politykę retencji, zanim cokolwiek usuniesz.
• Zasoby wyglądają na wystarczające, ale aplikacja jest wolna: zbadaj zależności, zapytania i ścieżkę żądania.

Zapisz arkusz roboczy z opisem obciążenia, czasem próbkowania, jednostkami i datą następnego przeglądu. Sprawdź ponownie po znaczącym wydaniu, wzroście danych lub dodaniu workera. Wybierz konfigurację na podstawie tych obserwacji; żadna nazwa planu nie gwarantuje zdolności obsługi żądań. Kontynuuj z czytaniem ostrzeżeń o pamięci i dysku lub pierwszym scenariuszem zasobu API.