Jak ograniczyć użycie procesora i pamięci RAM przez proces za pomocą Cgroups w systemie Ubuntu

W Ubuntu najbezpieczniejszym, ogólnym sposobem ograniczenia obciążenia za pomocą cgroups jest umożliwienie systemd utworzenia i zarządzania grupą kontrolną. Użyj systemd-runjej do polecenia, które aktualnie uruchamiasz, lub skonfiguruj usługę systemd, gdy limit musi przetrwać restarty. Ustaw CPUQuota=sztywny limit czasu procesora i wybierz pomiędzy MemoryHigh=obciążeniem a MemoryMax=sztywnym limitem pamięci. Limity te dotyczą jednostki i jej procesów potomnych.

Grupa cgroup (grupa kontrolna) to mechanizm jądra Linuksa, który organizuje procesy, aby system mógł rejestrować i kontrolować wykorzystanie zasobów. Systemd w Ubuntu umieszcza usługi w grupach cgroup, więc większość użytkowników nie musi ręcznie tworzyć katalogów /sys/fs/cgroup. Poniższe przykłady wykorzystują interfejs kontroli zasobów systemd i należy je porównać z wersją systemd zainstalowaną w systemie Ubuntu.

Wybierz kontrolę odpowiadającą problemowi

W przypadku większości interaktywnych maszyn Ubuntu, zakres przejściowy jest najszybszym odwracalnym rozwiązaniem. W przypadku usługi produkcyjnej należy użyć jednostki usługi, aby polityka była dokumentowana i przywracana podczas rozruchu. Używaj plików bezpośrednich cgroup tylko wtedy, gdy celowo zarządzasz delegowaną hierarchią lub budujesz przepływ pracy kontenera/środowiska wykonawczego.

Sprawdź system Ubuntu przed ustawieniem limitów

Najpierw sprawdź, czy systemd jest dostępny i czy system plików cgroup jest zunifikowany w wersji 2:

systemctl --version
stat -fc %T /sys/fs/cgroup

Wynik cgroup2fsdrugiego polecenia wskazuje na zunifikowany system plików cgroup v2. Wersje Ubuntu i systemy niestandardowe mogą się różnić, dlatego nie należy zakładać, że każdy komputer ma tę samą hierarchię lub funkcje systemd. Można również sprawdzić bieżącą wersję systemd za pomocą pierwszego polecenia. Jeśli montowanie cgroup jest inne niż v2, niektóre właściwości zasobów lub zachowanie kontrolera mogą się różnić; przed skopiowaniem konfiguracji należy zapoznać się z podręcznikiem Ubuntu dla zainstalowanej wersji.

Wybierz wartości po zmierzeniu obciążenia. Zostaw miejsce na resztę systemu i pamiętaj, że limity ustawione dla usługi użytkownika są również ograniczone przez wszelkie limity na jej nadrzędnym segmencie. Podrzędna grupa cgroup nie może otrzymać więcej zasobów, niż pozwala jej przodek.

Ogranicz polecenie, które chcesz uruchomić

Aby uruchomić polecenie w sesji użytkownika, uruchom je w zakresie przejściowym za pomocą systemd-run --user --scope. Na przykład:

systemd-run --user --scope --unit=worker-capped \
  -p CPUQuota=50% \
  -p MemoryHigh=700M \
  -p MemoryMax=900M \
  -- python3 /opt/worker.py

Zastąp polecenie Pythona programem, który faktycznie chcesz uruchomić. Ten przykład nadaje cgroup maksymalną przepustowość procesora równą połowie jednego procesora, rozpoczyna obsługę obciążenia pamięci na poziomie około 700 MiB i ustawia maksymalną wartość pamięci stałej na 900 MiB. Wartości pamięci są oparte 100%na jednostkach bazowych systemd 1024. Kwota reprezentuje czas pracy jednego procesora; 200%może wykorzystać czas pracy dwóch procesorów, jeśli jest dostępny. Nie oznacza to procentowego udziału wszystkich rdzeni w komputerze.

Polecenie działa na pierwszym planie, ponieważ jest to zakres. Po jego zakończeniu jednostka przejściowa znika. Usuń --usertylko wtedy, gdy zamierzasz używać menedżera systemu i masz wymagane uprawnienia; w przypadku jednostki przejściowej obejmującej cały system, uruchom polecenie z parametrem sudoi użyj odpowiednich opcji polecenia. Ustawienia zasobów mogą zostać odrzucone, jeśli menedżer lub kontroler grupy cgroup ich nie obsługuje.

Ustaw limity dla trwałej usługi systemd

W przypadku usługi takiej jak worker.service, utwórz drop-in zamiast edytować plik jednostki dostawcy. Uruchom sudo systemctl edit worker.servicei dodaj:

[Service]
CPUQuota=50%
MemoryHigh=700M
MemoryMax=900M

Zapisz zmiany, a następnie ponownie załaduj definicje jednostek systemd i uruchom ponownie usługę, aby proces rozpoczął się zgodnie ze zmienioną polityką:

sudo systemctl daemon-reload
sudo systemctl restart worker.service

