Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Ogłoszenie
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
#1 2018-11-30 19:03:53
morfik - 
Cenzor wirtualnego świata
Brakujące kontrolery w cgroup v2
Chciałem ponownie w końcu zaimplementować sobie cgroup ale się trochę pozmieniało w tej kwestii i za bardzo nie wiem jak teraz powinno się ogarnąć to przedsięwzięcie.
Domyślnie systemy mające systemd na pokładzie używają trybu hybrydowego (v1+v2). Istnieje możliwość włączenia lub wyłączenia jednego z tych trybów i w ten sposób można mieć albo v1 albo v2. Więcej info tu.
Cgroup v1 działają u mnie bez problemu mniej więcej tak jak to kiedyś opisałem tutaj — podążając tym howto udało mi się wszystko wskrzesić u siebie, oczywiście dostosowując nieco rzeczy pod kątem obecnych realiów ale działa. xD
Problem w tym, że cgroup v1 nie ma kontrolerów od SWAP. Bez SWAP, system zachowuje się tak jak od niego oczekuję w przypadku, gdy jakiś proces zjada za dużo zasobów (dostaje w łeb od OOM-killer'a). Jak się włączy SWAP, to aplikacja zamiast dostać w łeb, to zaczyna zrzucać dane do SWAP i nie ma tutaj żadej kontroli ile tych danych może zrzucić. To i tak jest o wiele lepsze rozwiązanie niż bez cgroup, bo przynajmniej dane tego żarłocznego procesu są zrzucane do SWAP, a nie innych procesów. Niemniej jednak, czytaj sobie o cgroup v2, jest tam wzmianka o kontrolerze memory, a dokładnie chodzi o to poniższe:
memory.swap.current
A read-only single value file which exists on non-root
cgroups.
The total amount of swap currently being used by the cgroup
and its descendants.
memory.swap.max
A read-write single value file which exists on non-root
cgroups. The default is "max".
Swap usage hard limit. If a cgroup's swap usage reaches this
limit, anonymous memory of the cgroup will not be swapped out.
No i to jest to czego mi brakuje, problem w tym, że coś ten cgroup v2 w debianie jest jakiś niedorobiony (albo to mój system xD). Bo testowo włączając za pomocą systemd.unified_cgroup_hierarchy=1 w linijce kernela, mam coś takiego:
Kod:
# mount | grep cgroup cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate)
No i powinien być tylko ten jeden wpis ale jak się zajrzy do tego katalogu /sys/fs/cgroup/ , to tam jest:
Kod:
# cat cgroup.controllers cpu io memory pids
I widać, że jest memory. Jak się teraz stworzy jakiś katalog, to w nim są takie oto pliki:
Kod:
# ls -a ./ cgroup.max.descendants cgroup.type io.max memory.high pids.current ../ cgroup.procs cpu.max io.stat memory.low pids.events cgroup.controllers cgroup.stat cpu.stat io.weight memory.max pids.max cgroup.events cgroup.subtree_control cpu.weight memory.current memory.min cgroup.max.depth cgroup.threads cpu.weight.nice memory.events memory.stat
No i na moje oko to trochę tych plików brakuje. No i pytanie jak sprawić, by się one pojawiły. xD
A i jeszcze tak przy okazji. Chyba ten cgrulesengd i spółka raczej nie znajdzie zastosowania na cgroup v2, bo m.in. plik tasks został usunięty, no i nazwy plików się pozmieniały, itp? To jak teraz ogarnąć appki usera, by je jakoś ograniczyć?
Offline
#2 2018-11-30 20:16:10
Jacekalex - Podobno człowiek...;)
- Jacekalex
- Podobno człowiek...;)
- Skąd: /dev/random
- Zarejestrowany: 2008-01-07
Re: Brakujące kontrolery w cgroup v2
Cgroup v1 nie obrabia swapa?
To co oznaczają te klucze u mnie:
Kod:
/cgroup/memory/users/firefox/memory.memsw.failcnt /cgroup/memory/users/firefox/memory.memsw.limit_in_bytes /cgroup/memory/users/firefox/memory.memsw.max_usage_in_bytes /cgroup/memory/users/firefox/memory.memsw.usage_in_bytes /cgroup/memory/users/firefox/memory.swappiness
Jeżeli CgroupV1 nie pisali kretyni, to znaczy, że albo Debian ma jakiś błąd,
albo CgroupV2 jest zjebane, albo masz coś zwalone w konfiguracji.
Może błąd jest w tym hybrydowym v1+v2 z Systemd?
Jest też możliwość, że dokumentacja CgroupV2 wyprzedza rzeczywistość o 15 lat,
np spróbuj wg dokumentacji apparmora filtrować programom połączenia sieciowe,
sockety unix, ptrace i sygnały na domyślnym jaju Debiana, to lepiej zrozumiesz, o co chodzi.
np takie:
[88597.549626] audit: type=1400 audit(1543593918.545:7340): apparmor="DENIED" operation="signal" profile="/opt/google/*/chrome" pid=19109 comm="chrome" requested_mask="receive" denied_mask="receive" signal=kill peer="/opt/google/*/chrome
Ja na Cgroup V2 się wybiorę dopiero, jak będzie miał pełną funkcjonalność v1.
Chyba że wcześniej wyleci iptables na rzecz nftables a mnie się nie uda zrobić globalnej polityki AA czyli profilu dla /sbin/init.
Już się za niego zabieram jak pies za jeża od dłuższego czasu.
Poza tym w Debianie SWAP? po cholerę to, nie lepiej RAMu dokupić?
EDIT:
Cgroup v1 nie pisali kretyni:
...
memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
...
memory.memsw.max_usage_in_bytes # show max memory+Swap usage recorded
....
2.4 Swap Extension (CONFIG_MEMCG_SWAP)
Swap Extension allows you to record charge for swap. A swapped-in page is
charged back to original page allocator if possible.
When swap is accounted, following files are added.
- memory.memsw.usage_in_bytes.
- memory.memsw.limit_in_bytes.
memsw means memory+swap. Usage of memory+swap is limited by
memsw.limit_in_bytes.
Example: Assume a system with 4G of swap. A task which allocates 6G of memory
(by mistake) under 2G memory limitation will use all swap.
In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
By using the memsw limit, you can avoid system OOM which can be caused by swap
shortage.
* why 'memory+swap' rather than swap.
The global LRU(kswapd) can swap out arbitrary pages. Swap-out means
to move account from memory to swap...there is no change in usage of
memory+swap. In other words, when we want to limit the usage of swap without
affecting global LRU, memory+swap limit is better than just limiting swap from
an OS point of view.
* What happens when a cgroup hits memory.memsw.limit_in_bytes
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
in this cgroup. Then, swap-out will not be done by cgroup routine and file
caches are dropped. But as mentioned above, global LRU can do swapout memory
from it for sanity of the system's memory management state. You can't forbid
it by cgroup.
...
RTFM:
https://lwn.net/Articles/529927/
U mnie:
Kod:
root ~> zgrep -i MEMCG_SWAP /proc/config.gz CONFIG_MEMCG_SWAP=y CONFIG_MEMCG_SWAP_ENABLED=y root ~> grep firefox `which cgstart` | grep mem mkdir -p $CGDIR/memory/users/firefox echo '1'> $CGDIR/memory/users/firefox/cgroup.clone_children echo '2g' > $CGDIR/memory/users/firefox/memory.soft_limit_in_bytes echo '32m' > $CGDIR/memory/users/firefox/memory.kmem.tcp.limit_in_bytes echo '2g' > $CGDIR/memory/users/firefox/memory.limit_in_bytes echo '2g' > $CGDIR/memory/users/firefox/memory.memsw.limit_in_bytes echo '1' > $CGDIR/memory/users/firefox/memory.oom_control
Pozdro
;)
Ostatnio edytowany przez Jacekalex (2018-11-30 21:08:39)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
#3 2018-11-30 23:02:30
morfik - Cenzor wirtualnego świata
Re: Brakujące kontrolery w cgroup v2
Wygląda, że debian nie ma odpowiednich opcji w kernelu. I w sumie by te memory.memsw.* się pojawiły to trzeba albo sobie kernel przekompilować albo dodać do linijki kernela tę poniższa opcję:
Kod:
swapaccount=1
I powinno śmigać. xD
Offline