Wybierz pamięć dla systemu operacyjnego, usług trwałych i realistycznej współbieżności z zapasem. Wybierz CPU po zmierzeniu, które zadania są zajęte, czy działają równolegle i jakich opóźnień faktycznie doświadczają użytkownicy.
Opisz osobno normalną pracę i pracę w szczycie
Sama liczba odwiedzających to słabe dane wejściowe do doboru rozmiaru. Jedno żądanie może obsłużyć plik z pamięci podręcznej, a inne wygenerować raport lub odpytać wiele tabel. Wymień procesy robocze web, bazę danych, pamięć podręczną, konsumentów kolejek i zadania konserwacyjne, które będą współdzielić VPS. Opisz normalną współbieżność i najcięższą oczekiwaną operację. Uwzględnij zaplanowane eksporty, aktualizacje pakietów i wdrożenia, zamiast traktować je jako niewidoczną aktywność w tle.
W przypadku istniejącego projektu zbierz reprezentatywny okres obejmujący okno szczytu. Zapisuj czasy odpowiedzi i błędy wraz z użyciem zasobów. W przypadku nowego projektu utwórz mały test z realistycznymi kształtami żądań i rozmiarami danych. Twoje wstępne oszacowanie będzie niedoskonałe; użytecznym celem jest udokumentowany punkt wyjścia, który możesz porównać ze zmierzonym zachowaniem po wdrożeniu.
Zbuduj budżet pamięci przed dodaniem procesów
Zapotrzebowanie na pamięć wynika z systemu, trwałych usług aplikacji, użycia na proces roboczy i operacji tymczasowych. Pomnożenie śladu procesu roboczego przez planowaną współbieżność to przybliżone narzędzie planistyczne, a nie gwarancja, ponieważ pamięć współdzielona i pamięci podręczne komplikują sumę. Obserwuj rzeczywiste procesy pod obciążeniem. Pozostaw wystarczająco dużo miejsca, aby zadanie konserwacyjne nie zmuszało aplikacji do konkurowania o każdą pozostałą stronę.
Ustawienia bazy danych mogą nieoczekiwanie zwielokrotnić użycie pamięci. PostgreSQL dokumentuje, że work_mem dotyczy operacji zapytań, a kilka operacji lub sesji może działać współbieżnie. Ustawienie, które w izolacji wygląda skromnie, może więc mieć większy wpływ na system. Przeczytaj własne wytyczne swojej bazy danych, przetestuj realistyczną współbieżność i unikaj przypisywania każdego reklamowanego gigabajta do jednej pamięci podręcznej.
Rozróżnij wykorzystanie CPU od użytecznego równoległości
Liczba procesorów mówi, ile zasobów wykonawczych jest prezentowanych gościowi, a nie jak efektywnie Twoje oprogramowanie może z nich korzystać. Jeden zajęty wątek może ograniczać aplikację, podczas gdy inne rdzenie pozostają bezczynne. Dodanie procesów roboczych może pomóc niezależnym żądaniom, ale może też zwiększyć rywalizację o bazę danych i zapotrzebowanie na pamięć. Sprawdź model współbieżności aplikacji, zanim założysz, że dwukrotność liczby rdzeni daje dwukrotność przepustowości.
KVM zapewnia maszynom wirtualnym własny sprzęt wirtualny. Nie zamienia jednak każdej etykiety vCPU w identyczny benchmark na różnych hostach i generacjach procesorów. Porównaj wymieniony model CPU i warunki alokacji, jeśli są dostępne, a następnie oceń usługę na własnym obciążeniu. Unikaj wyciągania wniosku zakupowego z krótkiego syntetycznego wyniku, który nie przypomina aplikacji.
Szukaj presji i oczekiwania, nie tylko średnich
System może wydawać się wolny, nie utrzymując wysokiego średniego procentu CPU. Procesy mogą czekać na pamięć masową, odzyskiwanie pamięci lub inną usługę. Pressure Stall Information jądra Linux udostępnia informacje o zatorach CPU, pamięci i we/wy w obsługiwanych systemach. Te sygnały mogą pomóc zidentyfikować rywalizację o zasoby obok normalnych metryk wykorzystania i czasów aplikacji.
Czytaj metryki razem. Utrzymująca się presja pamięci, swapping, nieudane alokacje i wolne żądania wskazują na inną interwencję niż pojedynczy zajęty proces obliczeniowy. Oczekiwania pamięci masowej mogą uzasadniać zmiany zapytań lub inny profil dysku. Zewnętrzne opóźnienie API nie zostanie naprawione przez dodanie lokalnego RAM. Wyjaśnij zaobserwowane ograniczenie, zanim wybierzesz zasób do zwiększenia.
| Zaobserwowane zachowanie | Pytanie do zbadania | Możliwy następny krok |
|---|---|---|
| Jeden wątek zajęty, wolne rdzenie bezczynne | Czy ta praca może działać równolegle? | Popraw zadanie lub zmień projekt procesu roboczego |
| Presja pamięci podczas raportu | Ile operacji się nakłada? | Ogranicz współbieżność lub dodaj przetestowany zapas |
| Wolne żądania z oczekiwaniami we/wy | Które odczyty lub zapisy są opóźnione? | Zbadaj zapytania i zachowanie pamięci masowej |
| CPU i pamięć niskie, żądania wolne | Czy zależność opóźnia odpowiedzi? | Zmierz wywołania podrzędne |
Przykład planistyczny z jawnymi założeniami
Wyobraź sobie małą aplikację z dwoma procesami roboczymi web, bazą danych i jednym konsumentem kolejki. Zespół mierzy te usługi podczas zwykłych żądań i zadania generowania raportu. Odkrywa, że dopuszczenie czterech raportów naraz gwałtownie zwiększa zapotrzebowanie na pamięć, opóźniając normalny ruch. Zamiast natychmiast kupować największy plan, ogranicza współbieżność raportów i ponownie mierzy wynik.
Jeśli dostosowane obciążenie nadal wymaga więcej pamięci, aktualizacja odpowiada teraz zaobserwowanemu wymaganiu. Jeśli kolejka pozostaje ograniczona przez CPU, a niezależne zadania mogą działać współbieżnie, więcej zasobów wykonawczych może być właściwe. To przykładowe decyzje, a nie dane wydajnościowe planów SwissOctet. Zachowaj własne pomiary i ograniczenia wraz z wybraną konfiguracją.
Pozostaw wyraźną ścieżkę do następnego pomiaru
Zdefiniuj sygnały, które wywołają przegląd: pogorszenie czasu odpowiedzi, powtarzająca się presja pamięci, rosnące kolejki lub zmienione obciążenie. Utrzymuj monitorowanie na tyle lekkie, aby nie stało się nowym wąskim gardłem. Oceń ponownie po dodaniu funkcji lub dużego zbioru danych i unikaj powtarzanych aktualizacji, gdy prawdziwym problemem jest nieograniczony proces lub wolne zapytanie.
Rodziny SwissOctet VPS udostępniają specyfikacje CPU i pamięci oraz wybrane opcje zasobów. Przeczytaj ostateczną konfigurację po dodaniu dodatków, w tym okres rozliczeniowy i sumę. Potwierdź warunki aktualizacji u działającego operatora, zanim na nich polegniesz. Użyteczny rozmiar VPS to taki, który obsługuje zmierzone obciążenie z rozsądnym zapasem i zrozumiałym następnym krokiem.
Twoja praktyczna lista kontrolna.
- Zinwentaryzuj usługi i prace konserwacyjne.
- Zmierz współbieżność w normalnym okresie i w szczycie.
- Zaplanuj budżet pamięci trwałej i tymczasowej.
- Sprawdź, czy praca CPU może działać równolegle.
- Porównaj presję, wykorzystanie i czasy aplikacji.
- Zdefiniuj, kiedy przeglądać konfigurację.
Szczegóły, które mają znaczenie.
Czy powinienem dobierać rozmiar VPS na podstawie miesięcznych odwiedzających?+
Użyj liczby odwiedzających jako kontekstu, a następnie zmierz złożoność żądań, współbieżność, rozmiar danych i pracę w tle. Równe liczby odwiedzających mogą tworzyć różne obciążenia.
Czy więcej RAM zawsze przyspiesza usługę?+
Nie. Pomaga, gdy pamięć jest ograniczeniem lub umożliwia użyteczne buforowanie, ale nie rozwiązuje każdego opóźnienia CPU, pamięci masowej lub zależności zewnętrznej.
Czy dwukrotność liczby vCPU podwaja wydajność?+
Nie. Równoległość, charakterystyka procesora, rywalizacja i projekt aplikacji decydują, ile dodatkowej przepustowości jest użyteczne.
Przejdź do źródła.
Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją.
- Jądro Linux: Pressure Stall Information docs.kernel.org
- PostgreSQL: Zużycie zasobów www.postgresql.org
- Projekt KVM: Kernel Virtual Machine www.linux-kvm.org
Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno.