Открыл для себя vm.overcommit_memory

Чем данные в свопе отличаются от прочих данных на диске по скорости доступа? Ничем, кроме разве что дефрагментированности. SSD стирает различие. Своп не нужен хотя бы потому, что прочитать снова данные с SSD и достать их из кеша на свопе - одно и то же. Что касается выдавливания неиспользуемых страниц в своп, так это лишь закостыливание багованных приложений, не способных самостоятельно отдать ненужную память. Кстати, в iOS SDK проблема решена чуть ли не в корне - получив предупреждение о чрезмерном использовании памяти, приложения просто сбросят кеши (иногда за них это сделает библиотека, используемая в приложении)

Верно лишь для случая работы при высоком заполнении памяти. При заполненности до 50% - ведет лишь к приросту производительности. Цифра «50», ессно, очень приблизительная.

Откуда ты взял цифру 50%? IMHO, ты рассуждаешь о вещах, в которых не разбираешься.

Это да. Читал дискуссию об аллокаторах в Rust и плакал.

А потом плачут крокодильими слезами, «используйте Линукс, там работает», когда кто-нибудь запускает их код в любой другой системе, реально распределяющей память при brk() или mmap().

Мне лично подход «если память дали — то она гарантированно есть» нравится намного больше. Линукс с оверкоммитом страдает отсутствием детерминизма.

Чем данные в свопе отличаются от прочих данных на диске по скорости доступа?

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

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

Только вот оставшийся к кеше часто используемый блок статистически значимо будет использован намного большее количество раз, чем забытые до выключения компьютера bash с mc на vty2.

А вот данные в кэше, который в оперативке, могут быть доступны гораздо быстрее

Мало того, что быстрее, к ним ещё и обратятся большее количество раз, чем к высвопленному куску.

И это если не рассматривать системы, где своп лежит на отдельном от основного датасета накопителе. Там сплошная экономия при любом раскладе.

Ошибаться надо в верхнюю сторону.

Кому надо - производителю памяти и ее продавцу?

Проектанту. Если у него не стоит задачей экономить любой ценой на всем чем можно

Какие-то детские загоны - «любой ценой, на всём, чем можно». Задача экономии стоит всегда, и из двух систем, отвечающих ТЗ, лучше та, которая дешевле. Сюрприз?

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

Когда не используется то, за что заплачено - да, это неэффективно. Сюрприз?

А потом плачут крокодильими слезами, «используйте Линукс, там работает», когда кто-нибудь запускает их код в любой другой системе, реально распределяющей память при brk() или mmap().

Никогда не слышал.

Тогда другими словами, борьба кеша со свопом, это не прирост производительности, это недостаток оперативки.

Следовательно истинный виновник потери производительности недостаток ОЗУ (либо программная течка памяти).

Борьба кеша со свопом при дефолтном swappiness = 60 начнётся от 60% заполнения ОЗУ. Условно будем считать это необходимым объёмом ОЗУ при недостатке которого начинает падать производительность. Потому что, если отключим своп, то потерем дисковый кеш, если включим своп получим выросший диcковый IO. Итого никакого роста не наблюдается только падение с разными видами парашютов.

Борьба кеша со свопом при дефолтном swappiness = 60 начнётся от 60% заполнения ОЗУ.

Нет. Она начнется при 100% заполнении ОЗУ и закончится со счетом 60:40 в пользу кеша.

Тогда другими словами, борьба кеша со свопом, это не прирост производительности, это недостаток оперативки.

Какая борьба, о чём ты?

Следовательно истинный виновник потери производительности недостаток ОЗУ (либо программная течка памяти).

Теперь представь, что ОЗУ достаточно.

Но уже при 60% начнётся заполнение свопа, следовательно начнёт увеличиваться дисковый i/o. C одной стороны экономия i/o на кеше, с другой стороны нагрузка i/o по свопу. Но суть в другом, использование свопа никак не увеличит производительность. Может только замедлить падение производительности в определенном промежутке.

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

