Ograniczanie użycia procesora i pamięci przez polecenia za pomocą grup dyskusyjnych Ubuntu

Jeśli jedno polecenie spowalnia pulpit Ubuntu lub powoduje, że serwerowi brakuje pamięci, umieść je wraz z procesami potomnymi w zarządzanej przez systemd grupie cgroup z limitem procesora i pamięci. W obecnych wersjach Ubuntu systemd-run --scopejest to najkrótsze praktyczne rozwiązanie: polecenie jest uruchamiane w zakresie tymczasowym, a systemd stosuje limity za pośrednictwem kontrolek grupy cgroup.

Poniższy przykład ogranicza obciążenie do połowy wydajności jednego procesora i 1 GB pamięci. Są to limity dla całego zakresu, w tym procesów potomnych; nie stanowią one gwarancji, że program będzie działał z określoną szybkością.

Dlaczego proces potrzebuje limitu cgroup

Proces o dużym obciążeniu pamięci może konkurować z aplikacjami interaktywnymi, podczas gdy proces o dużym zapotrzebowaniu na pamięć może zmusić maszynę do odzyskiwania lub do stanu braku pamięci. Grupa cgroup grupuje proces z jego potomkami, dzięki czemu jądro może uwzględnić i ograniczyć tę grupę. Systemd w Ubuntu zapewnia wygodny interfejs do tych funkcji.

Ustawienia procesora i pamięci działają inaczej. CPUQuota=50%Limituje czas procesora do połowy wydajności jednego procesora, uśredniając go w okresie planowania. Wartość 200%reprezentuje czas maksymalnie dwóch procesorów, gdy jest dostępny. Jest to pułap, a nie priorytet procesora ani rezerwacja. MemoryMax=1GUstawia sztywny limit pamięci obciążającej grupę cgroup; jeśli obciążenie nie może utrzymać się poniżej tego limitu, jądro może odzyskać pamięć lub wywołać zamknięcie procesu z powodu braku pamięci w tej grupie cgroup. Wybierz limit z zapasem dla aplikacji i jej procesów potomnych.

1. Sprawdź, czy Ubuntu używa cgroup v2

Systemy Ubuntu korzystające z systemd zazwyczaj korzystają z ujednoliconej hierarchii cgroup v2. Sprawdź aktywną konfigurację, zanim skorzystasz ze ścieżek pokazanych poniżej:

stat -fc %T /sys/fs/cgroup
systemctl --version | head -n 1

Pierwsze polecenie powinno zwrócić cgroup2fs. Jeśli zgłosi inny typ systemu plików, ścieżki plików cgroup v2 z tego artykułu nie mają zastosowania w takiej postaci, w jakiej zostały napisane. Właściwości systemd mogą być nadal obsługiwane w innej hierarchii, ale należy użyć odpowiedniej dokumentacji dystrybucji zamiast kopiować ścieżki v2.

Sprawdź również dokładną wersję systemd, jeśli właściwość zostanie odrzucona. Dokumentacja Noble w Ubuntu opisuje CPUQuota=i MemoryMax=jako ustawienia kontroli zasobów; starsze wersje Ubuntu mogą zawierać inne wersje systemd.

2. Rozpocznij obciążenie pracą w ograniczonym zakresie

Uruchom program przez systemd-run, podstawiając jego rzeczywisty plik wykonywalny i argumenty. W przypadku polecenia w bieżącym katalogu użyj ./i przekaż wszystkie argumenty po --:

systemd-run --scope \
  -p CPUQuota=50% \
  -p MemoryMax=1G \
  -- ./my-program --input data.csv

W przypadku polecenia należącego do użytkownika, wypróbuj tę opcję bez sudowcześniejszego uruchomienia. Jeśli systemd zgłosi, że żądany kontroler lub właściwość są niedostępne, menedżer użytkowników może nie mieć uprawnień do ich delegowania; ponowienie próby jako użytkownik root może być właściwe w przypadku obciążenia całego systemu, ale zmienia kontekst bezpieczeństwa polecenia. Nie uruchamiaj przypadkowo niezaufanego programu jako użytkownik root. Jeśli wymagane jest użycie menedżera systemu jako użytkownik root, użyj tej opcji sudo systemd-run --scope ...dopiero po uwzględnieniu tej zmiany.

