LINUX.ORG.RU

Новый метод управления памятью от Facebook

 , ,


1

4

Один из членов команды разработки социальной сети Facebook, Роман Гущин, предложил в рассылке разработчиков набор из патчей для ядра Linux, направленных на улучшение работы с памятью через реализацию нового контроллера управления оной – slab (slab memory сontroller).


Распределение slab – это механизм управления памятью, предназначенный для более эффективного распределения памяти и устранения значительной фрагментации. Основой этого алгоритма является сохранение выделенной памяти, содержащей объект определенного типа, и повторное использование этой памяти при следующем выделении для объекта того же типа. Этот метод был впервые введен в SunOS Джефом Бонвиком и сейчас широко используется в ядрах многих операционных систем Unix, включая FreeBSD и Linux.


В основе нового контроллера лежит перенос учёта slab с уровня страниц памяти на уровень объектов ядра, что предоставляет возможность совместного использования одной slab-страницы в разных cgroup, вместо выделения отдельного кэша для каждой cgroup.

По результатам испытаний следует, что предложенный метод управления памятью позволяет повысить эффективность использования slab до 45%, а также понизит общее потребление памяти ядром ОС. Также за счет сокращения количества выделяемых под slab страниц уменьшается фрагментация памяти в целом, что не может не сказаться на быстродействии системы.

Новый контроллер уже несколько месяцев тестируется на рабочих серверах Facebook, и пока это тестирование можно назвать успешным: при отсутствии потерь в быстродействии и увеличения количества ошибок замечено явное уменьшение расхода памяти – на некоторых серверах до 1Гб. Это число довольно субъективно, так, например, ранее проведенные тесты показали немного меньшие результаты:

  • 650-700 МБ на веб-фронтенде;
  • 750-800 МБ на сервере с кэшем баз данных;
  • 700 МБ на DNS-сервере.

>>> Страничка автора на GitHub

>>> Результаты ранних тестов

>>> Подробности

★★★★★

Проверено: leave ()

