Przeczytaj ostrzeżenia o pamięci i dysku przed aktualizacją.

Uchwyć małą wartość bazową z kontekstem

Użyj konta Linux uprawnionego do sprawdzenia aplikacji, którą zarządzasz. Polecenia tutaj sprawdzają stan; nie usuwają plików ani nie zmieniają rozmiaru pamięci masowej. Niektóre katalogi i dzienniki wymagają podwyższonego dostępu. Zastąp /var/lib/field-api, /opt/field-api oraz /opt/first-api rzeczywistymi ścieżkami aplikacji i potwierdź, że te ścieżki istnieją przed interpretacją wyników.

Zapisz czas, bieżące wydanie i aktywność: zwykły ruch, przesłanie pliku, zadanie raportu lub kompilację wdrożenia. Wykonaj kolejny odczyt podczas porównywalnej aktywności. Dwa niepowiązane zrzuty ekranu mogą sprawić, że zdrowa maszyna będzie wyglądać niespójnie. Jeśli użytkownicy są już dotknięci, uchwyć pierwszą użyteczną wskazówkę z przewodnika po awariach aplikacji zanim wprowadzisz kilka zmian naraz.

Odczytaj dostępną pamięć, a następnie sprawdź obciążenie

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

W freedostępna pamięć szacuje, co można wykorzystać dla nowych aplikacji bez wymiany. Uwzględnia możliwą do odzyskania pamięć podręczną, więc odpowiada na inne pytanie niż całkowicie niewykorzystana „wolna” pamięć. Zobacz podręcznik free upstream. Linux używa pamięci do buforowania plików; sama duża pamięć podręczna nie jest dowodem wycieku. przegląd pamięci jądra wyjaśnia, dlaczego pamięć podręczna i pamięć aplikacji współistnieją.

Odczyt ilustracyjny, nie pomiar serwera: mały host ma około 1.9 GiB użytecznej pamięci, 80 MiB wolnej i 850 MiB dostępnej. Niska wartość wolnej pamięci sama nie uzasadnia aktualizacji. Jeśli dostępna pamięć wielokrotnie spada blisko zera podczas raportu, żądania zwalniają, a pojawiają się istotne komunikaty o alokacji lub braku pamięci, te połączone dowody zasługują na zbadanie.

Ten ps polecenie wyświetla RSS procesów w KiB, od największego. RSS opisuje pamięć rezydentną, a nie pełne rozliczenie wyłącznej własności; współdzielone strony mogą pojawiać się w wielu procesach. Nie dodawaj każdej wartości RSS i nie traktuj wyniku jako dokładnego użycia hosta. odniesienie do ps upstream definiuje RSS i sortowanie. Zapisz nazwę procesu i czy jego ślad wraca do wcześniejszego poziomu po zakończeniu obciążenia.

Używany swap może odzwierciedlać wcześniejszą aktywność; sam nie dowodzi bieżącego przeciążenia. Rozróżnij też pojemność hosta od limitów usługi lub kontenera. Ograniczony proces może zawieść, gdy host ma jeszcze dostępną pamięć. Sprawdź skonfigurowany limit i czas awarii przed zwiększeniem rozmiaru VPS. Dokumentacja systemu plików proc jądra opisuje pola pamięci stojące za tymi obserwacjami.

Znajdź system plików, który faktycznie się zapełnia

df -h / /opt/first-api
df -i / /opt/first-api

Pierwsze polecenie raportuje miejsce w systemach plików zawierających te ścieżki. Drugie raportuje i-węzły, które są rekordami systemu plików potrzebnymi dla plików i katalogów. Obciążenie z wieloma małymi plikami może wyczerpać i-węzły, podczas gdy pojemność bajtowa pozostaje. Sprawdź punkt montowania i oba rodzaje pojemności, zamiast używać rozmiaru całego VPS jako jedynej liczby. Zobacz podręcznik GNU df.