Тю. Какие глупости. Да прочитайте наконец хоть что-нибудь о том как выделяется память. Ну хотя бы это:

https://habrahabr.ru/company/yandex/blog/250753/

Какая борьба, о чём ты?

Об этом

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

Но уже при 60% начнётся заполнение свопа

Нет. У тебя какое-то странное понимание swappiness

суть в другом, использование свопа никак не увеличит производительность

Есть как минимум один сценарий, в котором своп увеличивает производительность - mc, забытый на vty2, уйдет в своп и освободит немного RAM для кеша или анонимной памяти.

Откуда ты взял цифру 50%?

Я же написал специально, как можно было пропустить?

Цифра «50», ессно, очень приблизительная.

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

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

С чего вдруг?

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

А если памяти достаточно и менее нужные данные тоже находятся в оперативке? Куда этот случай то делся?

Не приблизительно 50, а точно 60 по дефолту

$ sysctl vm.swappiness
vm.swappiness = 60

отключение свопа вызывает прирост производительности

Не вызывает рост, он просто не используется. Ни своп, ни без свопа не даёт прироста производительности. Производительность может только падать по разному в зависимости от сценария. Именно эту мысль я пытаюсь до всех донести.

А теперь представь, что у тебя столько же памяти, но есть ещё и своп.

Когда не используется то, за что заплачено - да, это неэффективно. Сюрприз?

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

OMG. vm.swappiness - это не проценты.

где пруфы

Есть как минимум один сценарий, в котором своп увеличивает производительность - mc, забытый на vty2, уйдет в своп и освободит немного RAM для кеша или анонимной памяти.

Дожили. Уже mc мешает в памяти. Много места занимает.

Я тебе уже дал ссылку, где поискать. Открыл для себя vm.overcommit_memory (комментарий)

т.е. ты сам не знаешь

Не вызывает рост, он просто не используется.

Чем и вызвает прирост )

Ни своп, ни без свопа не даёт прироста производительности. Производительность может только падать по разному в зависимости от сценария.

Я не собираюсь спорить по терминологии. Назовите это «отсутствием падения производительности», я не возражаю )

Да, я немного ошибся, конкретно про проценты нигде не говорится, есть только про агрессивность, давно читал, подзабыл. Причём чем выше число тем сильнее свопит.

Когда не используется то, за что заплачено - да, это неэффективно. Сюрприз?

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

Ну вот, началось передергивание путем кривых аналогий. Впрочем, если у тебя процессор никогда не используется на 100% - да, ты тоже выбросил деньги на ветер.

То, что нежелательно заполнять ssd под завязку, потому что это ведет к падению эффективности и ускоренной деградации - знаете?

Это очень веский довод за то, что нужно купить RAM больше, чем можно заполнить.

и в дополнение - память. Не надо ее забивать, будет бяка.

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

Уже mc мешает в памяти. Много места занимает.

У тебя mc не занимает места в памяти? Да ты колдун. А про «много» - это ты выдумал.

А теперь представь, что у тебя столько же памяти, но есть ещё и своп.

Представил. Пользы с него нет, разве что когда понадобится сырое экспериментирование с софтом при работающей основной задаче. То есть не при самой разумной ситуации. А на стабильной отлаженной системе - зачем?

Что я не знаю?

То, что нежелательно заполнять ssd под завязку, потому что это ведет к падению эффективности и ускоренной деградации - знаете?

А то, что на ssd всегда есть резервная область, ты не знаешь?

Ну вот, началось передергивание путем кривых аналогий. Впрочем, если у тебя процессор никогда не используется на 100% - да, ты тоже выбросил деньги на ветер.

На каком интервале времени? Вы ведь надеюсь, в курсе, что процессор нагружается до 100% импульсно? Любой. В отличие от памяти. А в среднем - может и до 5% не доходить. Пичалька?

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

Ай-яй. Ну и кто тут, спрашишивается, передергивает?

А то, что на ssd всегда есть резервная область, ты не знаешь?

А то, что ее недостаточно и для продления ресурса рекомендуют не забивать остальное, ты не знаешь?