Należy ostrożnie określić limit pamięci. Jeśli usługa nie jest w stanie odzyskać wystarczającej ilości pamięci poniżej limitu MemoryMax, jądro może wywołać komendę „out-of-memory killer” w obrębie tej grupy cgroup. Może to zakończyć jeden lub więcej procesów w grupie usług i przerwać pracę. Bezpieczniejszym rozwiązaniem jest często ustawienie MemoryHighlimitu na poziomie, na którym odzyskiwanie i ograniczanie przepustowości są akceptowalne, a następnie ustawienie MemoryMaxwyższej granicy jako ostatecznej. Przed wdrożeniem ścisłych limitów należy przeprowadzić testy przy realistycznych obciążeniach szczytowych.

Sprawdź jednostkę i obserwuj jej zachowanie

W przypadku zakresu przejściowego sprawdź jego status, korzystając z podanej nazwy jednostki:

systemctl --user status worker-capped.scope
systemd-cgtop

W przypadku usługi systemowej należy pominąć ten parametr --userw poleceniu status. Widok statusu potwierdza istnienie i aktywność jednostki; systemd-cgtoppokazuje bieżące wykorzystanie zasobów przez grupę kontrolną. Aby sprawdzić skonfigurowane właściwości, należy bezpośrednio wysłać zapytanie do jednostki, na przykład:

systemctl --user show worker-capped.scope \
  -p CPUQuotaPerSecUSec -p MemoryHigh -p MemoryMax

Pamięć raportowana dla grupy cgroup niekoniecznie jest taka sama, jak wartość pamięci rezydentnej jednego procesu: uwzględnia ona pamięć obciążającą grupę i może obejmować potomków obciążenia. Monitorowanie należy traktować jako dowód zachowania się obciążenia w czasie, a nie jako pojedynczą wartość do optymalizacji na ślepo.

A co jeśli proces już działa?

systemd-runUruchamia nowe polecenie w nowej jednostce; nie pobiera dowolnego istniejącego PID i nie przenosi go do tego zakresu. Jeśli proces należy do usługi systemd, zastosuj ustawienia do tej usługi za pomocą polecenia drop-in lub, w przypadku tymczasowej zmiany, użyj polecenia sudo systemctl set-property --runtime worker.service CPUQuota=50% MemoryHigh=700M MemoryMax=900M. Ten --runtimeformularz jest tymczasowy i nie zastępuje trwałej konfiguracji usługi.

Jeśli proces jest zwykłym programem w sesji pulpitu, bezpieczną i prostą metodą jest zazwyczaj jego zatrzymanie i ponowne uruchomienie w [brakuje kontekstu] systemd-run. Zastosowanie właściwości do szerszego wycinka, takiego jak cały wycinek użytkownika, może mieć wpływ na wiele niepowiązanych aplikacji. Przeniesienie procesu poprzez zapisanie jego identyfikatora PID do pliku cgroup wymaga kontroli nad odpowiednią delegowaną hierarchią i musi być zgodne z zasadami rozmieszczania procesów cgroup v2; nie zapisuj do katalogów zarządzanych przez systemd na zasadzie zgadywania.

Jak wybrać politykę procesora i pamięci

• Potrzebujesz sztywnego limitu procesora? Wybierz CPUQuota=. Niższe wartości zmniejszają szczytowe zużycie procesora, ale mogą spowolnić ukończenie zadania i wydłużyć czas oczekiwania w kolejce.
• Potrzebujesz tylko niższego priorytetu? Rozważ CPUWeight=raczej limit. Waga współdzieli zasoby procesora w stosunkowo niewielkim stopniu; nie rezerwuje stałego procentu ani nie zapobiega wykorzystaniu bezczynnego procesora.
• Potrzebujesz obciążenia pamięci bez natychmiastowego, twardego zatrzymania? Ustaw MemoryHigh=główny próg obciążenia i obserwuj opóźnienie oraz zachowanie odzyskiwania.
• Potrzebujesz ostatecznej granicy ograniczającej? Dodaj ją MemoryMax=z zapasem na normalne szczyty. Przygotuj się na brak koncentracji (OOM), gdy granica nie będzie mogła zostać zachowana.
• Już korzystasz z kontenera? Wolisz flagi procesora i pamięci obsługiwane przez menedżera kontenerów, które konfigurują grupy cgroups dla danego kontenera i dopasowują się do jego cyklu życia.

Nie ma jednego idealnego limitu dla każdego obciążenia. Zadanie wsadowe na komputerze stacjonarnym może tolerować niski limit i umiarkowany limit pamięci; usługa wrażliwa na opóźnienia może wymagać większej rezerwy mocy obliczeniowej procesora i wyższej, MemoryHighaby uniknąć przerw związanych z odzyskiwaniem. Zacznij ostrożnie, monitoruj jednostkę w reprezentatywnym okresie szczytowym i dostosowuj ustawienia po kolei.

Odniesienia

• Dokumentacja Ubuntu: cgroups i kontrola zasobów systemd
• Strona podręcznika Ubuntu: systemd-run
• Strona podręcznika Ubuntu: systemd.resource-control
• Dokumentacja jądra Linux: Grupa kontrolna v2