LINUX.ORG.RU
ФорумTalks

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

 


6

2

Да, я слоупок: более 5 лет пользуюсь линуксом, даже программист вроде как, и только сейчас обнаружил эти отличные опции для `/etc/sysctl.conf`:

vm.overcommit_memory = 2
vm.overcommit_ratio = 100

Перегрузил опции командой `sudo sysctl --system` и попал прямо в райские кущи. Можно открыть браузер, три IDE и запустить виртуалку Virtual Box - и результатом станет не зависание системы намертво с необходимостью делать hard reset, а просто ошибка в Virtual Box (работа виртуальной машины прервана).

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

А как вы боретесь с традиционным для Linux зависанием намертво при нехватке памяти?

P.S. для справки, настройку выполнял согласно этому былинному посту: http://avz.org.ua/wp/2011/04/24/overcommit-memory/

★★★★

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

Ответ на: комментарий от Black_Shadow

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

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

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

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

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

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

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от quiet_readonly

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

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

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

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

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

baka-kun ★★★★★
()
Ответ на: комментарий от Black_Shadow

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

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

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

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

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

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

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

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

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от baka-kun

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

surefire ★★★
()
Ответ на: комментарий от baka-kun

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

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

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

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

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

Об этом

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

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

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

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

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

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

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

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

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

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

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

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

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

С чего вдруг?

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

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

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

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

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

$ sysctl vm.swappiness
vm.swappiness = 60

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2 минуты.

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

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

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

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

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

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

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

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

И что?

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

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

vaddd ★☆
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И что?

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

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

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

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

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

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

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

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

Естественно

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

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

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

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

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

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

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