V první části této série jsem diskutoval o základních konceptech cgroups a o tom, jak cgroups pomáhají řídit výkon a bezpečnost na linuxových serverech. Zde ve druhé části diskutuji o hodnotě CPUShares a o tom, jak ji používají cgroups. Nezapomeňte, že ve třetí části se podívám na správu cgroup a ve čtvrté části uzavírám cgroups při jejich interakci se systemd.
Něco o Linux Elevators
V této sekci se velmi úzce zaměřím na Red Hat Enterprise Linux (RHEL). Nicméně při mém rychlém pohledu na několik boxů Ubuntu v mé laboratoři jsem si všiml podobnosti s plánovačem I/O. Některé z mých bodů by se proto mohly vztahovat i na jiné distribuce. Většina produktů z rodiny Red Hat (Fedora, CentOS a RHEL) používá buď deadline nebo cfq jako výchozí plánovače.
- Completely Fair Queuing (CFQ):Zdůrazňuje I/O pocházející z procesů v reálném čase a využívá historická data k rozhodnutí, zda aplikace bude v blízké budoucnosti vydávat další I/O požadavky.
- Termín:Pokouší se poskytnout zaručenou latenci pro požadavky a je zvláště vhodný, když se operace čtení vyskytují častěji než operace zápisu. Existuje jedna fronta pro čtení a jedna pro zápis. Operace se dokončují na základě času stráveného ve frontě a jádro se vždy pokusí zpracovat požadavky před uplynutím jejich maximální doby. Operace čtení mají ve výchozím nastavení přednost před dávkami zápisu.
S ohledem na to má RHEL tendenci používat cfq pro disky SATA a deadline pro všechny ostatní případy standardně. To hraje důležitou roli při ladění vašeho systému. Tyto plánovače lze samozřejmě změnit a měli byste prozkoumat své pracovní vytížení a vybrat plánovač, který nejlépe vyhovuje vašim úkolům. Za zmínku také stojí, že plánovač lze zvolit pro blokové zařízení . To znamená, že můžete mít více plánovačů na jednom systému v závislosti na tom, jak jsou vaše disky nakonfigurovány.
[ Také by se vám mohlo líbit:Nastavení kontejnerových serverů SSH pro nahrávání relací pomocí protokolu tlog ]
CPUShares
CPUShares hodnota poskytuje úlohám v cgroup relativní množství času CPU. Jakmile systém připojí řadič cpu cgroup, můžete použít soubor cpu.shares k definování počtu sdílených položek přidělených cgroup. CPU čas je určen vydělením CPUShares cgroup celkovým počtem definovaných CPUShares v systému. Tato matematika s časem CPU je poměrně komplikovaná, takže se podívejme na několik diagramů, abychom si věci ujasnili.
Výše uvedený diagram představuje některé z nejběžnějších prvků na serveru řídicí roviny RHEL 7 OpenShift Container Platform. Každý proces v tomto systému začíná znakem / cgroup.
V RHEL to začíná kořenem / cgroup s 1024 sdílenými položkami a 100 % zdrojů CPU. Zbytek zdrojů je rovnoměrně rozdělen mezi skupiny /system.slice , /user.slice a /kubepod.slice , každý má ve výchozím nastavení stejnou váhu 1024, jak je vidět níže:
V tomto scénáři je logika docela přímá:Každý řez může využívat pouze 33 % CPUShares, pokud všechny cgroups vyžadují sdílení současně. Matematika je docela jednoduchá:
A když zapojíte čísla:
Co když se však rozhodnete vnořit skupiny nebo změnit váhu skupin na stejné úrovni? Níže je uveden příklad vnořených skupin:
V tomto příkladu vidíte, že jsem vytvořil cgroup pro různé uživatele. Zde začíná být matematika zajímavá. Zpočátku byste si mysleli, že následující rovnice bude fungovat dobře:
To je však pouze 23 % z 33 % přidělených user.slice . To znamená uživatel1 má přibližně 7,6 % celkového času CPU na základě těchto vah v případě sporu o zdroje.
CPUShares se ve spěchu zkomplikovaly. Naštěstí většina ostatních ovladačů je přímočařejší než tento.
[ Začínáte s kontejnery? Podívejte se na tento bezplatný kurz. Nasazení kontejnerových aplikací:technický přehled. ]
Sbalit
Hodnoty CPUShares mohou způsobit, že cgroups vypadají opravdu složitě. To je část toho, proč jsem zde chtěl pokrýt CPUShares. Správné používání CPUShares vám však pomůže spravovat váš systém efektivněji a přesněji.
V dalším článku této série pojednávám o správě cgroup. Doufám, že tuto sérii budete i nadále sledovat. Ve čtvrté části zakončím naši diskusi se systemd a cgroups.