Przejdź do treści 
Za pomocą narzędzia systemd resource precyzyjnie zarządzam zasobami procesora, pamięci RAM, operacji we/wy oraz identyfikatorami PID dla usług w systemie Linux, co pozwala mi zapewnić przewidywalność działania usług produkcyjnych. Poniższe kroki pokazują w praktyczny sposób, jak ustawiam limity w jednostkach i segmentach, opieram się na cgroups v2 oraz łagodzę konflikty zasobów za pomocą jasnych reguł; dzięki temu każda Instancja przewidywalny.
Punkty centralne
Poniższy przegląd zawiera najważniejsze tezy, które szczegółowo omawiam w artykule; służy on jako szybki Przewodnik.
- cgroups v2 jako jednolita hierarchia z systemd jako centralnym menedżerem
- Typy jednostek Celowe łączenie usług, zakresu i segmentów
- CPUQuota oraz CPUWeight w celu sprawiedliwego podziału obciążenia procesora
- MemoryMax oraz MemoryHigh przeciwko OOM i dławieniu przepustowości
- Plasterki dotyczące limitów grupowych i priorytetów w pracy serwera
Dlaczego systemd i cgroups v2 współpracują ze sobą
Organizuję wszystkie procesy w cgroups v2 i korzystam z systemd jako Centrum sterowania. Jednolita hierarchia w katalogu /sys/fs/cgroup w przejrzysty sposób grupuje kontrolery, takie jak cpu, memory, io i pids. Każda jednostka otrzymuje własną grupę cgroup, co pozwala mi spójnie stosować limity do całej rodziny usług. Struktura ta zapobiega omijaniu limitów przez poszczególne identyfikatory PID, ponieważ liczy się grupa jako całość. Od wersji 232 systemd zarządza tą hierarchią na wyłączność i zapisuje limity w interfejsach jądra; delegację zezwalam tylko świadomie, aby nic nie ominęło kontroli. W ten sposób utrzymuję moją Zasoby można nim sterować w dowolnym momencie.
Zrozumienie typów jednostek: Service, Scope, Slice
Zamykam klasyczne demony w Serwis-Jednostki i grupuję procesy uruchomione zewnętrznie w zakresach. W celu utworzenia hierarchii tworzę segmenty, które jako węzły wewnętrzne definiują zasoby dla całych grup. Usługi i zakresy stanowią liście, które dziedziczą limity z danego segmentu. W ten sposób rozdzielam budżety procesora, pamięci i operacji wejścia/wyjścia wzdłuż drzewa, zamiast traktować każdą usługę osobno. Dla początkujących warto zapoznać się z Efektywne zarządzanie usługami hostingowymi, aby zrozumieć rolę jednostek w działaniu serwera i stworzyć własne Plasterki zaplanować.
Sprawdź warunki wstępne: spójna hierarchia i kontroler
Upewniam się, że system działa w trybie zunifikowanym (unified mode) i że wszystkie niezbędne kontrolery są aktywne. Rozpoznaję to po katalogu /sys/fs/cgroup (punkt montowania) oraz po tym, że systemd zarządza strukturą drzewa. Jeśli brakuje kontrolerów (np. io), sprawdzam konfigurację jądra i, w razie potrzeby, parametry rozruchowe. Szczególnie w starszych środowiskach celowo migruję z wersji v1 na v2, aby opisane dyrektywy, takie jak IOWeight, MemoryHigh czy AllowedCPUs, działały prawidłowo. Dopiero gdy rozliczanie zasobów i kontrolery zaczną działać, warto zająć się precyzyjnym dostosowywaniem wag i limitów.
Kontrola procesora: prawidłowe wykorzystanie funkcji CPUWeight i CPUQuota
Steruję udziałami procesora za pomocą CPUQuota oraz względne priorytety za pomocą CPUWeight. Limit 50% ogranicza usługę do połowy czasu procesora, natomiast waga 200 zapewnia jej pierwszeństwo przed usługami o mniejszych wagach. W ten sposób reguluję zadania o stałym obciążeniu, nie spowalniając przy tym usług interaktywnych. W praktyce zaczynam od umiarkowanych limitów, obserwuję opóźnienia i zwiększam wagę ważniejszych usług. W ten sposób rozdzielam czas obliczeniowy według ważności, a nie według losowego obciążenia.
Afinity procesora, AllowedCPUs i okresy przydziału
Jeśli chcę na stałe przyporządkować rdzenie, korzystam z funkcji CPUAffinity lub bardziej precyzyjnej kontroli za pomocą cpuset poprzez parametr AllowedCPUs. W ten sposób oddzielam np. obciążenia wsadowe od usług wrażliwych na opóźnienia, przypisując je do oddzielnych rdzeni. W przypadku obciążeń impulsowych dostosowuję wartość CPUQuotaPeriodSec: dłuższy okres pozwala na większe, krótkotrwałe odchylenia w ramach tej samej średniej kwoty, co poprawia opóźnienie P99 w przypadku usług o gwałtownych skokach obciążenia.
[Usługa]
Wybór rdzeni # (sched_affinity) a cpuset (cgroup v2)
CPUAffinity=0 1 2 3
AllowedCPUs=0-3
# 150% Całkowity czas przy okresie 200 ms (większy margines dla obciążeń szczytowych)
CPUQuota=150%
CPUQuotaPeriodSec=200 ms
# Względna waga w tym samym segmencie
CPUWeight=200
Limity pamięci za pomocą MemoryMax, MemoryHigh, MemoryLow
Wyznaczam ścisły limit, stosując MemoryMax, aby uniknąć sytuacji OOM spowodowanych wartościami odstającymi. Dzięki ustawieniu MemoryHigh ograniczam dostęp do pamięci jeszcze przed osiągnięciem maksymalnego limitu, co zwiększa ogólną stabilność. MemoryLow i MemoryMin zapewniają usługom strefy ochronne, dzięki czemu jądro najpierw odzyskuje pamięć z innych grup. Takie rozłożenie zapobiega efektom kaskadowym, gdy kilka usług rośnie jednocześnie. Osoby poszukujące informacji na temat kontrolera znajdą je na stronie Wyjaśnienie działania kontrolera pamięci przejrzyste wprowadzenie do powiązanych Mechanizmy.
Świadome określenie strategii swapowania i zachowania w przypadku wyczerpania pamięci (OOM)
Jasno określam, czy i w jakim stopniu dana jednostka może korzystać z pamięci wymiany. Za pomocą MemorySwapMax ustalam górny limit łącznego wykorzystania pamięci RAM i pamięci wymiany. W przypadku usług, dla których opóźnienia mają kluczowe znaczenie, często znacznie ograniczam wykorzystanie pamięci wymiany lub całkowicie ją wyłączam, aby uniknąć wyrzucania stron. Ponadto za pomocą parametru OOMScoreAdjust wpływam na prawdopodobieństwo, z jakim jądro kończy poszczególne procesy, a za pomocą OOMPolicy określam, w jaki sposób systemd reaguje na sytuację OOM w jednostce (np. zatrzymuje całą jednostkę lub pozwala jej dalej działać).
[Serwis]
# Maksymalnie 2G wraz z pamięcią wymiany; sztywnym limitem pamięci RAM pozostaje MemoryMax
MemoryMax=1.5G
MemorySwapMax=2G
# Priorytet decyzji OOM (im mniejsza wartość, tym większa ochrona)
OOMScoreAdjust=-500
# Reakcja w przypadku uruchomienia mechanizmu OOM-Killer w ramach jednostki
OOMPolicy=stop
Dzięki tej kombinacji zapobiegam niekontrolowanym zamianom, zapewniam zdefiniowane scenariusze przełączania awaryjnego oraz niezawodnie utrzymuję bazy danych i pamięci podręczne w pamięci operacyjnej pod jednym, przewidywalnym parasolem.
Limity wejść/wyjść i procesów: IOWeight, szerokości pasma i TasksMax
Ograniczam prędkość odczytu i zapisu za pomocą IOReadBandwidthMax oraz IOWriteBandwidthMax w przypadku współdzielenia dysków. Do ustalania względnych priorytetów używam IOWeight, dzięki czemu kluczowe obciążenia mają pierwszeństwo przed strumieniami wsadowymi. Za pomocą TasksMax ustalam wyraźny limit dla procesów i wątków, co skutecznie powstrzymuje ataki typu „fork bomb”. Te mechanizmy stabilizują środowiska wieloserwerowe, w których pojedyncze zadania mogłyby w przeciwnym razie zdominować całe operacje wejścia/wyjścia. Szczególnie w przypadku serwerów kompilacji zapewniam w ten sposób powtarzalne Przepustowość od.
Precyzyjne sterowanie wejściami i wyjściami poszczególnych urządzeń
W zróżnicowanych konfiguracjach z dyskami NVMe i HDD dostosowuję ustawienia dla każdego urządzenia z osobna. Zapobiega to spowolnieniu szybkich dysków SSD przez głośny dysk HDD w sąsiedztwie. Połączenie wag względnych i limitów bezwzględnych dla poszczególnych urządzeń pozwala uwzględnić większość praktycznych przypadków.
[Usługa]
# Waga względna dla wszystkich urządzeń
IOWeight=300
# Waga na urządzenie (np. priorytet dla NVMe)
IODeviceWeight=/dev/nvme0n1 500
IODeviceWeight=/dev/sda 100
# Absolutna przepustowość maksymalna na urządzenie (szybkość odczytu/zapisu)
IOReadBandwidthMax=/dev/sda 50M
IOWriteBandwidthMax=/dev/sda 30M
Ważne: IOWeight działa tylko relatywnie między aktywnymi grupami cgroup; dyrektywy „Max“ ustalają sztywne limity. Często zaczynam od wag i dodaję sztywne limity tylko tam, gdzie muszę na pewno wyeliminować „hałaśliwych sąsiadów”.
Konfiguracja: pliki jednostek, moduły typu „drop-in” i set-property
Wpisuję limity bezpośrednio do Jednostka-plik lub korzystam z plików typu „drop-in”, które nie zmieniają oryginalnych plików. Za pomocą polecenia `systemctl edit NAME.service` tworzę fragment, który uzupełnia dyrektywy `CPUQuota`, `CPUWeight`, `MemoryMax` i inne. Do szybkich testów używam polecenia `systemctl set-property`; systemd poprawnie zapisuje zmianę w pliku typu „drop-in”. Po wprowadzeniu zmian ponownie ładuję demony i sprawdzam ich status, aby zweryfikować efekt. Taki sposób pracy pozwala uniknąć konfliktów podczas aktualizacji i zapewnia, że każda Poprawka o jasnej historii.
Priorytety typu „drop-in”, ustawienia wstępne i wartości domyślne
Zwracam uwagę na kolejność plików drop-in: systemd ładuje je w porządku numerycznym; plik 90-override.conf nadpisuje np. wcześniejsze pliki 10-*.conf. Nie modyfikuję ustawień domyślnych dostawców; nadpisuję je w katalogu /etc, aby aktualizacje pakietów nie miały krytycznego wpływu. Ustawienia domyślne dla całego systemu, takie jak DefaultTasksMax, DefaultCPUAccounting czy DefaultMemoryAccounting, celowo umieszczam w pliku systemd.conf, aby zapewnić spójne wskaźniki i zabezpieczenia również dla nowych jednostek.
# Sprawdzanie aktualnych wartości
systemctl show NAME.service -p CPUQuota -p CPUWeight -p MemoryMax
systemd-analyze dump | grep -E "Default(TasksMax|CPUAccounting|MemoryAccounting)"
# Otwarcie/utworzenie trwałego pliku nadpisującego
systemctl edit NAME.service
Slices w praktyce: rozsądne ograniczanie grup
Grupuję powiązane usługi w osobnych Plasterki, na przykład web.slice, db.slice i batch.slice. W batch.slice zezwalam na przykład na 200% procesora i 4G pamięci RAM, aby zadania działające w tle miały wystarczającą przestrzeń bez wyparcia aplikacji front-endowych. Usługi przypisuję do ich docelowych segmentów za pomocą opcji `Slice=`; limity obowiązują wówczas wspólnie dla wszystkich członków. Takie grupowanie znacznie upraszcza zasady: nowy projekt zespołowy automatycznie przejmuje zasady swojego segmentu. W przypadku izolowanych grup klientów lub aplikacji pomocne jest również spojrzenie na Izolacja cgroups, aby rozdzielenie przebiegło sprawnie Plan.
Standardowe segmenty: system.slice, user.slice, machine.slice
Pozostawiam usługi systemowe w system.slice i ustalam tam globalne limity tylko ostrożnie, aby niezbędne usługi nie zostały pozbawione zasobów. Procesy użytkowników trafiają do user.slice, gdzie ograniczam sesje interaktywne bez całkowitego blokowania powłok. Wirtualizacje i kontenery łączę w machine.slice i przypisuję jasne limity na każdą maszynę wirtualną lub kontener. Ta standardowa struktura zapewnia porządek i oferuje sensowne punkty odniesienia dla własnych segmentów. Kto prawidłowo dziedziczy, oszczędza sobie wielu pojedynczych reguł i utrzymuje Przejrzystość wysoki.
Delegowanie dla kontenerów i obciążeń dynamicznych
Kiedy przekazuję poddrzewa do środowisk uruchomieniowych kontenerów lub narzędzi sterowanych przez użytkownika, celowo ustawiam opcję `Delegate=yes` i to wyłącznie w miejscach, gdzie konieczna jest kontrola. W ten sposób nadrzędność pozostaje po stronie systemd, podczas gdy odbiorca delegacji może tworzyć własne grupy cgroup w obrębie swojego poddrzewa. W połączeniu z zakresami (Scopes) mogę sprawnie gromadzić, ograniczać i ponownie zwalniać procesy krótkotrwałe (np. zadania CI), nie rozmywając przy tym segmentów (slices).
[Usługa]
# Zezwala na sterowanie poddrzewem cgroup (np. przez środowisko uruchomieniowe kontenera)
Delegate=yes
Slice=machine.slice
MemoryMax=4G
CPUWeight=300
Monitorowanie i diagnostyka: Status, cgtop, cgls
Najpierw sprawdzam za pomocą systemctl status NAME.service, aby sprawdzić, które limity są aktywne i jak działa usługa. Dzięki narzędziu systemd-cgtop mogę na bieżąco obserwować zużycie procesora i pamięci dla poszczególnych grup cgroup. Narzędzie systemd-cgls pokazuje strukturę drzewa i uwidacznia dziedziczenie. W przypadku nieprawidłowości przeglądam pliki w katalogu /sys/fs/cgroup, aby zweryfikować ustawione wartości kontrolerów. Następnie stopniowo dostosowuję limity, obserwuję wskaźniki i dokumentuję każdą Poprawka.
Pogłębienie monitoringu: księgowość, PSI i szybkie testy
Aby uzyskać miarodajne wskaźniki, włączam funkcje CPUAccounting, MemoryAccounting i IOAccounting na poszczególnych jednostkach lub domyślnie. Dodatkowo obserwuję szczyty obciążenia na podstawie informacji o ciśnieniu (PSI) w jądrze, aby wykryć, czy nasilają się ograniczenia (memory.high) lub czy zasoby wejścia/wyjścia są stale niewystarczające. Aby zapewnić powtarzalność testów, uruchamiam obciążenia z systemd-run jako zakresem i tymczasowo przypisuję limity, zanim przeniosę je do trwałego rozwiązania typu „drop-in”.
# Zakres tymczasowy z wagami I/O i CPU
systemd-run --scope -p IOWeight=400 -p CPUWeight=300 --unit test-batch -- dd if=/dev/zero of=/tmp/out bs=1M count=1024
Włączenie rozliczania # w istniejącej jednostce
systemctl set-property NAME.service CPUAccounting=yes MemoryAccounting=yes IOAccounting=yes
Rozwiązywanie problemów i typowe przeszkody
- Harsh Caps kontra Burst: zbyt wąski limit CPUQuota bez odpowiednio dostosowanego okresu powoduje zacinanie się. Zwiększam wartość CPUQuotaPeriodSec lub obniżam limit tylko umiarkowanie i w większym stopniu korzystam z CPUWeight.
- Ogranicznik pamięci zadziałał zbyt wcześnie: czy wartość MemoryHigh została ustawiona zbyt nisko? Podniosę ją lub zdefiniuję MemoryLow, aby ścieżki krytyczne nie były odzyskiwane zbyt agresywnie.
- Urządzenia wejścia/wyjścia mają nieprawidłowe adresy: dyrektywy IO* oczekują urządzeń blokowych. Sprawdzam ścieżkę do urządzenia za pomocą polecenia lsblk i ustalam reguły dla poszczególnych urządzeń, a nie dla punktów montowania.
- Liczba wątków osiąga limit: zbyt niska wartość TasksMax spowalnia pule pracowników. Dostosowuję wymiarowanie na podstawie szczytowej liczby wątków z uwzględnieniem rezerwy i monitoruję kolumnę „Tasks” za pomocą narzędzia systemd-cgtop.
- Bezskuteczne aktualizacje: Po wprowadzeniu zmian uruchamiam polecenie `systemctl daemon-reload` i sprawdzam za pomocą `systemctl show`, czy właściwości zostały rzeczywiście ustawione.
Najlepsze praktyki dotyczące priorytetów i granic
Grupuję usługi według roli, przypisuję wartości CPUWeight i IOWeight w zależności od ważności oraz ustalam sztywne limity pamięci za pomocą MemoryMax. Krytyczne bazy danych otrzymują wysoką wagę i mniej rygorystyczne limity, podczas gdy raporty i zadania wsadowe podlegają większym ograniczeniom. Ustawiam TasksMax, gdy aplikacje wykorzystują wiele procesów roboczych lub istnieje ryzyko „eksplozji wątków”. Każda zmiana trafia do repozytorium z oznaczeniem wersji, dzięki czemu mogę ją prześledzić i w razie potrzeby cofnąć. W środowisku stagingowym dostosowuję wartości do profili obciążenia, a następnie ostrożnie przenoszę je do Produkcja.
Przegląd najważniejszych dyrektyw w formie tabeli
Ta zwięzła tabela zawiera typowe ustawienia i pomaga mi dobrać odpowiednie Wartości do wyboru.
| Cel | dyrektywa | Przykładowa wartość | Efekt |
|---|---|---|---|
| Udział procesora | CPUWeight | 200 | Zwiększa priorytet względem jednostek o mniejszej wadze; rozdziela CPU sprawiedliwie. |
| Współczynnik wykorzystania procesora | CPUQuota | 50% | Ogranicza efektywny czas pracy; idealne rozwiązanie w przypadku ciągłego obciążenia miejsca pracy. |
| Pamięć stała | MemoryMax | 1G | Limit bezwzględny; zapobiega wystąpieniu błędu OOM spowodowanego wartościami odstającymi w tej samej Slice. |
| Miękka pamięć | MemoryHigh | 800 m | Ogranicza prędkość przed Maxem; zmniejsza nacisk na System. |
| Priorytet wejścia/wyjścia | IOWeight | 500 | Preferuje usługi centralne na współdzielonych Dyski. |
| PID-y/wątki | TasksMax | 512 | Ogranicza liczbę procesów/wątków; chroni przed Forks-Lawiny. |
Przykłady zastosowań w dziedzinie hostingu i obsługi serwerów
Tworzę dla klientów własne Plasterki i przypisuję budżety procesora i pamięci RAM dla każdego klienta. W konfiguracjach opartych na mikrousługach usługi API i uwierzytelniania otrzymują wyższe priorytety, podczas gdy raportowanie działa asynchronicznie. Dla programów CI/CD tworzę segment partii, aby kompilacje nigdy nie wypierały interfejsów użytkownika. W środowiskach kontenerowych i maszyn wirtualnych izoluję obciążenia w pliku machine.slice i jasno rozdzielam budżety dla poszczególnych klientów. Taki podział ogranicza efekt „hałaśliwego sąsiada” i zapewnia powtarzalność Opóźnienia w godzinach szczytu.
Podsumowanie
Steruję usługami systemu Linux za pomocą systemd i cgroups v2 Jednostka zamiast skupiać się na pojedynczych procesach. CPUQuota, CPUWeight, MemoryMax, MemoryHigh, IOWeight i TasksMax stanowią mój podstawowy zestaw narzędzi zapewniających sprawiedliwy podział zasobów i jasno określone limity. Slices wprowadzają porządek, grupują wytyczne oraz ułatwiają eksploatację i wdrażanie nowych usług. Monitorowanie za pomocą poleceń systemctl status, cgtop i cgls pozwala wcześnie wykryć, gdzie konieczne są korekty. Dzięki temu wydajność i dostępność pozostają przewidywalne, a konflikty zasobów ograniczam do Kontrola.
