LINUX.ORG.RU

Вышел cgroups v2

 , , ,


2

2

Инженер Facebook Tejun Heo объявил о выходе cgroups v2. Полностью переделанная версия механизма cgroups уже доступна в mainline и будет включена в релиз Linux 4.5.

cgroups v2 сфокусирован на предоставлении единого, универсального и продуманного интерфейса (в то время как v1 очень беспорядочен и непоследователен). В частности, в v2 есть только одна унифицированная иерархия, per-process. Все контроллеры теперь жестко иерархические и ведут себя стандартизированным образом. Работающие, четко определенные soft limits для котроллера памяти, теперь не надо полагаться на тюнинг OOM killer'а. Работающий resource control для writeback IO.

Механизм ядра cgroups широко используется такими важными и популярными инструментами, как Docker, Hadoop, Kubernetes, LXC, Mesos и CoreOS. cgroups v2 уже обкатан в продакшене в Фейсбуке, хотя в ближайшем будущем ожидается несколько больших интересных нововведений, которые стали возможны благодаря редизайну.

>>> Пост в FB

★★★★★

Проверено: Pinkbyte ()
Последнее исправление: Wizard_ (всего исправлений: 3)

cgroups v2 уже обкатан в продакшене в Фейсбуке

Вот это неплохой способ коммитить что-то в ядро.

loz ★★★★★
()

Механизм ядра cgroups широко используется такими важными и популярными инструментами, как Docker, Hadoop, Kubernetes, LXC, Mesos и CoreOS.

systemd допишите.

DeadEye ★★★★★
()
Ответ на: комментарий от anonymous

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Document...

Говорят что «mixing v2 hierarchy with the legacy v1 multiple hierarchies in a fully backward compatible way».

Щупать надо самим, короче, но совместимость закладывалась - уже радует.

Pinkbyte ★★★★★
()
Ответ на: комментарий от leave

Вот что значит приходить в темы из трекера - я, блин, даже не заметил что это новость :-/

Pinkbyte ★★★★★
()

Звучит интересно. Спасибо за новость.

targitaj ★★★★★
()
Ответ на: комментарий от loz

Вот это неплохой способ коммитить что-то в ядро.

единственный для нас. все тестируется в приватных бранчах перед тем как апстримить.

val-amart ★★★★★
() автор топика
Ответ на: комментарий от anonymous

больше интересно коммиты к btrfs которую они пилят увидеть, особенно было бы весело, чтобы subvol стали блочным устройством.

erzentddd
()
Ответ на: комментарий от erzentddd

subvol стали блочным устройством

Файловая система, которая реализует тома, которые отдаются как блочные устройства? SOMETHING IS SERIOUSLY BROKEN OUT THERE.

kirk_johnson ★☆
()
Ответ на: комментарий от kirk_johnson

это вы авторам ZFS скажите...

anonymous
()

Ура! По мне так первичная фишка cgroups не контроллеры, а возможность иерархически маркировать процессы, чем и пользуется systemd.

Теперь же появилась возможность прикручивать менеджеры на поддеревья. Т.е. Поттеринг, пугающий unified hieracy, таки пукнул в лужу.

Это отличнейший повод для systemd-xeйтеров погнать systemd из PID 1.

А для systemd-филов — сделать systemd рекурсивным.

Macil ★★★★★
()
Ответ на: комментарий от no-dashi

ZFS?

Да, я в курсе.

На самом деле, сейчас понятие ФС вышло за уровень собственно файловой системы.

У кого вышло?

kirk_johnson ★☆
()
Ответ на: комментарий от Macil

я не понял, можешь подробнее обьяснить плиз? если что, я знаю что делает этот чейндж и пользуюсь им в проде. но я не пользуюсь системд нигде. как это поможет «заменить системд»? что такого уникального дает системд в pid 1 по отношению к cgroups?

val-amart ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

На самом деле, сейчас понятие ФС вышло за уровень собственно файловой системы

так и есть

targitaj ★★★★★
()
Последнее исправление: targitaj (всего исправлений: 1)
Ответ на: комментарий от val-amart

Насколько я понимаю, изначально systemd имел свою иерархию процессов (маркировка процессов согласно их запуску сервисами), а logind - свою (маркировка процессов согласно их запуску пользовательскими сессиями). Потом в ведре решили отказаться от множественных иерархий и контроллеров, и Леня вынес все управление cgroups в systemd, а logind прибил к нему гвоздями (при том, что некоторые non-systemd дистры успели принять logind без systemd). Сейчас вроде как можно сделать обратно - оба будут управлять одной иерархией, systemd будет разбивать ее по сервисам, а logind внутри сервисов, порождающих пользовательские сеансы, будет создавать сеансовые поддеревья. Ну или прямо в корне, если будет использоваться без systemd.

shatsky ★★
()
Последнее исправление: shatsky (всего исправлений: 1)
Ответ на: комментарий от val-amart

я не понял, можешь подробнее обьяснить плиз?