Ścieżka na osobno zamontowanym wolumenie może zapełnić się niezależnie od głównego systemu plików. Odwrotnie, dwie wymienione ścieżki mogą należeć do tego samego systemu plików, więc ich dostępne miejsce nie sumuje się. Rezerwacje systemu plików, limity i warstwy pamięci masowej mogą również wpływać na to, co aplikacja może zapisać. Pojedynczy wyświetlany procent nie identyfikuje właściciela wzrostu.

Przypisz wzrost do logów, przesłanych plików lub artefaktów

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du szacuje przydzielone miejsce w każdym katalogu. Tutaj -x zapobiega przejściu do innego systemu plików, -h używa czytelnych jednostek i -d1 ogranicza wyświetlaną głębokość. Duże drzewa mogą nadal wymagać czasu i aktywności dysku do przeskanowania. Błędy uprawnień oznaczają, że widok jest niekompletny. Zobacz podręcznik GNU du. Polecenie dziennika raportuje pamięć dziennika, w tym aktywne i zarchiwizowane pliki, zgodnie z dokumentacją journalctl.

Porównaj największe katalogi z ich przeznaczeniem:

• Logi: czy powtarzający się błąd zwiększył objętość i czy skonfigurowano rotację?
• Przesłane pliki: czy zachowane pliki użytkowników rosną zgodnie z oczekiwaniami i czy uwzględniono porzucone częściowe przesłania?
• Artefakty wydania: czy stare kompilacje gromadzą się poza polityką wycofywania?
• Pliki bazy danych: czy własne narzędzia bazy danych wyjaśniają wzrost i potrzeby konserwacji?

Nie usuwaj nieznanego katalogu bazy danych ani nie używaj szerokiego czyszczenia wolumenu kontenera jako kroku badawczego. Najpierw ustal własność, wymagania dotyczące przechowywania i odzyskiwalną kopię. Jeśli df a sumy katalogów znacznie się różnią, sprawdź granice montowania, błędy dostępu i pliki nadal otwarte po usunięciu z doświadczonym operatorem; wielokrotne usuwanie widocznych plików może nie objąć zajętego miejsca.

Przekształć odczyty w konkretne następne działanie

Przykład ilustracyjny: dostępna pamięć pozostaje komfortowa, ale katalog przesłanych plików rośnie o około 400 MiB w każdym z dwóch obserwowanych dni. System plików ma około 2 GiB dostępnego miejsca. Podzielenie pozostałego miejsca przez ten krótkoterminowy wzrost sugeruje tylko około pięciu dni przy tym samym tempie, przed uwzględnieniem zapasu operacyjnego. To szacunek planistyczny, a nie prognoza ani bezpieczny termin oczekiwania; przesłane pliki i prace tymczasowe mogą pojawiać się nierównomiernie.

Następnym działaniem jest sprawdzenie przechowywania przesłanych plików i oczekiwanego popytu, zaplanowanie dodatkowej pamięci masowej, jeśli jest to uzasadnione, oraz ustawienie alertu wystarczająco wcześnie, aby działać. Więcej RAM nie rozwiązałoby tego problemu. W innym przypadku kompilacja wdrożenia może tworzyć krótki szczyt pamięci, gdy obsługa pozostaje mała; przeniesienie kompilacji poza VPS mogłoby być bardziej użyteczne niż trwałe powiększanie środowiska uruchomieniowego.

Po uzasadnionej zmianie powtórz te same odczyty i jedno działanie aplikacji. Potwierdź, że miejsce jest faktycznie dostępne, a zamierzone dane nadal działają. Utrzymuj usuwanie i zmianę rozmiaru jako zaplanowane operacje z krokami odzyskiwania, a nie automatyczne reakcje na czerwony wskaźnik. Użyj przewodnika po budżecie zasobów , aby przekształcić wykazaną potrzebę w wybory konfiguracyjne, i przećwicz przywracanie przed poleganiem na czyszczeniu lub migracji.