Впрочем, если у тебя процессор никогда не используется на 100% - да, ты тоже выбросил деньги на ветер.

На каком интервале времени?

2 минуты.

Вы ведь надеюсь, в курсе, что процессор нагружается до 100% импульсно? Любой. В отличие от памяти.

А ты в курсе, что память сохраняет содержимое, которое в нее записано?

и в дополнение - память. Не надо ее забивать, будет бяка.

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

Ай-яй. Ну и кто тут, спрашишивается, передергивает?

Это была ирония. Наверное, слишком тонкая.

А ты в курсе, что память сохраняет содержимое, которое в нее записано?

И что?

Это была ирония. Наверное, слишком тонкая.

Надо же, опередил.

Ну да, всего лишь cgroup2 пишет в ядре. Куда ему до пятизвёздочных с ЛОРа.

А ты в курсе, что память сохраняет содержимое, которое в нее записано?

И что?

Так в курсе или нет?

Кудахчущим про ценнейший файловый кэш и что память не должна быть свободной от него. Риальный пример из жизни, сурового ынтырпрайзного продакшена. Сервер с 24Гб RAM, пишет через 10 гигабитную сеть на NAS видеопотоки с 90 камер. На сервере серверная Убунта. Были жалобы, что не удаляются файлы с NAS, ошибки в логах Device or resource busy и всё такое. Как выяснилось, линупс в своих лучших дефолтных традициях сначала забивал память кэшем до упора, когда память кончалась (что при её объёме происходило далеко не сразу), люто-бешено пытался всё сразу сбросить через сеть на NAS, NAS от нагрузки превращался в тыкву, линупс начинал срать ошибками в dmesg, помогала только перезагрузка. Стоило только примонтировать NAS с опцией nocache, как всё стало шоколадно, внезапно выяснилось, что непрерывная запись без кэша нагружает сеть от силы на 10% (или 1%, не помню уже), память почти вся свободна, система отзывчива, волосы снова гладкие и шелковистые

Уже mc мешает в памяти. Много места занимает.

У тебя mc не занимает места в памяти? Да ты колдун. А про «много» - это ты выдумал.

Это была ирония. Наверное, слишком тонкая.

ядро разные люди пишут, не все они блещут профессионализмом

Так в курсе или нет?

Естественно! Каждый раз перед возможным наступлением врагов я забиваю память из /dev/urandom. Два раза.

Прохладна былина твоя, боярин.

Я-то знаю, я и про over-provisioning в курсе. Но ты тут ещё и про продление ресурса ssd нам рассказываешь, при том, что называешь нищебродами тех, кто использует swap. А я вот называю нищебродами тех, кто экономит ресурс ssd. А вот для сохранения производительности over-provisioning может быть полезен (но не обязательно, зависит от задач).

ты в курсе, что память сохраняет содержимое, которое в нее записано?

И что?

Так в курсе или нет?

Естественно!

«Естественно да» или «естественно нет»?

Но ты тут ещё и про продление ресурса ssd нам рассказываешь, при том, что называешь нищебродами тех, кто использует swap. А я вот называю нищебродами тех, кто экономит ресурс ssd

Я в следующий раз буду поднимать табличку «САРКАЗМ!» Я упомянул первый раз про расход ресурса ssd чтобы было доступнее тем, кто экономит копейки на памяти.

«Естественно да» или «естественно нет»?

Естественно

Я упомянул первый раз про расход ресурса ssd чтобы было доступнее тем, кто экономит копейки на памяти.

А кто так делает? Тебе тут пытаются объяснить, что swap не для этого.

swap и для этого тоже.

А кто так делает? Тебе тут пытаются объяснить, что swap не для этого.

Щас все пойдет по второму кругу. Своп - это вынужденная припарка для тех, кто не имеет возможности использовать ОЗУ достаточного размера. Все. Никаких других предназначений и никаких преимуществ у него нет. Забудьте про ssd, про него говорилось не вам и не с той целью что вы поняли.