Инженеры из компании Facebook (запрещена в РФ) опубликовали отчёт о внедрении в прошлом году технологии TMO (Transparent Memory Offloading), позволяющей значительно экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данных на более дешёвые накопители, такие как NVMe SSD-диски. По оценке Facebook, применение TMO позволяет экономить от 20 до 32% ОЗУ на каждом сервере. Решение рассчитано на применение в инфраструктурах, в которых приложения запускаются в изолированных контейнерах. Работающие на стороне ядра компоненты TMO уже включены в состав ядра Linux...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57383
Сначала пишут жирный софт, а потом пытаются эффеективно свапиться. 2022.
На чём основана твоя уверенность, что их задачи можно уместить в 640 КБ, и только лень не позволяет это сделать?
Facebook был написан на пхп а сейчас у них своя реализация пхп с типами и jit - hack lang. Hack это виртуальная машина, которая ест много памяти как и другие ВМ.
Если бы они выбрали компилируемый язык типа golang то памяти требовалось бы в 10 раз меньше.
Тут есть небольшая проблема, что если бы они писали на голанге или другом компилируемом языке. Большой компанией они бы никогда не стали. И их продукт никогда бы не взлетел. А так да ты прав.
Если бы у твоей бабки был х, то она не была бы у.
Не вижу причинной связи никакой. Наоборот, более эффективный софт выделял бы их в конкурентной борьбе.
Только в твоих влажных, пользователям пофиг на твой эффективный софт. Фейсбук бы просто ничего не выпустил, до сих пор бы занимались рефакторингом рефакторинга, а деньги бы у них закончились еще 16 лет назад. И все пользователи бы сидели в другой соцсети написаной на пыхе.А как набрали пользователей можно и свой пых делать быстрый с блекджеком.
Давай тебе задача со звездочкой почему первая версия вконтакте написана на обычном пхп.
Так когда набрали и нужно было переписывать на компилируемом.
А ещё социальная сеть кажется мне простой программой.
кажется
> А как набрали пользователейНе пользователей, а скот. Пользователи не позволяют к себе относится так, какую политику давно ведет конопатый жид.
А что там плохого в политике? Не слежу за этим.
динозавры тоже были большие и неэффективные, были да сплыли, просто окружение позволяло, вот и щас позволяет
Это правда - когда они начинали эффективный по ресурсам и при этом фичастый язык был один - С++. Хрен бы они что сделали на нём. Это теперь есть голанг. Но голанг тоже со сборщиком мусора и тоже неэффективный по ресурсам. Так что вариант один - раст.
> вариант один - растМозила попробовала - доломала FF окончательно с потерей всего рынка.
В Мозилле не в Расте дело, а в "эффективных менеджерах", которые распилили почти весь бюджет между собой и половину разрабов уволили. Есть ощущение, что Мозиллу ведут к планируемому банкротству и поглощению Гуглом или Майкрософтом, с выплатой "золотых парашютов" менеджменту. Ну как с Нокией было.
> Ну как с Нокией было.У Нокии был фатальный недостаток: она находилась не в Штатах.
О как! А нам предлагали продукты, написанные на С++ и они даже работали? Хм. То ли нам такие продукты плохие продавали, то ли у них программисты негодные.
На самом деле уже в те времена был очень фичастый компилируемый язык со сборщиком мусора - Haskell. Единственный минус - порог вхождения высокий. Мало кто из пхпшников осилить способен.
Смелое утверждение. Поделитесь исходя из чего вы так решили?
Исходя из того что стоимость времени разработчика больше стоимости железа.
>Исходя из того что стоимость времени разработчика больше стоимости железа.Даже если это железо приходится растаскивать на кучу ЦОД разбросанных по всему миру и построенных с нуля? Ой не факт. Просто Вы не учитываете, что у руководства может не стоять цели "потратить как можно меньше денег в долгосрочной перспективе". Обычно там цель в том, чтобы по быстрому состряпать макет и продать долю компании за миллиард. А дальше, да парись оно всё конём.
Так не бывает что у тебя ЦОДЫ и тысячи серверов по всему миру и один разработчик. Если ты разместился по всему миру значит твои фичи нужны пользователям. А для этого надо много разработчиков и много времени. А если тебе надо писать на С++ то тебе надо еще больше времени и еще больше разработчиков. Но зачем когда можно писать на пыхе. Ну и пересчитай что в США один средний разработчик стоит 100000 долларов. А в Фейсбуке не меньше 10000 разработчиков.
А гугл вообще ничего не писал, он только покупал готовое и продавал данные, результат - сам видишь.
Разрешите вам немножечко порвать шаблон. Спасибо за разрешение.Первая версия того что сейчас Google называлось BackRub это был научный проект Брина и Пейджа и написан оно было СЮРПРИЗ на Java и Python. А если бы они писали на С/С++ они бы тупо никогда не закончили проект и забили. И такой поиск бы сделал кто-то другой.
Совет прикладывайте к порванному шаблону подорожник, скоро заживет.
Все верно, есть т.н. Lean методология, когда стадия стенда или прототипирования ставит в приоритет время и гибкость.Так же было с первыми шагами Твиттера, который был на Ruby on Rails.
Но уже не первых стадиях зрелости, компании начинают вертикальную интеграцию (переписывают стабильные вещи на другом стэке), т.к. на масштабе это экономит большие деньги
которые как раз можно потратить на новых сотрудников для новых продуктов и фич.
FB явно перерос стадию прототипирования и при этом не перестал быть глючным говном, в котором ни комментарии свои не найти,
ни даже ссылку на отдельный комментарий не дать (из приложения).
Хорошо, что есть Reddit (с больным на голову медиа плеером, который у всех в мире виснет и лагает)
Reddit, написанный на python
Какие в ж...пу фичи в Твиттере?! Увеличение сообщения больше 160 символов?! Доска сообщений она и есть доска...
"Если бы они выбрали компилируемый язык"
... то настолько масштабного сервиса не было бы никогда. Был бы концепт за концептом.
В этом всё веселье моднявых язычков. Реальные же серьёзные внедрения делаются на других.
Ну а на сях фейсбук написать - не, можно наверное, но оно ж онлайновое, потом всё это поддерживать, отлаживать, деплоить... это просто ад трешовый.
Я видел их код. За такой код надо запрещать работать в индустрии навсегда.
Ещё один любитель искусства ради искусства.
>Сначала пишут жирный софт, а потом пытаются эффеективно свапиться. 2022.Да никто вам уже не будет байтики считать в 2022-м, ЗАБУДЬТЕ про это.
>> байтики считатьУдивитесь, но и сейчас считают, и ещё как.
И востребованы весьма нестандартные способы сжатия.
Есть низкоскоростные каналы связи, типа Lora, и радиоканал.
А есть и гораздо более шустрые средства связи, но всё равно пропускная способность не резиновая.
Да, это не совсем та область, о которой Вы подумали, но считают.
Причём здесь каналы связи? Я имел ввиду ОЗУ вычислительных устройств с полноценным ЦПУ и их софт.
А какой из стандартных алгоритмов сортировки выберете для строкового массива на пару Тб?
Выберу вот такой.Вон отсюда...
> А какой из стандартных алгоритмов сортировки выберете для строкового массива на пару
> Тб?Стандартные маловероятно.
Была не очень давно задача не про сортировку, а поиск и выборку значений из базы. Типа встроенный прибор, ни вменяемой структуры, ни полезного индекса. С ростом аппетитов базы распухли, и операции выборки стали переваливать за 40 секунд.
Носитель - флешка, скорости ограничены, в ОЗУ много не накэшируешь. Плюс могут быть сбойные записи, ннедостающие параметры, вместо еоторвх надо выдать что то другое.
Поставили задачу, сделать работу хоть как то быстрее. Если вдвое быстре будет, то это предел мечтаний.
До алгоритмов не сам дошел, воспользовался помощью математиков.
И, после оптимизации...
время операций стало 0.02 - 0.3 секунд, в лучшем и хуждем случаях.
Более, чем в тысячу раз ускорил. ;)
На том же желелезе.В чем подвох? Вместо наращивания производительности, или переписывания на Русты, применили алгоритм учитываюший характер данных, построили модели распределения данных, модели сбоев, в алноритме поиска учитывается сколько операций может потребоваться до длинной и коротким ветвям поиска, и вероятности попадания на короткие пути...
Так, что обсуждаемый механизм TMO, учитывающий характер данных, и их важность, даже при не лучшей реализации будет всяко эффективнее "бездумного" свопа.
> применили алгоритм учитываюший характер данных,Открою секрет, у данных нет характера, это тупа куча байт.
> построили модели распределения данных,
> модели сбоев, в алноритме поиска учитывается сколько операций может потребоваться до
> длинной и коротким ветвям поиска, и вероятности попадания на короткие пути...Математики молодцы, заработали себе бабла из вакуума.
1. Если в системe "работает" вероятностный выбор, значит данные х...во организованы изначально.
2. Вероятностная выборка, в пределе, равна рандомному выбору, иначе данные х...во организованы изначально.
3. Собственно цифры с 40 до 0.02 говорят о том, что данные х...во организованы изначально.)))
> Открою секрет...Согласен по пунктам 1 и 3 полностью, и по 2му на 30%. :)
Нельзя в готовом, и по сути чужом проекте, который работает, все похерить и сделать правильно.
К элегантным костылям претензии есть? Да, нет, они шикарны.
>> Открою секрет...
> Согласен по пунктам 1 и 3 полностью, и по 2му на 30%.
> :)
> Нельзя в готовом, и по сути чужом проекте, который работает, все похерить
> и сделать правильно.
> К элегантным костылям претензии есть? Да, нет, они шикарны.Найти чупакабру на ноевом ковчеге - O(N)
Найти чупакабру в зоопарке - O(1)
А просто ссд или нвме диск в своп добавить не додумались.
читай внимательно. они привязали данные ко времени, без этих ваших процентных содержаний озу.
А какой от этого толк что ты уберешь в своп что-то раньше по времени чем позже по процентам. У тебя же все равно будет неиспользованная оператива. Или ты пустую оперативу солить собрался? И оба подхода сойдутся когда опера и своп закончатся.
1. можно больше памяти пустить на кэши
2. можно намного избирательнее относится к памяти так как всегда известно ее прошлое время обращение
классический swap:
1. начинаем выгружать при 60% озу
2. выгружаем то что можно выгрузить не разбераясь в этом
Прям очень сильно натянутый сценарий. Он наверняка отлично подходит для отчета для менеджера смотрите вот эта кривая ниже проходит. Мы теперь делаем ту же работу, а сумма свободной оперы у нас больше! Это же положительный рост!Если тебе так нужен кеш и ты к нему так часто обращаешься он и при старой системе свопа будет в опере и вытеснит всё ненужное в своп. Даже если в обычной системе есть временной лаг между переполнением оперы и началом свопа он не выглядит чем то заградительным.
Я бы даже поверил что это полезно для десктопа, например мак принудительно свопит даже если у него полностью пустая система. По своему фирменному алгоритму. Тут можно поверить что ты запустил тяжелое приложение и чтобы оно быстро стартануло, надо быстро все в оперу закинуть. А если она пустая то вообще норм. Но на сервере такой сценарий очень натянут.
Я бы может сабжу и нашел сценарий на сервере, но только в случае ручного управление, какому приложению можно всегда быть в своп, какому никогда в своп не попадать. Но сабж такой функционал не предполагает.
Это своп другого уровня. Как я понял, гипервизор динамично управляет свопом/памятью в запущенных контейнерах (/виртуалках?). Это не совсем то, как если бы иметь своп исключительно на той или другой стороне. Как-то так.
И это тоже
Вот что интересно.. привязать данные в озу к времени использования чтобы выгрузить неактуальные данные...
Они изобрели своп?
Они изобрели аккуратный своп, в отличие от классического, который выгружал всё подряд.Судя по описанию -- годно и нужно.
Судя по описанию это маркетинговый буллшит.
+
Когда прочитал думал они какой то супер пупер метод сжатия придумали. А они придумали ровно то же колво сметаны перекладывать в те же банки, но перекладывать "более сильнее".
Они улучшили своп
> компонент SenpaiНадо взять на заметку! Вместо терминологии мастер/слейв можно употреблять сенсей/сенпай. Можно пойти еще дальше и употреблять рэй, ёй, каматэ, хачиме, ямэ и осс для обмена сообщений между клиент/сервером.
Сэмпай/кохай же.
Кохай - это "люби" по-украински?
OOMKiller переименовать в Яндере.
Потом можно сразу переходить на персонажей аниме. Тогда OOMKiller это коро-сенсей.
У щелочкоглазых очень развитая терминология в вопросах распределения ролей. Проблема в том, что надо быть реальным японистом, чтобы в этом всем не путаться. Вся команда разработки должна быть.
А можно плз перевод терминов? С целью повышения уровня образованности.
это стандартные термины в каратэ (для общения, не для обозначения техник)рэй - приветствие
ёй - приготовиться
осс - подтверждение (так точно, понял, готов)
каматэ - принять боевую стойку
хачиме - старт/начать
ямэ - финиш/отбойсенсей - учитель
сенпай - старший ученик
кохай - младший ученик
незнаю каратэ, начать разьве не hajime?
в голодных сёстрах помойму было, hajimaru you!
ну так поди, сенпай он для кохая сенпай, а не для сенсея. Для сенсея он такой же кохай.
Там каламбур на тему одной игры.
Замена политнекорректного OOMKiller на Яндере. Что тот же киллер, но с любовью.
Тут надо прояснить откуда берется семпай и кохай - у японцев в школах есть всякие клубы и прочие местные "комсомольские организации" в которых совместно участвуют ученики разных годов обучения, поэтому и появляется меду ними взаимодецствие с делением на "старший"\"младший". Потом такая модель отчасти тянется и более взрослую жизнь.
У нас в Дикой такое ученики разных годов обычно никак не взаимодействуют.
Насколько я помню из прочитанного - у японцев ообще сильно поделённое по возрасту\соц. положению общество, редко кто кому может напрямую обращаться.
> Насколько я помню из прочитанного - у японцев ообще сильно поделённое по
> возрасту\соц. положению общество, редко кто кому может напрямую обращаться.Ну это вообще характерно дял азиатов, хотя сейчас я так понимаю "не то что раньше". В Корее тоже самое.
Senpai, yamete kudasai, it doesn't fit. Out of memory.
барин/холоп
Никита Сергеич Михалков. Перелогиньтесь!
Уже. Долго же до вас тренды доходят.
Заранее выкидывать из памяти. Ну-ну.
На яблоке только недавно удалось отрубить нафиг тамошний своп
Ведь валилось в него даже при половине или трети занятой ОЗУ и не высвобождалось даже когда ещё больше ОЗУ освобождалось
Как ни странно, но красивой кнопки в настройках для этого не нашлось. И без консоли не обошлось. Даже с консолью - сам механизм решения проблемы не столь уж и простойДержу в курсе
А как не подскажите? MacOS убивает просто, 32GiB оператоса, i9 а тормозит как черте знает что -_-"
А в компании выбор либо M$ либо MacOS из-за антивирусов и прочей фиготени.
> А в компании выбор либо M$ либо MacOSЛучше выбрать другую компанию
>> А в компании выбор либо M$ либо MacOSУчитывая стоимость железок, бакс всё-таки корректней ставить яблоку - MacO$ или, просто O$ X
Бери мс - там и интерфейс человеческий и есть WSL что тот же линупc.
> А как не подскажите? MacOS убивает просто, 32GiB оператоса, i9 а тормозит
> как черте знает что -_-"
> А в компании выбор либо M$ либо MacOS из-за антивирусов и прочей
> фиготени.Причин для тупни на яблоке может быть полно, но вот что по памяти:
Для начала отключить SIP
После - в терминале ввести
> sysctl -a vm.compressor_modeЕсли выдаёт 4( по умолчанию ) - валит на диск, нужно переключить в 2
Перед изменением на всякий получить текущий список аргументов
> nvram boot-argsИ указать что нефиг использовать диск если есть оперативка!
> sudo nvram boot-args="vm_compressor=2"Или, скорее, даже так
> sudo nvram boot-args="выхлоп_от_запроса_списка_параметров_загрузки_предыдущего_шага vm_compressor=2"Изменения вступают в силу после перезагрузки. Если всё норм, то sysctl -a vm.compressor_mode должна выдавать 2
Если работает на хакинтоше, то пытаться просто менять nvram бесполезно - исправлять надо в настройках опенкор( там одно из полей - аккурат кагбэ_nvram_для_яблока )
Любое вытеснение данных из оперативки в своп (что обычное, что умное от Фейсбук) это сигнал что необходимо немедленно или оптмиизировать приложения, или масштабировать (разносить) на большее кол-во серверов, или тупо добавлять оперативку. Использование свопа не есть нормальность, это лишь временный костыль позволяющий день простоять да ночь продержаться !
Походу хомки с 512 меговыми впсками радуются.
Если в своп проваливается не tmpfs у тебя большая проблема. Даже если шоу со спецффектами пока почему-то не началось, то скоро это случится. Однако, в своп попадают и БЕСПОЛЕЗНЫЕ данные, а также УТЕКШАЯ память, использование свопа -- это единственный способ нормальной работы, просто кто-то уже это понял, а кто-то ещё не дорос и занимается самолюбованием по поводу "а я своп отключаю".
> просто кто-то уже это понял, а кто-то ещё не дорос и занимается самолюбованием по поводу "а я своп отключаю".Просто кто-то знает когда можно и нужно отключать своп а когда этого это делать не стоит. И когда лучше не экономить на железе, а когда пытаться за каждый рубль давиться. Разные задачи порождают разные решения. Кричать "своп нужен всегда" также глупо как кричать "а я своп отключаю".
Единственный способ временного решения проблем. Потечь конечно может и своп спасет. Но это лишь повод начинать искать пути решения. Добавить железок найти утечку или вовремя перезапускать потекший процесс. Если ты постоянно работаешь со свопом у меня для тебя плохие новости.
Иногда своп своим своим наличием увеличивает время беспроблемного аптайма до месяцев, а вот попытки его отключать приводят к тому, что памяти часто и внезапно начинает не хватать. Далеко не все операции требуют много памяти постоянно, временно можно поступиться перетеканием в своп огромной бесполезной кучи фоновых данных. Да и в целом, когда память используется под файловые кэши, это куда полезнее старых не востребованных данных оказывается. Есть ситуации, когда отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой причине), но на практике такие задачи ещё придётся поискать.
> Иногда своп своим своим наличием увеличивает время беспроблемного аптайма до месяцев, а
> вот попытки его отключать приводят к тому, что памяти часто и
> внезапно начинает не хватать. Далеко не все операции требуют много памяти
> постоянно, временно можно поступиться перетеканием в своп огромной бесполезной кучи фоновых
> данных. Да и в целом, когда память используется под файловые кэши,
> это куда полезнее старых не востребованных данных оказывается. Есть ситуации, когда
> отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой
> причине), но на практике такие задачи ещё придётся поискать.Да, вот только частенько бывает обратное, свапование зачастую означает, что система плотно и глубоко "задумывается", без возможности дать ей дополнительную задачу, чисто потому, что по какой-то интересной причине ОЗУ не забито, а система в свапе что-то ворочает со скоростью эстонской черепахи.
Как бы ни был быстр ЖД, ОЗУ всё равно пока ещё быстрее, и зачастую свап ненужен, если ОЗУ физически хватает под задачи и даже вреден, для скорости работы.
>[оверквотинг удален]
>> это куда полезнее старых не востребованных данных оказывается. Есть ситуации, когда
>> отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой
>> причине), но на практике такие задачи ещё придётся поискать.
> Да, вот только частенько бывает обратное, свапование зачастую означает, что система плотно
> и глубоко "задумывается", без возможности дать ей дополнительную задачу, чисто потому,
> что по какой-то интересной причине ОЗУ не забито, а система в
> свапе что-то ворочает со скоростью эстонской черепахи.
> Как бы ни был быстр ЖД, ОЗУ всё равно пока ещё быстрее,
> и зачастую свап ненужен, если ОЗУ физически хватает под задачи и
> даже вреден, для скорости работы.Свап был создан в те времена, когда ОЗУ объективно не хватало физически и когда упавший и незавершившийся корректно процесс, был удшим исходом, нежели намного более медленное, но всё же разрешение и завершение процесса корректным образом.
>[оверквотинг удален]
>>> отключение свопа целесообразно (в основном критерий недопустимость любых задержек по этой
>>> причине), но на практике такие задачи ещё придётся поискать.
>> Да, вот только частенько бывает обратное, свапование зачастую означает, что система плотно
>> и глубоко "задумывается", без возможности дать ей дополнительную задачу, чисто потому,
>> что по какой-то интересной причине ОЗУ не забито, а система в
>> свапе что-то ворочает со скоростью эстонской черепахи.
>> Как бы ни был быстр ЖД, ОЗУ всё равно пока ещё быстрее,
>> и зачастую свап ненужен, если ОЗУ физически хватает под задачи и
>> даже вреден, для скорости работы.
>был *худшим исходом, нежели...
> Любое вытеснение данных из оперативки в своп (что обычное, что умное от Фейсбук) это сигнал чтокнутом сечь нещадно нужно таких разработчиков.
Вы из тех, кто считает сервер с 256 ГБ RAM для раздачи торрентов минимумом?https://github.com/arvidn/libtorrent/issues/6667#issuecommen...
Мне кажется что Вы со своим вопросом промахнулись - он явно не ко мне.
от 20 до 32%?
zram и zswap в некоторых случаях экономит в 2-3 раза.
Тсссс ты сейчас всё портишь.
Zswap хорошая идея, но он заполняется целиком и памяти начинает сильно не хватать, программы падают. выполняешь swapoff/swapon и оказывается, что он был пустым, просто занятым. Этому багу уже лет 20.Zram просто толку никакого, сжатие там недостаточно эффективное, чтобы весь утёкший мусор пожать, да и не только он ведь туда стекает. Намного выгоднее чистая быстрая память и обычный своп.
В некоторых случаях, я же написал, понятное дело, что с какой-нибудь джавой zram не прокатит, но на отдельных виртуалках где много чего текстового в RAM заталкивается - очень даже неплохо все экономит. К примеру на виртуалках с документсерверами onlyoffice и collabora подрезал реальной ОЗУ в 2 раза после включения zswap и нормально работают.
zram вернее
в Zram сжатие эффективное, а вот скорость - нет
> в Zram сжатие эффективное, а вот скорость - нетСжатие то эффективно, а вот размер окна -- нет. Это значит, что одинаковые данные за пределами окна будут сжаты несколько раз, отдельно.
>и оказывается, что он был пустым, просто занятым. Этому багу уже лет 20.man для кого писан?
Опцию монтирования discard в Zswap докинь, Шклифасофский.
>No results found for zswap discard.но не уверен, как это должно помочь, никогда не слышал о таком.
Именно тем и поможет - без опции discard не происходит высвобождение страниц zswap, они продолжают висеть занятыми и после протухания.
Быть может, у вас включён и zram, и zswap одновременно? Я встречал описываемый вами баг именно в таком сценарии.
Больше всего хочется: Гугл значительно оптимизировал и сократил потребление ОЗУ браузера Chrome. А встроенный MPV позволит просматривать видео даже на некрожелезе. Установочный файл весит всего 10 Мб.
Не дождёшься
Там не гугл виноват. Просто почитай сам стандарт HTML - охренеешь, сколько всего вычурного и костылеподобного надо поддерживать! А ещё ведь есть CSS, JS, мультимедия, отладочные средства... не удивлён, что chrome.dll занимает 170МБ! Хотя многовато для софта, да.Мы бы давно перешли бы к "тонкому вебу", если б г***но HTML заменили бы на адекватный стандарт паблишинга.
XHTML?
PDF. Он изначально был кандидатом для веб, но кое-кто подсуетился, и теперь имеем дерьмохтмл.
> Установочный файл весит всего 10 Мб.Есть такие, из разряда веб-инсталляторов. Качаешь такой на пару мегабайт, а тот потом в процессе установки еще половину интернета выкачает.
Не фанат я такого рода вещей.
А может ли эта технлогия использоваться в обычном свопе на HDD, чтобы trashingа и 12309 не было?
Для этого разработчик Google уже несколько лет пытается включить патч в стандартное ядро Linux: https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao&...Подобная технология уже около 10 лет работает на Chrome OS и несколько лет на Android. Вот здесь я писал эффект от альтернативного патча, который делает почти то же самое, там же есть видео: https://notes.valdikss.org.ru/linux-for-old-pc-from-2007/
Понаделали своих реактора и прочих ректал нативов, а теперь мучаются.
Ничё так идея - гробить ресурс SSD ради экономии оперативки...
Не гробить, а использовать. Если так получается выгоднее, то почему нет?
Считать надо. Но я сильно сомневаюсь. Во-1, - оператива, считай, вечная - капитальные затраты единожды и всё, а SSD, даже самый лучший, менять надо, тем более при таком сценарии использования. Во-2, народ наоборот часть данных на RAM-диски перенести пытается далеко не зря.
Посчитайте пожалуйста. А то у нас у всех лапки....
Как там, в 2010-х?
Они-то себе могут и MLC позволить. А вот для простых линуксоидов(-гентоводов) они исчезли из продажи.
даже мыльце от такого не спасёт в долгосрочной перспективе, и даже сальце (SLC).
Не понимаю, зачем это всё. Разве своп не так же работал? Это позор конечно. Но если своп работал не так, значит надо было его доработать, а не городить велосипеды.
Текущая версия swap в линуксе работает, прямо скажем, неоптимально. Там используется простой LRU-механизм, с разделением только на данные (анонимную память) и файловый кеш.
Есть два подхода к его улучшению, оба до сих пор не приняты в ядро:1. Патч под названием le9: https://github.com/hakavlad/le9-patch
Защищает (как мягко, так и жёстко) какое-то фиксированное количество файлового кеша в оперативной памяти. Очень полезно для десктопов, позволяет выгружать гигабайты в своп без зависаний и тормозов системы.2. Более продвинутая версия предыдущего патча с автоматическим определением количества важного файлового кеша MG-LRU, добавляющая понятие времени к LRU: https://lore.kernel.org/lkml/20220614071650.206064-1-yuzhao&...
Применяется в Chrome OS и Android.
Подробное описание: https://lore.kernel.org/all/20220614071650.206064-15-yuzhao&.../
А потом приложение внезапно по какому-то редкому запросу решает сходить в "холодную" память, и ВЕСЕЛУХА.
Не, в масштабах фейсбука всё понятно, там 99% хипа висят сутки мёртвым грузом в качестве кеша для очень редких обращений. Но за пределами применимость так себе. Это как RocksDB - на определённых применениях оно более-менее годно, но за их пределами - вообще неприменимо.
> на более дешёвые накопители, такие как NVMe SSD-дискиЧет как-то не очень понял. Памать конечно дороже денег/мегабайт, но она хотябы не рассыпается от использования за год как вышеуказанные "дешевые" накопители. Как-то не очень экономично звучит.
> через cgroup2 динамически корректирует ограничение памятиТам разве не жёсткое ограничение? Приложение же упадёт если сделать ограничение на память меньше чем ему нужно.
Зачем _вообще_ эвиктить исполняемые страницы? 90% памяти -- это же ресурсы, а не код.
100500 подгруженых либ, в которых реально используется 0.1% кода не согласны. И код инициализвции тоже.
"позволяющей значительно экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данных на более дешёвые накопители, такие как NVMe SSD-диски"Эээ... WUT?!
С каких это пор с ограниченным циклом перезаписи SSD стали дешевле "вечной" ОЗУ?!Я где-то проспал техническую революцию в вопросе "вечной" жизни ssd?
интересный вопрос - вы считаете их почему-то должна заботить "вечная" жизнь дисков, они как-то прикипели к ним душой? или их больше должно заботить залезть в нарастающий рынок VR на 100500 миллиардов и надо успеть сформировать его на своих правилах, а там уже на сдачу поменять просто все диски (ну чего бы нет, от доброты душевной) или вообще на Optane переехать (может у них уже Optane местами конечно)
>С каких это пор с ограниченным циклом перезаписи SSD стали дешевле "вечной" ОЗУ?!
>Я где-то проспал техническую революцию в вопросе "вечной" жизни ssd?У тебя просто пробелы в экономике. Сравни стоимость гигабайта SSD и гигабайта серверной RAM ECC.
Если Facebook решил для себя, что регулярно менять сдохшие SSD дешевле, чем докупать дополнительной RAM, значит так оно и есть - корпорации априори считают деньги.
"Если ты не видишь суслика, это не значит, что его нет"
> регулярно менять сдохшие SSD дешевлерегулярно терять сдохшие данные хомячков - дешевле
P.S. сначала продадут, потом потеряют, чтобы на ковре в Конгрессе не сильно пинали.
Именно так!
В шкале приоритетов на первом месте прибыль, а хомячки - на последнем
То есть теперь накопители будут изнашиваться ещё быстрее?
А смысл тогда в увеличении производительности засчет доп. затрат?
Знаешь способ увеличения производительности без доп. затрат? Патентуй скорее.
Уже же все запатентовали. Мульен терабайтный свап файл выгоднее, чем столько рамы покупать. Не удивлюсь если сейчас проблемы с производством, доставкой колбасы.D Говорили же инфу у нас локализуйте, так нет же...XD
> экономить оперативную память на серверах за счёт вытеснения не требуемых для выполнения работы вторичных данныхМы настолько уже привыкли к дерьмовой архитектуре ПО, что даже не замечаем ужас тех проблем, которые устраняем. Вдумайтесь: оптимизация затрат памяти за счёт некоего исключения НЕНУЖНЫХ данных! Как они там оказались? Зачем ненужные неиспользуемые данные находятся в оперативной памяти? Что за разработчики создают ПО, которое создаёт неиспользуемые данные на определённом интервале работы ПО?
Это катастрофа.
>Как они там оказались?Они там остались от предыдущей операции, в которой они были нужны.
>Зачем ненужные неиспользуемые данные находятся в оперативной памяти?
Они ждут отработки стандартного механизма вытеснения данных на уровне ОС. Но к сожалению ОС - ничего не знает о внутренней логике приложения, и весьма вероятно, что алгоритм реализованный на уровне ОС вытеснит в первую очередь "не те данные" которые мог бы вытеснить. Предложенный механизм действует более эффективно.
Возможно в следующей версии ядра вы получите его по умолчанию...>Что за разработчики создают ПО, которое создаёт неиспользуемые данные на определённом интервале работы ПО?
Вам походу до них еще учится, учится и учится... :)
Только не читайте про стандартный аллокатор malloc в glibc: сильно будете удивлены, что он почти не отдаёт данные при выполнении операции free().
Надо же... А я когда-то написал демона на сях, у которого в цикле было malloc в начале и free в конце, так он месяцами крутился и не тёк. А должен был бы течь, если free не освобождает.
Современные версии аллокатора в glibc не отдают память в ОС, выделенную на хипе, если её нельзя уменьшить через sbrk, а аллокации через новые регионы требуют выделения сразу большого количества памяти за раз (от 16 МБ, если не ошибаюсь).
Баг от 2006 года: https://sourceware.org/bugzilla/show_bug.cgi?id=2531
https://stackoverflow.com/a/48652734
Гы... Теперь олдфаги могут кряхтеть, что "раньше и malloc/free нормально работали".
Щас прибежит один из Анонимов и будет с пеной у рта доказывать, что только так и можно написать успешный проект.
Прочитал комментарии и не понял, есть ли какие-то претензии к продукту, кроме того, что его написал фейсбук?
Технологии свопа уже лет 30 если не больше, и во всех осях она есть по дефолту, на кой нужна подделка от мордокниги?
на что только не пойдет мордокнига для своих php извращений
Переизобрели своп, мое почтение всем велосипедостроителям мира