Terminal pozostaje podłączony do zakresu podczas wykonywania polecenia. Naciśnięcie Ctrl+Cprzerywa działanie na pierwszym planie. Zakres jest przejściowy i zazwyczaj znika po zakończeniu procesu. Jest to wygodny sposób na uruchomienie polecenia z ograniczeniami, a nie stała polityka na potrzeby przyszłych uruchomień.

3. Znajdź zakres i sprawdź jego ograniczenia

systemd-runWyświetla nazwę utworzonej jednostki, zazwyczaj coś w stylu run-….scope. Podczas działania polecenia wyświetl drzewo cgroup:

systemd-cgls

Znajdź zakres przejściowy i upewnij się, że program docelowy i jego podrzędne znajdują się pod nim. To ważne, ponieważ program podrzędny działający poza zakresem nie będzie objęty tym samym pułapem cgroup.

Użyj wydrukowanej nazwy zakresu w następnym poleceniu. Zastąp ją run-abc.scoperzeczywistą nazwą:

systemctl show run-abc.scope \
  -p ControlGroup -p CPUQuotaPerSecUSec -p MemoryMax

CPUQuotaPerSecUSec=50000jest zgodny z limitem 50%, gdy okres limitu systemd wynosi 100 ms; MemoryMax=1073741824wynosi 1 GiB w bajtach. Wartości bieżące są bardziej przydatne niż założenie, że każdy host zaakceptuje każde żądanie bez zmian, ponieważ nadrzędne grupy cgroups i dostępne kontrolery mogą ograniczać efektywny wynik.

4. Zweryfikuj pliki cgroup jądra i dostosuj je bezpiecznie

Właściwość ControlGrouppodaje ścieżkę cgroup względem /sys/fs/cgroup. Zapisz ją w zmiennej powłoki, aby polecenia podążały ścieżką faktycznie przypisaną na Twoim komputerze:

UNIT=run-abc.scope
CG=$(systemctl show "$UNIT" -p ControlGroup --value)
printf 'Group: %s\n' "$CG"
cat "/sys/fs/cgroup$CG/cpu.max"
cat "/sys/fs/cgroup$CG/memory.max"

W cgroup v2 cpu.maxzawiera kwotę i okres w mikrosekundach. Na przykład 50000 100000oznacza 50 ms czasu procesora w każdym okresie 100 ms. memory.maxPokazuje limit pamięci w bajtach. Jeśli brakuje plików, sprawdź, czy zakres jest nadal aktywny i czy jądro używa cgroup v2.

Jeśli uruchomiłeś nazwaną, długo działającą jednostkę i musisz dostosować jej limity, systemd obsługuje zmianę właściwości zasobów w aktywnej jednostce, na przykład sudo systemctl set-property --runtime my-worker.service CPUQuota=50% MemoryMax=1G. Dotyczy to grupy cgroup tej usługi i wymaga odpowiednich uprawnień. Systemd nie dołącza żadnego, już uruchomionego procesu tylko dlatego, że znany jest jego PID; w przypadku jednorazowego procesu należy go zatrzymać i ponownie uruchomić w ograniczonym zakresie. W przypadku usługi trwałej należy skonfigurować właściwości w jednostce usługi lub w module systemd i uruchomić go ponownie w odpowiednim oknie konserwacji.

Sprawdź wynik

Utrzymuj obciążenie aktywne podczas jego inspekcji. Upewnij się, że systemd-cglsumieszcza proces i jego elementy podrzędne w zamierzonym zakresie, systemctl showraportuje żądane właściwości oraz że odpowiednie pliki cpu.maxi memory.maxistnieją ze skończonymi wartościami. Po zakończeniu procesu zakres przejściowy jest usuwany, więc jego pliki cgroup mogą zniknąć.

Limit ogranicza czas procesora, ale nie gwarantuje stałego procentu na monitorze komputera stacjonarnego, a sztywny limit pamięci może powodować awarie, jeśli aplikacja potrzebuje więcej niż wynosi limit. Jeśli obciążenie stanie się niestabilne, należy je zatrzymać i zwiększyć limit do zmierzonej, bezpiecznej wartości lub użyć łagodniejszego MemoryHigh=progu obciążenia wraz z wyższym MemoryMax=. Aby uzyskać dokładne informacje na temat działania, zapoznaj się z zainstalowaną dokumentacją systemd i jądra; wiarygodne źródła to podręcznik Ubuntu systemd-run , podręcznik Ubuntu systemd resource-control oraz dokumentacja Linux kernel cgroup v2 .