Роман Гущин, к слову, раньше пилил в Яндексе ядерный планировщик процессов smart (https://github.com/yandex/smart) для уменьшения latency. В апстрим, правда, не попало и особой распространенности не получило.

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

Вы прослушали каприччо с вариациями на тему арии «не нужно!». Исполнял сводный хор анонимусов-лорских.

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

на десктопе всё в одном контейнере или вообще без него, так что ненужно в квадрате

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

Ну, смотря сколько таких серверов. На 128 штук, это вполне себе экономия одного такого сервера. И я подозреваю, что у фейсбука их наверняка гораздо больше 128 штук, так что я вижу смысл в этой экономии.

undefiened ()

Ознакомился с первоисточником: Bonwick, Jeff. «The Slab Allocator: An Object-Caching Kernel Memory Allocator.» USENIX summer. Vol. 16. 1994

Получается Джеф эту фичу для солярки еще в 94 году запилил, а у нас только сейчас родили? И не ядерные линуксоиды, а какие то левые чуваки из фейбучка.

Uncle_Bobby ()

вкусовщина. сильно зависит от задач. если у тебя на сервере не крутится куча одинаковых задач, то экономии не будет никакой, а вот оверхед на объекты ядра - это ещё хз. опять же, если каждая страница - объект ядра, это ж в какие космические дали нужно загнать ограничитель объектов?

Iron_Bug ★★★★ ()
Последнее исправление: Iron_Bug (всего исправлений: 1)

что предоставляет возможность совместного использования одной slab-страницы в разных cgroup, вместо выделения отдельного кэша для каждой cgroup.

Совершенно в этом не разбираюсь, но это попахивает уязвимостями.

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

в линуксе Slab Allocator появился тоже в дремучие времена, просто новость писал ламерок, не понимая, о чём пишет

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

запуск кода с разными правами на одной машине уже попахивает уязвимостями, глубже вникать не обязательно

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

при чём тут это? я всё понимаю. и интересы оотдельных копрораций в ядре меня не радуют и я понимаю, что это сугубо их личные тараканы, остальным даром не нужные. это как раз то самое, что убивает Linux.

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

ух как бы круто без корпораций написали бы дрова для железа(собственно, 90% требующегося от ядра)

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

при открытых протоколах - запросто. могу прямо начинать уже. а проприетарщина не нужна. не использую принципиально.

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

Кто это убивает? Компания за свои деньги улучшила линукс и сделала это доступным всем. Тебя ведь никто не заставляет использовать эти патчи?

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

он и так был доступен всем. я его ещё в 90-е собирала. в чем твоя проблема?

да, меня никто не заставляет использовать эти патчи. поэтому пусть они остаются патчами и копрорации не навязывают их всем.

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

Я имею ввиду набор патчей. Вот ты говоришь «фигня», а тесты показывают обратное.

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

Получается Джеф эту фичу для солярки еще в 94 году запилил, а у нас только сейчас родили?

«Но люди читают жопой»(цы)

Тебе же написано, что это улучшение алгоритма slab.

Оригинальный slab ещё в 2.4 был, насколько помню, а может даже и раньше.

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

Копия с опеннета. Но там написано «Предложенный подход позволяет повысить эффективность использования slab, на 30-45% сократить размер используемой для slab памяти и значительно уменьшить общее потребление памяти ядром.»

А у тебя «позволяет повысить эффективность использования slab до 45%».

Речь идет об уменьшении размера используемой памяти на 45%, а у тебя получается что запилили суперэффективный алгоритм slab с приростом в 45%.

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

Копия - это дословный текст. Я его компилял из первоисточника и местами опеннета, где басурманская тарабарщина не сильно логически складывалась в здравый текст.

Писали бы сами новости, че.

Zhbert ★★★★★ ()

замечено уменьшение расхода памяти — на некоторых серверах до 1Гб

На моей «микроволновке» 1К сэкономлю.

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

+1, идее slab-ов уже не знаю, наверное не меньше 20 лет, и вообще этот способ борьбы с фрагментацией мне кажется чуть ли не очевидным. Но небось на это десять патентов уже намазано

I-Love-Microsoft ★★★★★ ()

Новый метод управления памятью от Facebook

Новый? Facebook с момента создания управляет памятью и сознанием пользователей.

Да и лор туда же скатился, зарегистрируйся или докажи, что не робот.

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

Джеф, между прочим автор zfs и вице-президент Oracle. А тебе и показать нечего.

А Элтон Джон - сэр, миллионер и вообще легенда. Это никак не отменяет его п*дорства, и равняться на него вовсе не хочется.

anonymous ()

800 метров экономии когда на сервере 512 гигов оперативки? И жертвовать cgroup разделением? То есть я могу из одного изолированного cgroup по смещению 10 байт читать данные другого приложения изолированного в cgroup и MMU молча в трямочку не будет сообщать ядру что произошёл выход за границы выделенной памяти процессу, не кинет исключение в ядро, и ядро не остановит процесс с сегфолтом! А чё, давай внедрим решето! А потом патчами заплатки наделаем так что ядро ещё и подтормаживать будет на операциях по распределению памяти! Это как от майкрософта патч? Только там он написан криво, а тут архитектура кривая. Готовим ещё один мультик короче!

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

так-то не могешь. даже в википедии писано белым по черному что енто не одновременный доступ к идентичному объекту, а кеширование освобождаемых участков памяти для того чтобы их заново не создавать.
к примеру обмазана твоя програмка по самое не балуйся какойнить функцией, которая в начале действа выделяет из кучи память под какую-либо свою структуру, а в конце своего действа пристреливает ентот кусок, ибо не нужон. а таких функций обычно воз с торчащими из него граблями
так вот умный slab отлавливает удаление объекта, высвобождение притормаживает и запоминает кто и под что его использовал. а при последующем таком же запросе на создание, подсовывает указатель на готовый кусок памяти.
типа так и быстрее и менее фрагментировано.

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

Аж полез смотреть, не выкатил ли кто уже такую машину…

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

slab, pool или gc?

slab можно считать более общим случаем пула. gc на хайлоаде нередко приносит проблем не меньше, чем решает.

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

вкусовщина ... если у тебя на сервере не крутится куча одинаковых задач

фейсбук большой, ему видней. они это для себя прежде всего делали.

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

молчи лучше в тряпочку. а то сейчас прийдется например gnu utils выпилить на своей тачке, которую тоже разрабатывает сотрудник Фейсбука Джим Мейеринг. как и многие другие вещи, включая базовые подсистемы ядра.

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

во-первых, давно уже слаб аллокатор есть в линуксе. речь о том как он взаемодействует с cgroups. во-вторых, сотрудники фб вполне себе ядерные линуксоиды: https://en.wikipedia.org/wiki/Jens_Axboe

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

вот и я об этом. они свои хотелки, никому больше не нужные, продавливают в ядро. это и есть вредоносное влияние копрораций.

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

ну, я не в восторге от гну, если уж на то пошло. гну - большая штука и там много откровенного говна. многое бы я с удовольствием выпилила со своего компа, и я даже потихоньку некоторые вещи выпиливаю. и ты мне тут не тыкай, себе тряпочку надень. сейчас у коронабесов это даже модно.

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

существуют. но по поводу вирусов никогда не было такой паранойи и средневековых плясок. были и более опасные MERS и другие разновидности.

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

ну, я интересуюсь медициной и биологией. не то, чтобы меня конкретно интересовали вирусы, но я много чего знаю и про них. но не суть. я просто вижу тут кучку адептов, поклоняющихся каким-то субъектам. я никогда не поклонялась никому. я вообще не интересуюсь личностями, если я не нашла ошибку в коде и не хочу сообщить о ней автору. а тут у некоторых прямо подгорает от моих неумышленных наездов на каких-то совершенно неведомых мне типов. и меня это рассмешило :)

единственное, что я считаю концептуальным - копрорации не должны навязвывать свои копроративные хотелки в качестве «более лучшего» для всех (на самом деле это далеко не так). и мне пофигу, кто там как называется и где работает.

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

кто девушку ужином кормит... ядро в XXI стало продуктом корпораций. а уже наши с тобой хотелки - это и есть никому больше не нужное.

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

это и есть вредоносное влияние копрораций.

Вообще-то open source всю дорогу развивался именно так: люди писали то, что было нужно в первую очередь пишущим. Теперь вот выросло поколение, для которого это — «вредоносное влияние».

я даже потихоньку некоторые вещи выпиливаю

Где можно взглянуть на результаты?

dexpl ★★★★★ ()

Этот метод был впервые введен в SunOS Джефом Бонвиком и сейчас широко используется в ядрах многих операционных систем Unix, включая FreeBSD и Linux.

О нет, ведь рынок порешал, в Linux самое самое лучшее ядро!

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

Солярка в середине 90-х умела многое из того, что в итоге признали «ненужно», так как решали увеличением памяти и скорости.

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.