Przejdź do treści 
Wyjaśniam, w jaki sposób cgroup v2 dzięki kontrolerowi pamięci precyzyjnie realizuje ograniczenia pamięci, chroni usługi i izoluje lokalne zdarzenia OOM. W ten sposób administratorzy ustalają jasne Zasoby-ustalają zasady, w sposób kontrolowany ograniczają szczytowe obciążenia oraz zabezpieczają krytyczne procesy przed niedoborem pamięci.
Punkty centralne
Poniższa lista zawiera podsumowanie głównych aspektów, które szczegółowo omawiam w tym artykule.
- Znormalizowany Architektura: cgroup v2 ułatwia sterowanie i monitorowanie.
- Twardy Ograniczenie: parametr memory.max zapobiega niekontrolowanemu przydzielaniu pamięci.
- Delikatne Hamulec: memory.high zmniejsza ciśnienie bez natychmiastowego wyłączania.
- Bardziej ukierunkowane Ochrona: memory.low i memory.min nadają priorytet usługom.
- Przezroczysty Kontrola: funkcja memory.current dostarcza wartości pomiarowe do dostrajania.
Czym różni się cgroup v2 pod względem zarządzania pamięcią
Podsumowuję procesy w Kontrola Łączę grupy i zarządzam ich zapotrzebowaniem na pamięć jako jedną całość. W wersji v2 jądro ujednolica interfejsy, co pozwala mi spójnie stosować limity, progi zabezpieczające i telemetrię. Logika pamięci oddziela twardą izolację od miękkich ograniczeń, co nie powoduje natychmiastowego zablokowania alokacji, lecz uporządkowane spowolnienie. Dzięki temu mogę reagować na wartości odstające bez negatywnego wpływu na cały system, ponieważ procesy są zamykane lokalnie w danej grupie. W przypadku hostingu i kontenerów zapewnia to przewidywalność Zasoby-Rozkład obciążenia i przewidywalne reakcje na skoki obciążenia.
Wykorzystuję te cechy do grupowania usług o podobnym profilu i ustalania jasnych zasad. Dokładnie oddzielam kontenery, procesy PHP-Worker i procesy baz danych, tak aby każdy zestaw obciążeń miał swoje własne granice. W ten sposób unikam wpływów zewnętrznych, takich jak globalne obciążenie pamięci, które może negatywnie wpływać na nieszkodliwe zadania. Izolację tę można stopniowo udoskonalać, aż rozkład obciążenia będzie reagował w przewidywalny sposób. Dzięki temu zyskuję Przewidywalność podczas pracy i dbam o utrzymanie jakości usług nawet w okresach największego obciążenia.
Przegląd plików podatkowych
Zarządzanie pamięcią sprowadza się do kilku Parametry, które ustawiam w systemie plików cgroup. Każda grupa cgroup otrzymuje własne wartości twardych limitów, miękkich punktów hamowania i linii ochronnych. W ten sposób skaluję system od łagodnego odzyskiwania zasobów aż po bezkompromisową izolację, w zależności od ważności danej usługi. System monitorowania równolegle odczytuje aktualne wykorzystanie zasobów i generuje alarmy, gdy zostaną przekroczone progi ochronne. W ten sposób powstaje zamknięta pętla regulacyjna składająca się z wartości docelowych i pomiarów, która Zasoby-umożliwia kontrolowanie zużycia.
| Parametry | Rodzaj | Efekt | Typowe zastosowanie |
|---|---|---|---|
| memory.max | Twardy Granica | Blokuje nowe przydziały pamięci powyżej limitu; lokalne zakończenie procesu z powodu braku pamięci (OOM) | Bazy danych, środowiska JVM, pule PHP-FPM z jasno określonymi limitami |
| memory.high | Miękki hamulec | Zwiększa wartość Reclaim i opóźnienie przy alokacjach; brak natychmiastowych zabójstw | Delikatne łagodzenie napięcia przed eskalacją |
| memory.low | MiękkiOchrona | Najlepsza możliwa ochrona przed odzyskiem poniżej progu | Kluczowe oprogramowanie pośredniczące, pamięci podręczne, usługi centralne |
| memory.min | Twardszy Ochrona | Brak „Reclaim” poniżej progu; OOM dotyczy raczej innych grup | Kluczowe elementy krytyczne |
| memory.current | Na żywo-Wartość | Pokazuje aktualne zużycie; podstawa dla alarmów i regulacji | Panele kontrolne, analizy trendów |
| memory.oom.group | Zabij-Zakres | Zlicza zabójstwa OOM na poziomie grupy | Spójne zakończenie powiązanych ze sobą procesów |
Zrozumienie hierarchii i dziedziczenia
Konfiguruję cgroups hierarchicznie: Grupy nadrzędne wyznaczają ramy, elementy podrzędne dziedziczą ograniczenia i dzielą między sobą dostępną pamięć. Struktura ta sprawia, że wytyczne są przewidywalne, wymaga jednak jasnych zasad. Parametr memory.max elementów nadrzędnych ogranicza sumę wartości elementów podrzędnych; parametry memory.low i memory.min działają w przypadku rywalizacji na poziomie elementów równorzędnych jako Priorytety: Grupa o wyższym poziomie ochrony ma większą szansę na zachowanie swojej pamięci podstawowej, podczas gdy mniej istotne grupy są w większym stopniu poddawane odzyskiwaniu. Pomaga mi to zabezpieczyć kluczowe ścieżki bez osłabiania globalnych limitów.
Zauważam, że wartości graniczne addytywny Zasadniczo: zbyt wysokie wartości parametru memory.min dla wszystkich elementów podrzędnych blokują proces odzyskiwania pamięci w hierarchii i przenoszą obciążenie w górę, aż do hosta. Dlatego dostosowuję limity ochronne dla poszczególnych poziomów i zawsze pozostawiam wolny bufor. W modelach warstwowych definiuję klasy (krytyczne, ważne, best effort) i stosuję spójne szerokości pasma oraz progi ochronne dla każdej klasy. Dzięki temu rozkład obciążenia pozostaje sprawiedliwy i przejrzysty – nawet jeśli zespoły samodzielnie zarządzają podgrupami.
Ścisła granica: prawidłowe ustawienie wartości memory.max
Ustawiłem memory.max tak, aby proces miał wystarczającą przestrzeń na szczyty obciążenia, ale nie dominował na serwerze. W tym celu mierzę realistyczne szczyty, dodaję rezerwę, a następnie konsekwentnie ograniczam wykorzystanie. Jeśli usługa osiągnie ten górny limit, nie otrzymuje już przydziałów, a jądro kończy lokalne procesy w ramach tej grupy. Takie odizolowanie zapobiega efektowi domina w odniesieniu do innych obciążeń. W przypadku usług wymagających dużej ilości pamięci oznacza to wyraźną Bezpieczeństwo bez uszkodzeń poprzecznych.
W przypadku dużych stert lub pamięci podręcznych celowo uwzględniam bufory, ponieważ zbieranie śmieci i zadania w tle powodują skoki obciążenia. Weryfikuję ten limit za pomocą testów obciążeniowych, aby w normalnym trybie pracy nie dochodziło do zdarzeń typu OOM. Jeśli wykorzystanie pamięci utrzymuje się na stałym poziomie bliskim limitu, najpierw zwiększam rezerwę lub zmniejszam rzeczywistą ilość pracy. W ten sposób ograniczam ryzyko błędów i utrzymuję wysoką wydajność. Ta dyscyplina opłaca się w Dostępność od.
Łagodne hamowanie: memory.high w codziennym użytkowaniu
Z memory.high ustawiam punkt ostrzegawczy i punkt hamowania przed ostrym progiem. Jeśli grupa przekroczy tę wartość, jądro uruchamia mechanizm Reclaim i spowalnia alokacje, nie przeprowadzając jednak natychmiastowego czyszczenia. Wykorzystuję ten czas na opróżnienie pamięci podręcznej, rozłożenie obciążenia wsadowego lub obniżenie limitów żądań. W ten sposób wyrównuję szczyty obciążenia, zanim konieczne będzie przerywanie procesów. Poprawia to Jakość usług w przypadku nagłych skoków obciążenia.
Odstęp między wartościami memory.high a memory.max ustalam tak, aby system miał rzeczywisty margines działania. Jeśli różnica jest zbyt mała, zbyt szybko dochodzi do błędu OOM. Jeśli jest zbyt duża, tracę kontrolę nad opóźnieniami. Testuję oba warianty w profilach produkcyjnych i kalibruję optymalny punkt. W ten sposób uzyskuję niezawodny Przepustnica, która zadziała w odpowiednim czasie.
Polityka wymiany pamięci: świadomy wybór wartości parametru memory.swap.max
To ja decyduję, czy i w jakim stopniu dana grupa Zamiana mogę wykorzystać. Za pomocą parametru `memory.swap.max` ograniczam pamięć wymiany niezależnie od limitu pamięci RAM. Ustawiając tę wartość na 0, blokuję korzystanie z pamięci wymiany dla danej grupy – ma to sens w przypadku usług wrażliwych na opóźnienia, które nie mogą ulegać blokadom. Zezwalając na umiarkowane wykorzystanie pamięci wymiany, zyskuję elastyczność dla pamięci podręcznych i rzadko używanych stron. Ważne jest, aby pilność znajomość obciążeń: bazy danych i środowiska JVM często czerpią korzyści ze ścisłej lub bardzo restrykcyjnej polityki wymiany pamięci, podczas gdy zadania wsadowe lub raportowe lepiej radzą sobie z wymianą pamięci.
Dostosowuję strategię swapowania do konfiguracji hosta (np. swappiness, zram/zswap), aby podjęte działania nie były ze sobą sprzeczne. Nadmierne wykorzystanie pamięci wymiany maskuje niedobór pamięci tylko krótkotrwale i przenosi obciążenie na operacje wejścia/wyjścia – wykorzystuję ją celowo jako Bufor, a nie jako stan trwały. Wskaźniki takie jak „Major Page Faults” i opóźnienia szybko pokazują, czy swap pomaga, czy przeszkadza. W ten sposób zachowuję kontrolę nad opóźnieniami i opóźnieniami ogonowymi.
Linie ochronne: memory.low i memory.min
Używam memory.low, aby zapewnić ważnym usługom ich pamięć bazową. Dopóki wykorzystanie pozostaje poniżej tego poziomu, jądro oszczędza tę część pamięci i woli odzyskiwać pamięć w innych miejscach. W przypadku komponentów o wysokim priorytecie używam dodatkowo parametru memory.min. Ta twarda linia ochronna jasno sygnalizuje jądru, że nie zezwalam na odzyskiwanie pamięci w tym miejscu. Dzięki temu serce aplikacji pozostaje sprawne nawet pod ekstremalnym obciążeniem i responsywny.
Celowo ustalam takie priorytety: centralne bazy danych otrzymują ustawienie „memory.min”, krytyczne oprogramowanie pośredniczące – „memory.low”, a niekrytyczne zadania wsadowe nie otrzymują dodatkowej ochrony. Takie ustalenie priorytetów ułatwia podejmowanie decyzji w sytuacjach niedoboru pamięci. W przypadku wystąpienia błędu OOM (brak pamięci) ta klasyfikacja chroni moje kluczowe ścieżki. Zachowuję kontrolę nad tym, kto jako pierwszy zwolni pamięć. Daje mi to jasny Priorytety w przypadku niedoborów.
Przejrzystość: memory.current w monitoringu
Czytam memory.current na bieżąco analizuję i koreluję te dane z wskaźnikami aplikacji. W ten sposób dostrzegam trendy, narastanie zaległości i szczyty obciążenia. Jeśli system odnotowuje coraz więcej przypadków przekroczenia wartości memory.high lub zdarzeń OOM, dostosowuję limity lub obciążenie. Pulpity nawigacyjne i alerty pozwalają mi wyprzedzać awarie. Na podstawie tych danych wywnioskuję Strojenie-podejmuje decyzje, które w dłuższej perspektywie pozwalają uniknąć przestojów.
Oprócz samej wartości obserwuję wskaźniki błędów stron (Page Fault), współczynnik trafień w pamięci podręcznej (Cache Hit Rate) oraz opóźnienia. Ten widok pokazuje, czy funkcja Reclaim zbyt mocno spowalnia system, czy też uruchamiają się mechanizmy ochronne. Dostosowuję interwały i wartości progowe, aż alarmy staną się przydatne, a nie irytujące. Następnie automatyzuję działania zaradcze, takie jak czyszczenie pamięci podręcznej (cache-trim) lub ograniczenie kolejki. Dzięki temu reakcja pozostaje szybka i ukierunkowany.
Telemetria – zagłębienie: memory.stat, memory.events i PSI
Dodaję do `memory.current` następujące elementy: memory.stat oraz memory.events, aby zidentyfikować przyczyny, a nie tylko objawy. memory.stat rozdziela wykorzystanie pamięci na kategorie: Anon, File-Cache, Slab i inne. Na podstawie tych wartości mogę stwierdzić, czy rosną alokacje danej aplikacji lub pamięci podręcznej stron – i odpowiednio dostosować ustawienia (np. rozmiary pamięci podręcznej w stosunku do liczby procesów roboczych). memory.events i memory.events.local zliczają zdarzenia, takie jak przekroczenia wartości low/high/max, a także oom oraz oom_kill. Dzięki temu uzyskujemy niezawodne wyzwalacze dla alertów i automatycznego naprawiania.
Używam również PSI (Pressure Stall Information), aby ilościowo określić ciśnienie zamiast zgadywać. Jeśli wartości Memory-PSI stale rosną, wątki doświadczają opóźnień; ograniczam obciążenie, zwiększam wartość memory.high lub odciążam przepustowość w potoku. W sumie powstaje telemetria, która pozwala mi stopniowo Wczesne ostrzeżenia zapewnia – zanim zaczną obowiązywać surowe ograniczenia.
Kontenery i koordynacja
Jeśli ustawię limity pamięci w Kubernetes, zostaną one zapisane jako cgroup-Wartości takie jak memory.max i opcjonalnie memory.high w środowisku uruchomieniowym. Orchestracja stosuje zasady dla poszczególnych podów, podczas gdy ja definiuję szczegóły dla poszczególnych przestrzeni nazw lub wdrożeń. Aby zapewnić niezawodne wskaźniki SLO, łączę limity ze strategiami HPA i budżetami podów. Takie kompleksowe podejście zapobiega sytuacji, w której pojedyncze pody zdominowałyby pamięć. Dobrym wprowadzeniem do Izolacja zasobów za pomocą cgroups ułatwia projektowanie kontenerów o wyraźnie wyznaczonych granicach i podjazdach.
Dodatkowo sprawdzam, czy sidecary i kontenery inicjalizacyjne mają własne limity, aby procesy pomocnicze nie ograniczały podstawowych obciążeń. W przypadku obciążeń stanowych ustawiam parametry `memory.low` lub `memory.min`, aby pamięć podręczna i bufory nie zmniejszały się natychmiast. Dokumentuję te decyzje w ramach wdrożenia, aby zespół mógł je łatwo zrozumieć. W ten sposób zapewniam Spójność między infrastrukturą a aplikacją. Efektem tego są przewidywalne profile obciążenia.
Integracja z systemem systemd i automatyzacja
Korzystam z systemd, aby deklaratywnie ustawić parametry cgroup v2: MemoryMax odpowiada wartości memory.max, MemoryHigh wartości memory.high, MemoryLow oraz MemoryMin wyznaczają linie ochronne, MemorySwapMax reguluje Swap. Ta struktura zapewnia przejrzystość zasad w repozytorium kodu i ułatwia przywracanie poprzednich wersji. W większych środowiskach wykorzystuję ją do koordynowania spójnych Standardy dla każdej klasy usług oraz oddzielenie działania od ręcznych interwencji.
W celu automatycznego podejmowania działań łączę zdarzenia z serwisu memory.events/PSI z silnikami polityk. Jeśli dana grupa wielokrotnie przekracza wartość memory.high, równolegle zmniejszam liczbę workerów, ograniczam szybkość szczytową lub uruchamiam ukierunkowane Cache-Trim. Jeśli te poziomy nie przynoszą oczekiwanych rezultatów, pozwalam na kontrolowane działanie wbudowanych mechanizmów OOM – dzięki parametrowi memory.oom.group efekt pozostaje lokalny i przewidywalny. W ten sposób powstaje stopniowe, samonaprawiające się zachowanie bez niespodzianek.
Hosting wielodostępny z CloudLinux
Izoluję środowiska klientów w oddzielnych cgroups i ustalam jasne limity dla każdego dzierżawcy. CloudLinux uzupełnia to o narzędzia, które ograniczają wykorzystanie pamięci RAM, procesora i operacji wejścia/wyjścia dla każdego konta. Dzięki temu efekty sąsiedztwa pozostają pod kontrolą, a pojedyncze przypadki nadmiernego obciążenia nie mają wpływu na wszystkie konta. Osoby, które chcą zgłębić ten temat, znajdą praktyczny przegląd dotyczący CloudLinux i cgroup v2 w kontekście hostingu współdzielonego. Dzięki temu zachowuję uczciwe Zasoby-Rozkład na wielu klientów.
Ustawiam wartość `memory.max` dla każdego klienta na podstawie zmierzonego profilu dziennego, przypisuję pamięć podręczną do `memory.low`, a kluczowe procesy zabezpieczam wartością `memory.min`. W przypadku przekroczenia limitów najpierw stosowane są mechanizmy ograniczające przepustowość (throttles), zamiast radykalnego blokowania kont. Jeśli wystąpi błąd OOM, dotyczy to lokalnie tylko danej grupy. Dzięki temu platforma pozostaje dostępna dla pozostałych najemców. Takie podejście wzmacnia Możliwość planowania w obliczu szczytów ruchu.
Przypadki szczególne: pamięć podręczna stron, THP i duże strony
Rozróżniam między Anon-pamięć (heapy, stosy) oraz Pamięć podręczna plików (Pamięć podręczna stron). W sytuacjach obciążenia pamięć podręczną plików łatwiej jest zwolnić, podczas gdy strony anonimowe wymagają użycia pamięci wymiany lub prowadzą do wyczerpania pamięci (OOM). Parametry `memory.high` i limity ochronne pomagają mi zwolnić pamięć podręczną plików bez naruszania krytycznych stosów. W przypadku Transparent Huge Pages (THP) sprawdzam, czy przynoszą one korzyści aplikacji, czy też zwiększają fragmentację i opóźnienia – w zależności od profilu dostosowuję politykę THP, aby zapewnić spójną współpracę z kontrolerem pamięci.
Korzystaj z aplikacji Hugepages W sposób jawny oddzielam ich zapotrzebowanie za pomocą odpowiednich kontrolerów od kontroli pamięci RAM. W ten sposób zapobiegam wypieraniu zwykłej pamięci operacyjnej przez duże strony. Utrzymuję te specjalne rezerwy na niskim poziomie i synchronizuję je z pozostałymi limitami, aby nie doszło do nieoczekiwanych wąskich gardeł. W sumie powstają jasne wytyczne dotyczące standardowego i specjalnego zużycia pamięci.
Najlepsze praktyki dotyczące limitów
Zaczynam od rzeczywistych profili zużycia i ustalam memory.max z rezerwą, aby szczyty nie powodowały natychmiastowego wyzwolenia błędu OOM. Wartość memory.high ustalam znacznie niżej, aby wygładzić fale obciążenia i spowolnić procesy alokacji. Ważne jest ustalenie priorytetów: baza danych otrzymuje wartość memory.min, oprogramowanie pośredniczące – memory.low, a obciążenie wsadowe nie odgrywa żadnej szczególnej roli. Monitorowanie towarzyszy pracy systemu i pokazuje, czy progi działają prawidłowo, czy też zostały ustawione zbyt surowo. Na podstawie tych sygnałów dostosowuję limity i jednocześnie zwiększam Wydajność aplikacji.
Dokumentuję wartości dla każdej usługi, opisuję uzasadnienia i w sposób przejrzysty odnotowuję zmiany. W ten sposób angażuję zespół w podejmowane decyzje i zapobiegam spekulacjom po upływie kilku tygodni. Przed aktualizacjami lub zmianami architektury analizuję wykresy historyczne, aby nie zaostrzać ani nie łagodzić parametrów na ślepo. Mały etap testowy pozwala później uniknąć wielu kłopotów w środowisku produkcyjnym. Taki rytm pracy zapewnia Constance w codziennej działalności.
W praktyce: organizacja serwerów hostingowych
Dla każdego klienta tworzę osobną cgroup i przenoszę do niego PHP-FPM, bazę danych oraz pamięć podręczną. Każdemu zestawowi przypisuję wartość memory.max plus bufor, podczas gdy memory.high działa wcześniej i wygładza wahania. Krytyczne usługi klienta otrzymują limity ochronne, aby nie spadła ich pamięć podstawowa. Logi i pulpity nawigacyjne pokazują, kto spowalnia, kto przyspiesza i gdzie grozi brak pamięci (OOM). Dodatkowo pomocne są wskazówki dotyczące Przestrzenie nazw i koncepcje izolacji, aby klienci byli wyraźnie rozdzieleni oraz Bezpieczeństwo wzrasta.
Ponadto dostosowuję liczbę procesów PHP, rozmiary pamięci OPcache i pamięci podręcznej zapytań, aby zmniejszyć zużycie pamięci. Często już samo ograniczenie szczytowego obciążenia za pomocą parametru `memory.high` skraca czas działania. Do testów wykorzystuję rzeczywiste wzorce obciążenia, a nie syntetyczne wartości idealne. Następnie dokumentuję nowe limity i powiązuję je z umowami SLA. W ten sposób rośnie Przejrzystość w stosunku do klientów oraz wewnętrznego działu wsparcia.
Wykrywanie błędów podczas drukowania z pamięci
Rośnie memory.current W pierwszej kolejności sprawdzam zmiany w ruchu sieciowym, wdrożeniach lub konfiguracjach. Porównuję wykresy dotyczących przekroczeń wartości maksymalnych, błędów stron pamięci i opóźnień. Jeśli występują seryjne błędy OOM, identyfikuję procesy, które uległy zawieszeniu, na podstawie dziennika jądra i dostosowuję limity lub obciążenie. Jeśli przyczyną są wadliwe pamięci podręczne, dokonuję ukierunkowanego czyszczenia zamiast stosować rozwiązanie globalne. Ten łańcuch diagnostyczny szybko prowadzi mnie do Przyczyna, a nie tylko objawem.
Jeśli obciążenie pozostaje wysokie, rozkładam pracę: ograniczam limity impulsów dla Ingress, zmniejszam długości kolejek, przesuwam zadania wsadowe. Równolegle tymczasowo zwiększam wartość memory.high, aby zyskać trochę czasu, bez podnoszenia wartości memory.max. Jeśli wykryję wycieki pamięci, zaostrzam limity, dopóki nie zostanie wprowadzona poprawka. W uporczywych przypadkach ograniczam zakres usługi lub replikuję instancję. W ten sposób utrzymuję Działanie działa niezawodnie, nawet pod presją.
Automatyzacja: działania zaradcze sterowane zdarzeniami
Tkam Działania zdarzeń: memory.events dostarcza liczniki, które przetwarzam za pomocą obserwatora lub potoku metryk. W przypadku powtarzających się wysokich wartości wskaźnika „high-hits” celowo opróżniam pamięci podręczne, obniżam współbieżność lub inicjuję próby odzyskiwania zasobów, zanim użytkownicy cokolwiek zauważą. Jeśli łagodne interwencje nie przynoszą efektu, przechodzę do zdecydowanych środków: wstrzymywanie żądań, opróżnianie kolejki, zmiana priorytetów. Ważne jest, aby decyzje deterministyczny są – te same czynniki wyzwalające, ta sama reakcja – aby zespoły mogły zrozumieć i odtworzyć dane zachowanie.
Ponadto zachowuję Zakres z uwzględnieniem OOM. Dzięki memory.oom.group unikam częściowego zamykania procesów, które powodują, że aplikacje przechodzą w niespójne stany. Jeśli coś musi zostać zakończone, powinno to nastąpić w sposób spójny i szybki, tak aby pozostałe zasoby były ponownie dostępne w krótkim czasie. W połączeniu z telemetrią i udokumentowanymi procedurami powstaje solidna pętla sprzężenia zwrotnego, która sprawdza się w rzeczywistych warunkach produkcyjnych.
Perspektywy i podsumowanie
Kontroler pamięci firmy cgroup Wersja v2 oferuje mi zróżnicowany zestaw narzędzi: twarde ograniczenia, miękkie hamulce i linie ochronne o jasno określonym priorytecie. Jeśli świadomie wykorzystuję parametry memory.max, memory.high, memory.low i memory.min, mogę w sposób uporządkowany reagować na skoki obciążenia i utrzymywać sprawność usług. Monitorowanie za pomocą memory.current pozwala wcześnie wykryć, gdzie limity są zbyt wąskie lub brakuje rezerw. W konfiguracjach kontenerowych i wielodostępnych mechanizmy te zapewniają sprawiedliwy przydział zasobów bez skutków ubocznych. Dzięki dyscyplinie, wartościom pomiarowym i niewielkim korektom osiągam niezawodną Wydajność – od pojedynczej maszyny wirtualnej po mocno obciążony serwer.
