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

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

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

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

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

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Możesz wyłączyć AdBlock — tu nie ma reklam ;-)