Анонимная подкачка и контейнеры

[Maksim Dmitrichenko]

Всем хай!

Граждане, никак не могу найти ответ на вопрос. Вот есть у меня допустим 100 контейнеров из одного имиджа, или 100 имиджей с общим слоем (слоями). Будет ли скажем libc загружен в память единожды, так как это один и тот же бинарь из базового слоя, или же в каждом контейнере своя анонимная память?

--

With best regards
  Maksim Dmitrichenko

[Tim Sattarov]

Привет

On 11/24/22 08:19, Maksim Dmitrichenko wrote:
> Всем хай!
>
> Граждане, никак не могу найти ответ на вопрос. Вот есть у меня допустим 100 контейнеров из одного
> имиджа, или 100 имиджей с общим слоем (слоями). Будет ли скажем libc загружен в память единожды,
> так как это один и тот же бинарь из базового слоя, или же в каждом контейнере своя анонимная память?
>
>

Я буду очень удивлён, если сотня контейнеров будет шарить память, даже анонимную. я так понимаю
файловая система каждого контейнера создаётся из образа и тот же libc грузится каждый раз в свою
область, для каждого из ста.
С другой стороны у меня тоже сомнения появились, пошёл RTFM.

Тим

[Victor Wagner]

В Thu, 24 Nov 2022 17:19:43 +0400
Maksim Dmitrichenko <dmit...@gmail.com> пишет:

> Всем хай!
>
> Граждане, никак не могу найти ответ на вопрос. Вот есть у меня
> допустим 100 контейнеров из одного имиджа, или 100 имиджей с общим

Какая система контейнеризации, какой способ монтирования образов?

Для того чтобы ядро могло понять что это одна и та же libc, где-то
должен быть примонтирован этот образ, а последующие слои цепляться туда
как overlayfs.

И то не уверен.

Мне так казалось что control groups на базе которых строятся системы
контейнеризавции предназначены как раз для того, чтобы сделать
полностью незвисимыми области памяти, используемые контейнерами.

> слоем (слоями). Будет ли скажем libc загружен в память единожды, так
> как это один и тот же бинарь из базового слоя, или же в каждом
> контейнере своя анонимная память?
>



--

Victor Wagner <vi...@wagner.pp.ru>

[Иван Лох]

On Thu, Nov 24, 2022 at 05:19:43PM +0400, Maksim Dmitrichenko wrote:
> Всем хай!
>
> Граждане, никак не могу найти ответ на вопрос. Вот есть у меня допустим 100
> контейнеров из одного имиджа, или 100 имиджей с общим слоем (слоями). Будет
> ли скажем libc загружен в память единожды, так как это один и тот же бинарь
> из базового слоя, или же в каждом контейнере своя анонимная память?

В ядре есть такая технология — KSM (kernel same-page merging), но, насколько
я знаю, она включается если на страницы выставлен соответствующий флаг.
Так, что не факт, что это всегда работает во всех системах.

[Andrey Jr. Melnikov]

Maksim Dmitrichenko <dmit...@gmail.com> wrote:
> [-- text/plain, encoding base64, charset: UTF-8, 11 lines --]

> Всем хай!

> Граждане, никак не могу найти ответ на вопрос. Вот есть у меня допустим 100
> контейнеров из одного имиджа, или 100 имиджей с общим слоем (слоями). Будет
> ли скажем libc загружен в память единожды, так как это один и тот же бинарь
> из базового слоя, или же в каждом контейнере своя анонимная память?

KSM то в ядре есть, только толку от него - не много:

KSM only deduplicates (merges) memory pages that were flagged with MADV_MERGEABLE
flag using madvise() syscall. Recent QEMU versions are using madvise() to advise
memory pages used by VMs to be merged.

А UKSM за 10 лет так и не довели до вменяемого состояния. И не доведут -
память подешевела настолько, что проще воткнуть следующие 64 гига, чем
заниматься поиском и де-дупликацией одинаковых страниц (который ещё и жрет
процессор).

[George Shuklin]

On 24/11/2022 15:19, Maksim Dmitrichenko wrote:
> Всем хай!
>
> Граждане, никак не могу найти ответ на вопрос. Вот есть у меня
> допустим 100 контейнеров из одного имиджа, или 100 имиджей с общим
> слоем (слоями). Будет ли скажем libc загружен в память единожды, так
> как это один и тот же бинарь из базового слоя, или же в каждом
> контейнере своя анонимная память?
>

Меня этот вопрос интересовал даже в более простом разрезе: из одного и
того же image'а запускается N контейнеров, будет ли там какая-либо
экономия памяти из-за shared code. Достоверного ответа я не нашёл, но
запуск 500 копий из разных ven'ов на хосте или запуск 500 контейнеров с
одного image дал одинаковый результат по используемой памяти.  Более
того, 500 копий из одного venv'а дало тот же результат.

Поскольку магической дедупликации в ядре нет, то, получается, что если
экономия и есть (на rodata), то не существенная.

Моё размышление: если у нас всё проходит через динамический линкер, то
relocation table кто-то должен заполнять (а у нас же ещё и рандомизация
адресного пространства!), так что код в памяти не может соответствовать
секции в файле. Единственная возможная секция для прямого маппинга - это
.rodata, но во-первых я не уверен, что она есть, а во-вторых её явно
меньше, чем .text (в которой код находится).

Если кто-то знает какую-то актуальную информацию по тому, как бинари
грузятся в современном линуксе, буду благодарен.