В cgroups можно сделать группу не прицепленную к контроллеру. Смысл? Можно иерархически маркировать процессы, *как бы они и в каком порядке бы не форкались*. Исключительно ради этого и затевался systemd.

Systemd не требуется вести БД разной степени ущербности, для соответствия метка сервиса -> PID. Ему достаточно просканить свою группу и получить данные «из первых рук».

Уже тогда было понятно, что cgroups в таком виде не очень удобны. Практически сразу встал вопрос о unified hierarchy. Проблема в том, что в cgroups1 в рамках одной иерархии, уведомления мог получать только один процесс через достаточно кривой механизм. Т.е. при если бы UH была бы применена в таком виде как сейчас, в системе мог быть бы только один Д'Артаньян, все остальные — ...

Другое дело, что за столько лет, несмотря на эпические потоки говна излитого в адрес Поттеринга, соперников на должности главного Д'Артаньяна у systemd так и не появилось.

Возможность введения UH была одним аргументов Поттеринга по поводу дизайна systemd и необходимости объединения функционала PID 1 и менеджера cgroups. Да и внедрения systemd вообще.

Теперь, судя по докам, это неактуально. Д'Артаньянов может быть не один, и каждый Д'Артаньян будет тихо-мирно получать своё подмножество уведомлений по своему поддереву меток/контроллеров.

Macil ★★★★★
()

только одна унифицированная иерархия

Отлично. Реальный юз-кейс для множественных иерархий даже придумать трудно, никогда не понимал зачем их сделали.

selivan ★★★
()

стандартизированный подход это хорошо, но стал ли он работать лучше?

anonymous
()
Ответ на: комментарий от andreyu

фоточке суши быстрее зааплоадятся на стену

unt1tled ★★★★
()
Ответ на: комментарий от anonymous

А оно вроде реализацию ядра пользует. По крайней мере, при сборке в генте включать CGROUPS надо.

DeadEye ★★★★★
()
Ответ на: комментарий от anonymous

нет конечно. как ты представляешь себе «свою реализацию» ядренного механизма.

val-amart ★★★★★
() автор топика

А насколько полно реализованы ограничения дискового пространства в контейнерах сейчас? Ну в том плане что с этим вроде были какие-то проблемы...

ipeacocks ★★★★★
()
Ответ на: комментарий от ZenitharChampion

с нетерпением жду твоего анализа закладок спецслужб в cgroupsv2, кулхацкир мамкин. шапочка не жмет?

val-amart ★★★★★
() автор топика
Ответ на: комментарий от ipeacocks

А насколько полно реализованы ограничения дискового пространства в контейнерах сейчас? Ну в том плане что с этим вроде были какие-то проблемы...

именно обьема дискового пространства? никак, и никогда небыли. cgroups позволяет управлять гораздо более сложными и ценными параметрати IO: очередями, иопс, пропускной способностью. квотами занимается механизм квот и разрешений фс. но это все морально устарело, если есть такая необходимость, проще всего создать отдельную фс под этот контейнер, механизмов для этого масса в зависимости от типа контейнера. для «голых» cgroups вероятно надо замаппить эту фс как единственную rw фс в namespace этой группы.

val-amart ★★★★★
() автор топика
Ответ на: комментарий от Macil

Теперь, судя по докам, это неактуально. Д'Артаньянов может быть не один, и каждый Д'Артаньян будет тихо-мирно получать своё подмножество уведомлений по своему поддереву меток/контроллеров.

По своему поддереву меток (т. е. поддереву в иерархии). Насколько я понимаю, два процесса не могут рулить разными контроллерами одного и того же поддерева.

Ну а «рекурсивный systemd» таки уже есть.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Насколько я понимаю, два процесса не могут рулить разными контроллерами одного и того же поддерева.

Могут. Главное, чтобы управляющие процессы не гадили друг другу в чай...

Но тут моё cgroups-фу заканчивается. Нужно смотреть исходники, а лучше ставить тестовое ядро. Последнее, слегка проблематично на современных дистрах: спасибо Поттерингу.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Нужно смотреть исходники, а лучше ставить тестовое ядро. Последнее, слегка проблематично на современных дистрах: спасибо Поттерингу.

А в чем сложность? Ведь cgroupsV1 никуда не делась и поделие поттеринга будет также работать на новом ядре. Монтируешь новый cgroup в другую ветку и тестируешь что нужно.

anonymous
()
Ответ на: комментарий от Macil

а лучше ставить тестовое ядро. Последнее, слегка проблематично на современных дистрах: спасибо Поттерингу.

А гентушники-то и не знали. В чём проблема в любом дистрибутиве собрать своё ядро из транка?

Chaser_Andrey ★★★★★
()

уже обкатан в продакшене в Фейсбуке

Вот это я понимаю тестирование.

paran0id ★★★★★
()
Ответ на: комментарий от Pinkbyte

Кстати там все очень толково и круто наконец-то сделали.

qnikst ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.