AKTUALIZACJA: Zauważ, że odpowiedź poniżej dotyczy RHEL 6. W RHEL 7 większość grup jest zarządzana przez systemd, a libcgroup jest przestarzała.
Od czasu opublikowania tego pytania przestudiowałem cały przewodnik, do którego odsyłam , a także większość dokumentacji cgroups.txt i cpusets.txt . Teraz wiem więcej, niż się spodziewałem, aby dowiedzieć się o grupach, więc tutaj odpowiem na własne pytanie.
Istnieje wiele metod, które możesz zastosować. Kontakt z naszą firmą w Red Hat (architekt techniczny) zalecił całkowite ograniczenie wszystkich procesów zamiast bardziej deklaratywnego podejścia - ograniczając tylko te procesy, które konkretnie chcieliśmy ograniczyć. Powodem tego, zgodnie z jego wypowiedziami na ten temat, jest to, że wywołania systemowe mogą zależeć od kodu przestrzeni użytkownika (takiego jak procesy LVM), który w przypadku ograniczenia może spowolnić system - odwrotnie niż zamierzony efekt. Skończyłem więc na ograniczeniu kilku specjalnie nazwanych procesów i pozostawieniu wszystkiego innego w spokoju.
Ponadto chcę wspomnieć o niektórych podstawowych danych grupy , których brakowało, kiedy opublikowałem swoje pytanie.
Grupy C nie zależą od libcgroupinstalacji. Jest to jednak zestaw narzędzi do automatycznej obsługi konfiguracji cgroup i przypisywania procesów do cgroups i może być bardzo pomocny.
Odkryłem, że narzędzia libcgroup mogą również wprowadzać w błąd, ponieważ pakiet libcgroup jest zbudowany na własnym zestawie abstrakcji i założeń dotyczących korzystania z cgroups, które nieco różnią się od faktycznej implementacji cgroups na poziomie jądra. (Mogę podać przykłady, ale zajęłoby to trochę pracy; skomentuj, jeśli jesteś zainteresowany.)
Dlatego przed użyciem narzędzia libcgroup (takich jak /etc/cgconfig.conf, /etc/cgrules.conf, cgexec, cgcreate, cgclassify, itd.) Ja bardzo polecam się bardzo znane z /cgroupsamego wirtualnego systemu plików i ręcznego tworzenia cgroups, hierarchie cgroup (w tym hierarchii z wielu podsystemów przyłączone, który libcgroup podstępnie i leakily streszczeń od siebie), przypisywanie procesów do różnych grup przez uruchamianie echo $the_pid > /cgroup/some_cgroup_hierarchy/a_cgroup_within_that_hierarchy/tasksi inne pozornie magiczne zadania, które libcgroupwykonuje się pod maską.
Kolejna podstawowa koncepcja mi brakuje, że jeśli /cgroupwirtualny system plików jest zamontowany w systemie w ogóle (lub dokładniej, jeśli któryś z podsystemów cgroup aka „kontrolerów” są zamontowane w ogóle), a następnie każdy proces na cały system jest w A grupa. Nie ma czegoś takiego jak „niektóre procesy są w grupie, a niektóre nie”.
Istnieje tak zwana grupa główna dla danej hierarchii, która jest właścicielem wszystkich zasobów systemu dla dołączonych podsystemów. Na przykład hierarchia grupy cg, do której dołączone są podsystemy cpuset i blkio, miałaby główną grupę cg, która byłaby właścicielem całego cpus w systemie i całego blkio w systemie, i mogłaby współdzielić niektóre z tych zasobów z podrzędnymi grupami cgroup . Nie możesz ograniczyć grupy root, ponieważ posiada ona wszystkie zasoby systemu, więc ograniczenie nie miałoby nawet sensu.
Kilka innych prostych danych, których mi brakowało na temat libcgroup:
Jeśli używasz /etc/cgconfig.conf, powinieneś upewnić się, że chkconfig --list cgconfigpokazy cgconfigsą ustawione na uruchomienie systemu.
Jeśli zmienisz /etc/cgconfig.conf, musisz uruchomić, service cgconfig restartaby załadować zmiany. (A problemy z zatrzymaniem usługi lub uruchomieniem cgclearsą bardzo częste podczas wygłupów podczas testowania. Do debugowania zalecam na przykład lsof /cgroup/cpuset, jeśli cpusetjest to nazwa używanej hierarchii grupy).
Jeśli chcesz użyć /etc/cgrules.conf, musisz upewnić się, że działa „demon silnika reguł cgroup” ( cgrulesengd): service cgred starti chkconfig cgred on. (I powinieneś zdawać sobie sprawę z możliwego, ale mało prawdopodobnego stanu wyścigu dotyczącego tej usługi, jak opisano w Przewodniku zarządzania zasobami Red Hat w sekcji 2.8.1 na dole strony).
Jeśli chcesz oszukiwać ręcznie i konfigurować grupy za pomocą wirtualnego systemu plików (który zalecam do pierwszego użycia), możesz to zrobić, a następnie utworzyć cgconfig.confplik, aby odzwierciedlić konfigurację za pomocą cgsnapshotróżnych opcji.
I na koniec kluczowa informacja, której mi brakowało, kiedy napisałem:
Jednak zastrzeżenie w tej sprawie wydaje się ... że dzieci z myprocessname zostaną ponownie przypisane do ograniczonej grupy cpu0only.
Miałem rację, ale jest opcja, o której nie wiedziałam.
cgexec to polecenie, aby rozpocząć proces / uruchomić polecenie i przypisać je do grupy.
cgclassify to polecenie przypisujące już działający proces do grupy.
Obie te będą również zapobiegać cgred( cgrulesengd) z realokacja określonego procesu do innego cgroup na bazie /etc/cgrules.conf.
Zarówno cgexeci cgclassifywspierać --stickyflagę, która dodatkowo zapobiega cgredod realokacja potomnych procesów w oparciu o /etc/cgrules.conf.
Tak więc odpowiedź na pytanie, które napisałem (choć nie konfigurację, którą ostatecznie wdrożyłem, z powodu porady naszego architekta technicznego Red Hat wspomnianego powyżej) brzmi:
Utwórz grupy cpu0onlyi anycpucgroup zgodnie z opisem w moim pytaniu. (Upewnij się, że cgconfigjest ustawiony do uruchamiania podczas rozruchu).
Ustaw * cpuset cpu0onlyregułę zgodnie z opisem w moim pytaniu. (I upewnij się, że cgredjest ustawiony do uruchamiania podczas rozruchu).
Zacznij żadnych procesów chcę, nieograniczony z: cgexec -g cpuset:anycpu --sticky myprocessname.
Procesy te będą nieograniczone, a wszystkie ich procesy potomne również będą nieograniczone. Cała reszta w systemie będzie ograniczona do CPU 0 (po ponownym uruchomieniu, ponieważ cgrednie stosuje cgrules do już działających procesów, chyba że zmienią swój identyfikator EUID). Nie jest to całkowicie wskazane, ale tego właśnie początkowo zażądałem i można to zrobić za pomocą cgroups.