Comments 112
Мне было почти ничего непонятно, но свое старое железо я бы вам точно доверила 😉
Интересно, какова вероятность выхватить этот баг на воркер ноде k8s?
Приключалась ли такая беда с нодами и фиксировал ли кто уже это, или там действует принцип "упало-перезагрузили, падает редко - игнорим"?
Проблема-то на новых ядрах в целом решена MGLRU + echo 200 > /sys/kernel/mm/lru_gen/min_ttl_ms (или 500-1000 на HDD) + zram. Даже совсем древнегреческие машины, вроде VIA Nano с 512 МБ RAM, нормально работают в такой конфигурации.
Параметр min_ttl_ms как раз предотвращает вытеснение файлового кеша на X миллисекунд, см. Thrashing prevention в документации MGLRU. Без этого параметра (по умолчанию не включён) MGLRU это просто умный алгоритм определения редкоиспользуемых данных, которые можно выгрузить в swap.
MGLRU с TTL по отзывчивости чуть хуже le9, и может привести к OOM вместо агрессивного своппинга, но его идея в динамических условиях в вакууме лучше, чем банальная блокировка вытеснения файлового кеша фиксированного размера.
А обсуждалась проблема еще с 2009, когда похожий патч добавили в ChromeOS, потому что на бюджетном железе того времени без swap'а всё зависало: https://lore.kernel.org/lkml/20101028191523.GA14972@google.com/
Больше обсуждения здесь: https://lore.kernel.org/lkml/20211130201652.2218636d@mail.inbox.lv/, и в ревизиях MGLRU.
Проблема-то на новых ядрах в целом решена MGLRU
"В целом" и решена - разные вещи, 14 патчей со сложной логикой плюс "32Гб хватит на всех" в качестве обоснования отказа от дальнейших изысканий как-то не внушают доверия.
Ну и повторюсь: статья вообще появилась на свет как раз после зависания на 6.x ядре с этим самым MGLRU. Так-то я тоже думал что проблема давно решена.
Даже совсем древнегреческие машины, вроде VIA Nano с 512 МБ RAM, нормально работают в такой конфигурации.
Работают в том смысле что запускаются - да, выдерживают ли описанную нагрузку - сомневаюсь. Хотелось бы увидеть в действии.
Ну, так, вы включали ttl в MGLRU? Без него он не устраняет thrashing, что вы называете зависанием.
Users can write
Ntomin_ttl_msto prevent the working set ofNmilliseconds from getting evicted
Ну я же написал: l9ec патч хорош своей простотой - он 100% с гарантией решает проблему, а тут лишь настройка на какое время защищать working set.
И нет 200ms не ставил, но судя по описанию проблему это решает "в общем виде", те ситуация с live lock продолжает быть возможной.
l9ec патч хорош своей простотой
В этом и его проблема — его необходимо настраивать.
Есть у нас десктоп с 2ГБ RAM, какой объём файлового кеша блокировать? 64 МБ почти никакого эффекта не дадут, 512 МБ явно многовато.
Запускаем в основном жирные программы, которые загружают жирные библиотеки? Нужно поставить побольше, иначе всё равно будет пробуксовка, хоть и не настолько выраженная — выгрузится какой-нибудь Xorg или pixmap'ы, и пока данные будут восстанавливаться из свопа или перечитываться из диска, десктоп «зависнет» (критические для отрисовки данные/код не будет доступен).
Выгрузится у условного Firefox'а библиотека, которая нужна раз в секунду, и в эту же секунду начнёт что-то другое свопится, то FF зависнет — поток будет ждать, пока не появятся необходимые данные.
А если у нас не компьютер, а роутер с 128 МБ, из которых 70 МБ занято файловым кешем? Ему что важнее: данные или код? Абсолютно всегда, в любой момент времени?
le9 требует от вас решить этот вопрос.
А MGLRU работает во временном домене: он знает, что использовалось совсем недавно, и понимает, что это нужно всеми силами не скидывать в своп.
l9ec 100% с гарантией решает проблему
Только если вы знаете, что вы запускаете на своем компьютере, и подобающе настроили le9.
В этом и его проблема — его необходимо настраивать.
Так сама ситуация нестандартная, конечно ее решение требует настройки.
какой объём файлового кеша блокировать?
Если я правильно понял идею - объем физической памяти не так важен, важна схема ее использования, т.е теоретически live lock можно словить и на 32Гб.
А l9 просто блокирует от выгрузки фиксированный объем памяти, которого должно быть достаточно для отработки ООМ-киллера.
А MGLRU работает во временном домене: он знает, что использовалось совсем недавно, и понимает, что это нужно всеми силами не скидывать в своп.
Угу наперегонки с Garbage Collector в Java и Node.js. И хромом, который их обоих заранее обгоняет )
Проблема: thrashing (пробуксовка), или live lock, происходит тогда, когда несколько программ борются за оперативную память при её недостатке, что выливается либо в агрессивное сбрасывание файлового кеша из оперативки, чтобы загрузить данные из swap, либо наоборот, к срочной загрузке файлов с диска в кеш, потому что они нужны программе для её работы (программный код, в самом распространённом случае).
В общем смысле thrashing возникает, когда процессы так сильно конкурируют между собой, памяти так мало, а диск такой медленный, что ни один из процессов не может выполнить осмысленную работу в отведённый ему момент времени: система только и занимается, что пытается сбросить файловый кеш (особенно код) одной программы, чтобы загрузить данные другой программы, а тут уже подходит время передать управление первой программе, нужно загрузить её программный код и её данные, и так по кругу. Особенно худо, когда одна из программ каждый раз выделяет всё больше и больше памяти и работает с ней.
Но с точки зрения пользователя thrashing случается также когда система неотзывчива по привычным для пользователя интерфейсам: для десктопа это отсутствие перерисовки изображения на экране или отсутствия отклика на переключение программ или открытия меню (например, выгрузился файловый кеш (код) xorg, wayland, библиотек qt или gtk: так-то программы работают, плеер даже может продолжать играть музыку без перерыва, только пользователю от этого не легче), для сервера это невозможность подключиться по SSH или использовать основное ПО (bash в SSH-сессии, например), потому что код работы с памятью решил, что postgresql, который очень активно использует оперативку и диск и разом записал 10 ГБ данных, которые оказались во writeback-буфере, очевидно, гораздо важнее SSH-сессии.
Решаем проблему: ограждаем X мегабайт файлового кеша от сбрасывания: это то, что делает le9. Просто не дадим какому-то количеству произвольного файлового кеша выгружаться, в каждый момент времени разному (такому, какой важен по мнению существующего алгоритма LRU по работе с памятью). Какое это количество — решать пользователю, в зависимости от того, какой он использует софт, сколько он запускает разных программ и насколько ему важнее файловый кеш перед данными — от этого зависит время переключения между программами (latency).
Такой подход предотвращает жесткий thrashing (даже несколько десятков мегабайт заблокированных данных почти наверняка не приведут к бесконечному циклу — всё будет тормозить и откликаться по нескольку секунд, но не «зависнет»), но для эффективной работы требует установки значения с пониманием сценария работы, жирности софта, количества оперативки, и т.п.
Решаем проблему: ограждаем файловый кеш от сбрасывания на X миллисекунд: это подход MGLRU TTL. Пользователь прошлые 100 мс активно работал с такими-то данными в памяти, и у нас ну очень мало оперативки? Не вымещаем их из оперативки следующие 100 мс.
Эффективно? Так себе. Зато тоже работает, не требует тонкой настройки, и часто обеспечивает достаточно низкий latency (явно лучше, чем le9 с низкими значениями), но может приводить к OOM программ, которые пытались выделить память в эти X мс и не смогли (актуально при больших значениях ttl, от 500 мс и более).
Добавлю два важных момента:
я не ограничивал целенаправленно память (как это делал автор патча) и не отключал своп, но тем не менее словил live lock на MGLRU и 8Гб памяти + 16Гб свопа.
все диски только SSD, те со скоростью I/O все хорошо.
Напоминаю в третий раз: MGLRU без параметра min_ttl_ms (по умолчанию отключён) никак не противодействует thrashing. Это просто альтернативный, более умный, менеджер памяти.
Ладно, уговорили: действительно проверю с этим параметром и отпишусь.
Вообще я рассчитывал что в Xanmod он по-умолчанию включен и настроен, но почему-то не вижу патчей имеющих отношение к MGLRU в репозитории c 6.14 веткой.
Если этот параметр так важен почему он не включен по умолчанию? Или есть подозрения, что с ним не все так гладко?
Как найти опцию MGLRU TTL в конфигураторе ядра? Поиск по TTL не даёт ничего релевантного :(
В целом, можете посоветовать настройки ядра/sysctl для десктопа с максимально высоким откликом и при этом без сильных просадок по производительности? У меня Gentoo, изгаляться можно очень свободно.
Ещё такой вопрос, не совсем по теме. У меня после игры в нативные игры бывает, что остаются занятыми 4-5 ГБ оперативки, при этом никак не детектятся через менеджеры процессов. С виндовыми играми через PortProton такого не бывает, а вот с нативными - пожалуйста. Есть ли способы как-то отловить такую утёкшую память и высвободить её, не прибегая к ребуту системы?
Так сама ситуация нестандартная, конечно ее решение требует настройки.
Все стандартные значения параметров ядра устанавливаются, ориентируясь на серверные сценарии использования. Мне на десктопе, например, больше 30-40 МБ еще не записанных на диск данных, но уже находящихся в оперативке (dirty/writeback) только во вред, а Linux по умолчанию устанавливает это значение в 10% от количества оперативной памяти — 3.2 ГБ на 32ГБ RAM.
С моей точки зрения это совершенный абсурд, но, видимо, кому-то норм. У меня несколько раз начинался thrashing из-за этой стандартной настройки :P
А если у нас не компьютер, а роутер с 128 МБ, из которых 70 МБ занято файловым кешем?
Вообще тут уже начинается embedded с совершенно другими правилами игры: система загружается с прошивки и в read only, память фиксированная и все приложения запускаются сразу при запуске.
Поэтому никакой live lock не возможен в принципе - приложения просто никогда не выгружаются за время работы.
Я в 2021 году проводил тест le9 на следующей машине:
Типичный офисный компьютер тех времён:
Материнская плата Gigabyte GA-945GCM-S2L (ранний сокет LGA775, встроенное видеоядро GMA950, сентябрь 2007)
2-ядерный 64-битный процессор Intel® Core™2 Duo E4600 (2 ядра, 2.4 ГГц, конец 2007)
2 ГБ оперативной памяти (DDR2 667 МГц, одним модулем)
Жесткий диск 160 ГБ Samsung HD161HJ (SATA II, июнь 2007)
Без дискретной видеокарты
Результат работы тестового компьютера после всех настроек
Одновременно запущены:
Firefox с 37 активными вкладками (все данные в RAM, без выгрузки, всё честно)
Discord
Skype
LibreOffice с открытым документом
Два PDF-файла (размером 14 и 47 мегабайт)
…и всё это при 2 ГБ оперативной памяти. Впечатляет?
Если le9 делает чудеса просто в силу жесткой блокировки большого количества файлов, то с MGLRU + 1000 ms TTL, который я выполнил на таком же тесте спустя несколько месяцев, было похуже в силу очень медленного HDD (2007 года, это не современные с линейным чтением под 200 МБ/с) и какого-никакого вытеснения, но приемлемо.
А min_ttl_ms гарантировано решает проблему или только в большинстве случаев? Если за условные 200мс OOM killer не успеет отработать, то будет такое же вечное зависание?
если произошло зависание(всё произошел стоп-кадр, произошел зависон) нету магии, надо перезапустить сессию и закрыть все программы пользователя, вот кратко что должно быть, и убунта +- так и делает и фрибсд
другой вопрос как диагностировать почему утечка памяти происходит, значит либо чтото отвалилось в ПО и надо пересобрать или что-то еще, тоесть софт должен соответствовать инструкциям где он запускается минимум
Один из вопросов к автору патча в LKML так и остался неотвеченным с его стороны. В патче добавляются три числа-параметра. Как подобрать для них разумные значения? Просто взять из головы 50 Мб слишком топорно, особенно если у тебя на самой железке всего 64 Мбайт.
Как подобрать для них разумные значения?
Полагаю что только тестами. Именно для этого параметры и нужны.
Всё, что требует ручной настройки, и на что нельзя задать default, будет отключено по умолчанию, и будет иметь единицы пользователей. Это основная претензия к le9 в lkml.
Это основная претензия к le9 в lkml.
я тоже заметил, что в обсуждении сразу начался официоз в стиле "Хабра и знаков пунктуации" и первые же ответы автору были не по существу а по оформлению.
Ну что тут скажешь: видимо не зря я столько лет использую BSD.
А все потому, что автор патча не решает проблему, а купирует симптомы, на что ему много раз было указано, мягко и не очень.
Решение из патча и правда применимо в определенных случаях, но оно выглядит очень похожим на "поскольку malloc может вернуть NULL, давайте сразу при старте исполняемого файла выделим кусок в 50 мегабайт, авось больше NULL мы не увидим". В этом примере ровно та же проблема - а почему вообще 50, как это подобрать? А если мало? А если слишком много и память простаивать будет?
Если убрать упражения в софистике, то ваша претензия тоже сводится к необходимости настройки.
Когда на одной чаше весов зависание системы и полная неработоспособность а на другой - разовая настройка под задачу, неужели вы думаете что оно того не стоит?
Кривое решение или нет - оно работает, если сам Линукс это "кривое поделие" согласно архитектурным идеям профессора Таненбаума, создателя Minix - вам не все равно кто из этих далеких инженеров прав?
Вообще это конечно огорчает, что необходимость тюнинга и настройки ныне считается у линуксоидов плохим тоном.
Так в итоге правильное решение было найдено: MGLRU + 1000 ms TTL. В таком варианте оно как минимум делает не хуже всем, а в подавляющем большинстве случаев - лучше. И причем оно основано не на второстепенных метриках навроде "осталось свободной памяти" или "эмперически прибъем 50 мегабайт", а на основной и самой заметной - "система буксует уже 1000 мс".
особенно если у тебя на самой железке всего 64 Мбайт.
Если вы действительно завели 6.х ядро на 64 Мегабайтах памяти - думаю стоит писать отдельную статью. Тут уже все эти приседания с MGLRU неактуальны, поскольку удивляет даже сам факт такого запуска вообще.
Самое нижнее что у меня получалось это старый Дебиан на P2 400 и 128 Мб памяти, 4.х ядро и работало оно еле-еле.
6.х версия и на 64Мб вызовет фурор.
Linux запускают не только на персоналках, и не только на x86. Посмотрите на OpenWRT, оно на версии 6.x с удовольствием работает на таких устройствах. И там может даже быть запущен transmission.
Не очень понимаю зачем вам в таком случае что l9 что MGLRU, тут же другая схема работы: приложения запускаются разово и никогда не выгружаются.
Вы умудрились словить live lock на OpenWRT чтоли?
На OpenWRT очень многие приложения запускаются и завершаются постоянно, потому что базовая система буквально состоит из мелких утилит, и любое брожение по Web-интерфейсу постоянно их дергает в фоне (это я уж не говорю, что веб там на основе CGI, то есть каждый новый http-запрос - это новый процесс).
musl_vs_glibc посмотрите это советовать не буду, но когда юзал генту слышал об этом
спасибо интересно ( я ничего не понял ), подождите на подходе выпил X11 и ввод Wayland на постоянку, жду новых багов, давно это понял
tl;dr есть проблема, для её решения предложен механизм, который пользователи должны настраивать самостоятельно (т.к. выработать некие дефолтные значения, подходящие всем, не получится), поэтому разработчики ядра отказываются принимать этот механизм и реализовали другое решение, не требующее тонкой настройки, всё это сверху приправлено пассажем про "особенных" разработчиков
реализовали другое решение, не требующее тонкой настройки ...
но выключенное по умолчанию
приправлено пассажем про "особенных" разработчиков
В целом по делу приправлено. Пробема-то по дефолту остается.
обзор от ИИ это написал
Скрытый текст
OOM Killer (Out-of-Memory Killer) - это механизм ядра Linux, который срабатывает, когда система испытывает критическую нехватку оперативной памяти (RAM). Он предназначен для предотвращения полного выключения или зависания системы, принудительно завершая определенные процессы для освобождения памяти.
Как работает OOM Killer:
1. Идентификация процесса:
Когда система приближается к полному исчерпанию памяти, OOM Killer начинает анализировать все запущенные процессы и оценивать их "негодность" (badness), то есть, насколько сильно они используют память и насколько важны для системы.
2. Завершение процесса:
OOM Killer выбирает процесс с наименьшей полезностью и отправляет ему сигнал SIGKILL для принудительного завершения.
3. Освобождение памяти:
Освобожденная память возвращается в ядро системы и может быть использована другими процессами.
Почему это происходит:
OOM Killer срабатывает, когда система пытается выделить больше памяти, чем доступно. Это может происходить по нескольким причинам:
Слишком много процессов:
Запущено слишком много приложений, которые требуют значительного объема памяти.
Выделение памяти:
Программа пытается выделить большой блок памяти, и система не может предоставить ее.
Утечка памяти:
Программа имеет утечки памяти и потребляет все больше и больше памяти со временем, вызывая ее исчерпание.
Пример:
Представьте, что у вас запущено несколько программ, потребляющих большую часть RAM, и одна из них пытается открыть очень большой файл. Если системе не хватает памяти для этого, OOM Killer может завершить менее важный процесс, например, фоновое приложение или браузер, чтобы освободить память для выполнения операции.
Преимущества:
Предотвращение крашей:
OOM Killer помогает избежать полного выключения или зависания системы, когда память исчерпана.
Удержание работоспособности:
Даже если OOM Killer завершит процесс, другие процессы могут продолжать работать, хотя и с меньшей скоростью.
Недостатки:
Некорректное завершение:
Принудительное завершение процесса может привести к потере данных или другим проблемам, если процесс не успел сохранить изменения.
Идентификация процессов:
Если система не может правильно определить приоритет процессов, OOM Killer может убить важный процесс, что приведет к сбоям.
Когда следует обращать внимание на OOM Killer:
Если OOM Killer часто срабатывает, это может свидетельствовать о нехватке памяти в системе. Нужно:
Проанализировать, какие процессы потребляют наибольший объем памяти.
Удалить ненужные программы или процессы.
Увеличить объем RAM.
В целом, OOM Killer - это важная часть системы безопасности Linux, которая помогает предотвратить полный коллапс системы при недостатке памятии там еще название ctl vm_tbl[]
поидее это виртуальная таблица процесса? чтоли
это и не понял, но теперь чуть чуть понял по крайней от обзора ИИ по ООМ, кароче получается из-за старого пк, не происходит handle в долгую и он просто закроет процесс как я понял причем по какому-то payload тоесть по какому-то принципу выберет процесс, который закроет
я когда ошибался с некоторым кодингом видел переполнение всей системы ПК стоял гном, тоесть выглядит это так, происходит переполнение памяти, заполняется своп на полную стоп-кадр, далее убунта либо автокиляет это, либо если нету такого функционала надо перезагрузиться, помойму иногда даже если убунта вернёт стол, Иксы покажут смайлик мол перезагрузитесь чтобы восстановить Иксы, только с таким встречался
Intel-Core-2-Stalls-Boot-Fix старый пк с 6.14, а оно соберется вообще тоже интересно, я генту собирал под неттоп(еще хуже чем кор 2 дуо) лет 6 назад только. щас не проверял это всё переболел )
вот еще это ИИ не знаю так ли это
Скрытый текст
The use of unwind tables in GCC can contribute to out-of-memory (OOM) errors, particularly in scenarios involving extensive use of exceptions or stack unwinding. Unwind tables, generated by the -funwind-tables option (enabled by default), store information necessary for stack unwinding during exception handling or debugging. While essential for these functionalities, they can consume significant memory, especially in large applications with deep call stacks or frequent exceptions.
When an OOM error occurs due to unwind tables, it indicates that the memory required to store this information exceeds the available system resources. This situation can arise in resource-constrained environments or when compiling code with many functions and complex control flow.
To mitigate OOM errors related to unwind tables, consider the following approaches:
Disable unwind tables:
The
-fno-unwind-tablesoption prevents the generation of unwind tables, reducing memory consumption. However, this disables exception handling and may hinder debugging capabilities. It is suitable for applications where exceptions are not used and debugging is not a primary concern.Optimize code structure:
Reducing the depth of call stacks and minimizing the use of exceptions can decrease the size of unwind tables. Refactoring code to simplify control flow and avoid unnecessary function calls can be beneficial.
Increase memory limits:
If feasible, increasing the available memory for the compilation process can prevent OOM errors. This may involve adjusting system settings or using a machine with more RAM.
Use Position Independent Code (PIC):
When compiling for shared libraries using the
-fPICflag, the compiler generates code that accesses constant addresses through a Global Offset Table (GOT). This can sometimes influence the size and structure of unwind tables. Experimenting with or without-fPICmight yield different memory usage characteristics.Link-Time Optimization (LTO):
Enabling LTO can help the compiler to better optimize the code and reduce the size of the final executable, possibly also impacting the size of unwind tables.
The choice of approach depends on the specific requirements of the project. If exception handling and debugging are crucial, disabling unwind tables is not an option. In such cases, optimizing code structure or increasing memory limits may be necessary.
но вообще тут напрашивается момент почему запуская переполнение оно не определяется и не киляется переполнявший процесс, а вместо этого киляется процесс на бэкграунде, ну типо потомучто тогда будет не открываться браузер(что-то такое, тогда браузер надо компилировать определенным образом получается), а перед этим компилировать компилятор как-то что-то такое
и уже этим компилятором всё перекомпилировать ( тоесть это еще musl возможно читать придётся как оно работает
Надо было ещё упомянуть swap, zram, zswap. Насколько это подходит под решение проблемы.
У меня 16 гиг оперативы и когда пересел на линукс, сразу с зависанием столкнулся, потому что в винде на квм нужно было работать параллельно с софтом. qemu + ide + браузеры для разрабротки с несколькими вкладками + ютубчик = усё.
Решил проблему сначала с увеличением swap, а потом ещё zswap добавил для сжатия. Грубо говоря, добавил большое количество виртуальной памяти.
Надо было ещё упомянуть swap, zram, zswap. Насколько это подходит под решение проблемы.
В ситуации когда есть мощный CPU и мало памяти - наверное да, стоит использовать. В моем случае когда вся машина целиком из 2007 года (второй тест) - мне просто стало жалко.
На видео слышно как сильно она жужжит под нагрузкой, если включить еще и сжатие памяти, вой был бы постоянным.
Ну и думаю очевидно что про любую работу от батареи в случае zram придется забыть.
Машина аналогичного 2007 г. с 2 ГБ ожила благодаря zswap.
Там очень шустрые алгоритмы используются для сжатия. Проц не должен загружаться. Где читал про эти решения - там именно дохлые машины использовались.
Тут затык может быть только в медленом диске, например hdd. Вот тогда подтормаживать будет если zswap. Но в этом случае zram можно использовать.
Смартфоны это используют на постоянку. Особенно эппл.
Upd: виноват. Перепутал с zram
Вышеописанная проблема меня действительно поражает, ибо сам часто с нею сталкиваюсь. Одна заглючившая программа, которая пытается выделить бесконечное количество памяти, вешает всю систему. UI перестает обновляться и даже курсор мыши не двигается. Починить это можно или перезагрузкой нажатием на кнопку выключения компа, или (в редких случаях) переключением в консольный режим с убийством из консоли глюканувшей программы.
Подобное поведение явно нарушает основное требование к ОС - изоляцию процессов друг от друга. Если один глючный процесс может фактически приостановить работу всех остальных, то изоляция явно поломана.
Ещё кажется странным, что процессы пользовательского интерфейса не имеют какого-либо особого приоритета и защиты от выгрузки их памяти в своп, что кажется весьма странным. По-хорошему базовый UI и пара важных программ ( вроде аналога диспетчера задач ) должны быть избавлены от выгрузки, чтобы в случае чего пользователь мог убить глючный процесс.
Вообще, меня поражает, что почему-то где-то ещё используется своп. Зачем он нужен при наличии более 2 Гб памяти? Если память какой-то программы туда выгружается, то программа становится жутко-медлительной до полной неработоспособности. Зачем тогда это нужно, не проще ли сразу начать убивать процессы, если память кончается, чем делать по факту то-же самое, но долго и мучительно с насилованием жёсткого диска?
Я тоже сталкивался и не раз, самое частое запущена IDE идея, и собираешь проект на плюсах. и у меня было 20+ оперативы. Система виснет намертво в какой-то момент и все. Не тормозит.. А ответ разработчиков ядра вполне показательный, собственно так по стабильности ядро и ощущается.
Вы смотрите очень поверхностно.
Вот вам намеренно "грубый", "широкими мазками" пример. Некий "веб сервер", "условный nginx" при запуске всегда загружает в память код всего "core" + нескольких модулей, которые слинкованы статически "потому что обычно почти все их всё-равно используют". Для какого-то применения с большим количеством сложных динамических сайтов это оправдано на все 100%, да там ещё и динамические модули подгружаются в большом количестве. А для функционирования маленького статического сайта визитки достаточно, условно, 10% функционала core. И зачем тогда весь код core и статически слинкованых модулей держать в оперативной памяти? В свопе им самое место. Так понятнее зачем своп?
А ещё есть код, который таки вызывается, но очень редко. А есть ещё данные, обращение к которым тоже происходит не часто, но их тоже имеет смысл как-то хранить в уже полученном из источника и "предобработанном" виде. И т.д., и т.п..
Слишком искусственный пример. Сколько там этого кода, который не используется? Несколько мегабайт?
Да и в своп его пихать не надо. Код то грузится из исполняемого файла, который на диске есть, а значит его можно по необходимости из этого файла грузить.
"Чистый" pagecache в своп и не выгружается. Либо "грязные" страницы, которые после чтения изменились, но ещё не были записаны на диск, либо анонимные страницы. Выгружать в своп то, что просто можно прочитать с диска смысла немного.
Перечитайте внимательно, я не о коде, который потребуется подгрузить позднее [и это действительно можно было бы сделать и с диска], а о коде, который никогда не понадобиться, но при старте программы в любом случае будет загружен. Что с ним делать? ОС не знает, что он не понадобится никогда.
Пример намеренно упрощённый, что бы объяснить концепцию.
Хотите другой пример?
Для анализа "неведомой хрени" вам нужна отформатированная выборка каких-то данных из СУБД. Но обращаетесь вы к ней всего несколько раз в день с интервалом полчаса, не меньше. Держать её в памяти все время, не запуская никаких других программ? Запускать другие программы, но скрестить пальцы в надежде, что OOM убьёт менее ценные программы, но не эту с выборкой? Каждый раз делать запрос по LAN к серверу СУБД, пусть по SAN выкачивает с СХД гигазы данных, обрабатывает/выбирает их и шлёт вам назад так же по Сети для финального форматирования на вашем компе? Точно это лучшее решение, чем вытеснить неиспользуемые странички в своп на полчаса?
Повторюсь, я действительно упрощаю и загрубляю примеры, для наглядности. В жизни [в IT] всё обычно намного сложнее и все ситуации во всей красе и представить невозможно, пока не столкнёшься лично.
Есть подозрения, что и в линуксе, неиспользуемые сегменты кода не грузятся в оперативку.
Но там какие то родовые травмы с elf мешают
По-хорошему базовый UI и пара важных программ ( вроде аналога диспетчера задач ) должны быть избавлены от выгрузки, чтобы в случае чего пользователь мог убить глючный процесс.
Это давно есть. Но в виндовс, кажется с nt 4.0
Тут вопрос дискуссионный, насколько оно там есть. Помню, как на Windows XP (это nt 5.1) после запуска какой-нибудь тяжёлой игры рабочий стол нерабочим был - иконки пропадали, части панели задач не отрисовывались, кнопки не нажимались и т. д. Надо было ждать, видимо когда там что-то из свопа обратно в оперативку попадёт. Но вот в более новых Windows я лично такого уже не замечал, видимо там уже совсем нормально сделали.
Windows 10 запросто пригрохнет весь dwm.exe. Потом только по журналу можно догадаться, что произошло. Не путать с приоритетом планироащика процессорного времени, полагаю этим достигается побочный эффект "отзывчивее" в таких ситуациях.
Вообще, меня поражает, что почему-то где-то ещё используется своп. Зачем он нужен при наличии более 2 Гб памяти?
Потому что без него была бы простая вилка: хватает свободной памяти - запускаем программу, не хватает - не запускаем.
Для времен DOS это наверное было оправдано, но сейчас когда даже каждая вкладка в Хроме - отдельный процесс (без специального тюнинга) а под каждой программой свой garbage collector с пулом памяти - у вас никакого выбора собственно и нет.
Либо много физической памяти, либо своп, либо не работаем вообще.
Ну и диски сейчас быстрые, так что нет проблем использовать подкачку. SSD это не ATA на 5400 RPM :)
не хватает - не запускаем.
Звучит логично. Это лучше, чем насиловать постоянно диск и иногда вешать систему.
Либо много физической памяти
Для нормальной работы даже 8 Гб физической памяти - это очень даже много. Но если какая-то программа глючит и требует бесконечное количество памяти, то физической памяти конечно не напасёшься.
даже каждая вкладка в Хроме - отдельный процесс
Ну и? Если памяти мало становится - система сообщает процессу, что неплохо было бы прибраться и почистить память. Если не помогло - грохаем процесс вкладки. Это лучше, чем вешать всю систему.
Ну и диски сейчас быстрые
Проблема подкачки ещё и в том, что она работает по запросу. Если в своп улетело скажем 1000 страниц, то выкачиваться они оттуда будут поштучно, после каждого обращения процесса к памяти, которая была выгружена. Из-за этого процессы могут десятками минут отходить, после того, как их память была выгружена в своп. Ускорение диска тут особо не поможет.
Для нормальной работы даже 8 Гб физической памяти - это очень даже много.
Очень смелое утверджение. Попробуйте например видеомонтаж, быстро поймете зачем ставят по 128Гб физической памяти и ускорители.
Ну и? Если памяти мало становится - система сообщает процессу, что неплохо было бы прибраться и почистить память.
А если процесс не может или не хочет?
Если не помогло - грохаем процесс вкладки. Это лучше, чем вешать всю систему.
А если там шла работа? Сейчас даже у 1С веб-интерфейс является основным, люди в браузере работают а не котиков смотрят.
Вообще концепция OOM-Killer осмысленна только на сервере и то с оговорками - если нет например тяжелых расчетных задач, которые месяцами крутятся. Где падение такого процесса = потеря результата работы за день/месяц/год.
На десктопе где 90% софта - тяжелое и сложное нечто со сложным интерфейсом - это вообще никогда правильно работать не будет, тк убиваться будут самые используемые приложения.
OOM это не решение и додуматься убивать процессы принудительно могли только линуксоиды, в BSD почему-то такого нет. И как-то живем до сих пор.
Почему в линуксе сразу не пошли по пути защиты working set и лепили все это время заплатки в виде OOM - видимо влияние Android, где такой watchdog осмысленен, поскольку сам концепт завершения приложения скрыт от пользователя. Обратная сторона универсальности и влияния спонсоров.
Из-за этого процессы могут десятками минут отходить, после того, как их память была выгружена в своп.
На видео со вторым тестом видно, что при физических 2.5Гб есть еще 14Гб свопа, 3 из которых используются. Никаких "минутных задержек" нет и в помине - можете сами убедиться.
Попробуйте например видеомонтаж, быстро поймете зачем ставят по 128Гб физической памяти и ускорители.
Не всем нужен видеомонтаж. Я вот, например, в основном код пишу. 8 Гб хватает. Игры многие тоже не жрут столько памяти (я в сильно новые игры не играю).
А если процесс не может или не хочет?
Будет убит. Обычно, если процесс не хочет, он не совсем в порядке.
А если там шла работа?
Нормальные программы имеют автосохранение, чтобы в случае сбоев (вплоть до отключения электричества) много результатов работы не потерять.
люди в браузере работают а не котиков смотрят.
Не хватает памяти на интерфейса в 1С? Сомнительно. Только если в фоне открыты как раз множество вкладок с котиками. Если до того доходит, что ОС убивает нужные вкладки, то пользователь должен закрыть ненужные.
На десктопе где 90% софта - тяжелое и сложное нечто со сложным интерфейсом - это вообще никогда правильно работать не будет
Сильное утверждение. С чего бы большинство софта не будет работать? Мало какая программа требует много памяти, если только не происходит работа с чем-то тяжёлым. В этом случае пользователю рекомендуется закрыть те программы, которые ему сейчас не нужны. Он лучше знает ведь, что ему нужно, чем ОС, которая будет пытаться угадывать, что нужно в своп пихать.
в BSD почему-то такого нет. И как-то живем до сих пор.
А что она делает, если программы исчерпали всю память? Я как-то не вижу альтернативы, кроме как убить какой-то процесс. Можно конечно насиловать своп, но зачем, если это равносильно зависанию ситсемы ну или по крайней мере отдельных программ?
Нормальные программы имеют автосохранение, чтобы в случае сбоев (вплоть до отключения электричества) много результатов работы не потерять.
Ага ага, сразу с принудительной записью на диск и минуя все виды кеширования. По нажатию каждой клавиши.
Если до того доходит, что ОС убивает нужные вкладки, то пользователь должен закрыть ненужные.
Кому должен? Пользователь внезапно работает и убийство его рабочей программы = простой и потеря денег.
Еще вы видимо не очень понимаете масштаб: каждая вкладка это фактически копия браузера, с движком отрисовки и CSS/JS внутри. Поэтому и происходит эпический отжор ресурсов современными браузерами, не потому что сайты плохие.
С чего бы большинство софта не будет работать?
Вы же занимаетесь программированием? Так вот OOM легко и просто убивает например процесс компиляции, особенно если проект большой или используется современный язык типа Rust/Swift или описанные в статье Node.js+Webpack.
Т.е. ООМ берет и убивает ваш основной инструмент работы.
А что она делает, если программы исчерпали всю память?
У нас как раз есть защита ключевых процессов специальными флагами:
P_PROTECTED 0x100000 Do not kill on memory overcommit
Все же разработкой BSD занимаются более адекватные инженеры чем в линуксе, что не может не радовать.
Ага ага, сразу с принудительной записью на диск и минуя все виды кеширования. По нажатию каждой клавиши.
Ну не напрямую, и не на каждое нажатие. Но автосохранение раз в 5 минут - норма. В принципе не страшно потерять результат работы пяти минут.
Пользователь внезапно работает и убийство его рабочей программы = простой и потеря денег.
Если пользователь смотрит в фоне видео с котиками и из-за этого памяти не хватает и рабочая программа падает - сам дурак. Как вариант - на рабочую программу не хватает памяти и надо купить больше плашек. Со мной кстати так было как-то раз, компиляция рабочего проекта стала много памяти жрать и всем программистам памяти докупили.
каждая вкладка это фактически копия браузера
Каждый процесс переиспользует те же физические страницы, где хранится код браузера. Но данные да - у каждой вкладки свои. Не вижу ничего плохого в том, чтобы убить вкладку, отжирающую чрезмерно много памяти.
Так вот OOM легко и просто убивает например процесс компиляции
Так и хорошо же! Значит надо ненужные программы закрыть, собирать меньшим количеством потоков и т. д. Всяко лучше, чем лезть в своп и тем самым полностью вешать систему. Второе у меня лично случается часто, ибо OOM-Killer в системе как-то криво настроен и он не делает свою работу вовремя.
защита ключевых процессов специальными флагами
Ну хорошо, важная программа не будет убита. А неважная значит будет убита? А где прописана, какая программа важная, а какая нет? Пользователь может пометить нужную ему программу как важную?
Вы пошли совсем в религию, забывая о фактах.
В Linux можно настроить oom score так (поставив значение в -999), которое по сути означает то же самое, что и P_PROTECTED. Никто не мешает.
Ну и еще в Linux есть PSI. Я понимаю, что нужно писать код и вообще разбираться, но "поймать" разные градации состояния, когда с памятью становится туго в целом несложно - через PSI можно ловить их еще на подлете. И нормальная IDE вполне может это делать, запуская автосохранение в таком случае.
В Linux можно настроить oom score так (поставив значение в -999), которое по сути означает то же самое, что и P_PROTECTED. Никто не мешает.
Вот тут не знаю что сказать, прямого аналога OOM в BSD нет, соответственно нет и аналогичного поведения - с помощью oom_score устанавливается приоритет как раз для OOM Killer.
И нормальная IDE вполне может это делать, запуская автосохранение в таком случае.
Но каким-то образом такое использование ни разу не видел. У вас есть примеры IDE где действительно такое используется? Было бы интересно поглядеть на код.
Довольно забавно, что последние версии Windows вообще крайне погано существуют без своп-файла. У меня нынче 64 Гб оперативки на домашнем ПК под Win11, и я отключил файл подкачки. Так по достижении 80% заполнения RAM, приложения начинают выхватывать OOM-исключения. Иногда доходит до полного зависания самой ОС. Ну ёлки-палки, ну Микрософт...
поидее не 2 гигабайта, а 4+ не 4 гигабайта свопа а 32 гигабайта, не ext4, а zfs(но на линуксе на старом пк я не знаю как zfs работает), и сегодня надо как-то собирать с ключами(или искать дистрибутив где всё поддерживается из коробки), чтобы всё было отключено(соотв настройка должна быть другой), и это всё настраивать не хочется...
но вопрос зачем, потомучто на старом пк у процессора есть частота и инструкции, апи растут и требования к частоте растёт возможно(не точно) тоесть требуется скорость, а на старом железе её нету, пропорционально новому, соотв ДЕ на 2000 года девайсе будет текстовый, если он еще запустится
сюда еще драйвера и прочее, тоесть это надо поддерживать в актуальном состоянии(зависимость кода по инструкциям, которые вероятно начинают отлетать или еще что-то перестаёт работать)
еще этот переход на wayland и много чего еще видимо
своп. Зачем он нужен при наличии более 2 Гб памяти?
32Гб не гарантируют отсутствие зависаний (
Не знаю по обозначенной причине или из-за чего то другого, на прошлой системе (ubuntu20.04) у меня периодически происходило полное зависание. Выглядело это как стоп кадр и даже аудио зависало на каком то тоне (по bluetooth). Лечилось только перезагрузкой. Причину так и не нашёл (не большой специалист). Когда вместе с системой обновил и ядро, зависания почти пропала (3 за пару месяцев). Вариант использования - IDE с парой проектов, куча окон/вкладок firefox. 32Гб ОП + такой же swap на ssd. Сейчас по совету из комментариев изменил /sys/kernel/mm/lru_gen. Посмотрим. Надеюсь поправиться. Мне удобнее когда система не перезагружается неделями (только hibernate)
Вон оно что. Постоянно с этим сталкиваюсь, раз в несколько дней приходится вырубать компьютер кнопкой питания после того как все виснет намертво. Память выжирает в основном Firefox, в котором она безгранично течет, о чем разработчики тоже совершенно не парятся...
Попытаюсь потыкаться в lru_gen.
я тоже с firefox в какой-то момент испытывал проблемы утечки памяти.
пока не решил отследить средствами самого же firefox потребление памяти каждой его вкладки (goto about:memory), и обнаружил пару закрепленных вкладок, на которых постоянно росла утилизация памяти даже без активного использования самой вкладки (видимо какие-то JS-скрипты там постоянно крутились и постоянно потребляли всё больше новых блоков памяти)
по итогу я просто отказался от тех закрепленных вкладок - и вуаля, перестал испытывать проблем с тем что firefox жрёт непомерно много памяти.
Достаточно попользоваться Реддитом минут 20-30, чтобы FF стал жрать оперативку тоннами
У меня Reddit практически вешает Оперу намертво. Оно некритично, даже не разбирался, но обхожу Reddit по возможности.
Вот видео с пятью вкладками Reddit в Chrome, на том самом ноутбуке из 2007го года с 3Гб памяти. Тормозит конечно, но не умирает.
Суть Linux в надежности, причем на любом оборудовании и в любом окружении. И до сего момента это была и пока что остается одной из самых надежных операционных систем и именно благодаря тому, что туда не допускали подобных сомнительных поделок. Представленный патч, если задуматься, скорее уменьшает надежность, а увеличивает вероятность нестабильности, якобы закрывая одну, весьма малозначительную проблему, открывая при этом путь к целому ряду других, который гораздо серьезнее и опаснее для всей системы. Это очевидный факт!
Такие патчи-это скорее диверсия против надежного конкурента Windows и MacOS... Делайте выводы.
Ох уж эта мифическая надежность Линуха, когда даже тут сразу несколько человек написали "виснет" =)
Я уже молчу про Ехт2 итп
А что, ext2 где-то используется последние лет 20?
Если почитать исходники как устроена ФС, то тлдр - ехт3 вообще прилеплена сбоку к Ехт2 (т.е её структуры можно игнорировать вообще, драйвер Ехт2 будет её читать и писать), ехт4 та же структура но с флагами (если ехт4 то читать так).
Так что да, очень много где она используется. Хоть и в слегка улучшенном виде.
Оффтоп. Ubuntu 25 баг: при попытке создать миниатюры, Gnome Files съедает всю память. Поможет ли задание некоего числа в параметр
min_ttl_ms продолжить работать с системой, хотя бы выключить этот Gnome Files через htop? Сейчас как память (включая swap) кончилась, все зависает намертво, даже текстовые консоли не открыть...
@ValdikSS
Gnome Files съедает всю память.
Тут только лимит по памяти в cgroups или докер, игры с MGLRU или l9 помогут лишь накал последствий снизить.
поидее gsettings там искать по ключам (их там можно все вывести и там посмотреть что стоит, если оно засериализировано в дерево, поидее можно убрать создание миниатюр наверно опять же через дерево, если приложение и его возможность от дерева работает )
ключ (приложение или функция) сначала наверно ключи посмотреть надо с их значениями (gsettings list-recursively)
что-то наподобии gsetings дай все ключи | grep 'nautilus'
но например первый раз когда гном я ставлю я сначала все ключи внимательно смотрю
еще можно посмотреть freedesktop и еще надо знать с какой системы запуск X11 или Wayland
самое худшее что может быть в этой ситуации 25 версия убунта и такое если, это пересборка наутилуса, или установка старой версии наверно, я у себя посмотрел не отдьедает, но у меня фрибсд
@alex0x08 Спасибо за статью!
Занимаюсь импортозамещенеим..., ТП AstraLinux полгода пинал на то чтобы что бы они ответили насчёт неадекватного поведения OomKiller`а и зависаний на АРМ`ах, подумали в сторону такого патча т.к. на рабочих станциях (ОЗУ 4-8GB в основном), ответ ТП Астры был что их это не колышет... пользователи не должны открывать по 50 вкладок в браузере... в результате там где проблема совсем острая начали ставить ZRAM как заплатку... Но l9ec явно лучшее решение! У кого есть ТП Астры напишите им ссылку на эту статью....
ТП AstraLinux полгода пинал на то чтобы что бы они ответили насчёт неадекватного поведения OomKiller
а и зависаний на АРМах,
Пишите сразу в ФСБ, там разберутся )
Если серьезно то все зависит от ваших полномочий и уровня поддержки, подозреваю что Астратовцы для начала вам ничего такого и не должны.
Про l9ec там наверняка в курсе но просто точно также не считают нужным брать на себя ответственность за чужие проблемы просто так.
О, значит, на 12309 они не остановились.
Что 12309 что этот баг - обратная сторона универсальности и острого желания сидеть сразу на всех стульях. Рано или поздно ядро, где через ifdef накручена поддержка всего - от роутеров до мейнфреймов должно было начать разваливаться под собственным весом.
У 12309 даже концовка примерно такая же - официально он закрыт, но о проблеме продолжают сообщать:
Nelson G 2023-11-12 02:19:13 UTC
I am facing this issue with both debian and archlinux. xfs and ext4
https://forums.debian.net/viewtopic.php?p=778803Для 12309, в отличие от, коммит с патчем так и не был обнаружен (наверное, закоммитили в gcc/llvm/clang и во внутренние репы микрокода всяких штеуд и амд)
Может ли быть, что патч не принимают ещё и из-за национальности его автора?
Вот уж не знаю, статистику такого рода отказов не веду, но замечаю что примерно половина даже чисто технических ресурсов заблокировала доступ с территории РФ.
Собственно даже сайт Xanmod1 закрыт таким образом и без прокси будет 'Connection timeout'. И все это делается втихую, без оглашения претензий или позиции владельцев.
На тему отзывчивости большинства разработчиков ядра к проблемам пользователей со старым железом. Вспомнилась статья аж 2009 года
Ага, вот почему chrome с большим количеством вкладок вешал мой офисный компьютер на линукс раньше! Оказывается, линукс - не такая уш надёжная ось(
Разумеется разработчики ядра в курсе проблемы, но по ряду причин.. не считают этот баг важным.
Это ведь свойство вытесняющей многозадачности.
Никто не может гарантировать от свопинга при недостатке оперативки для задачи.
По сути этим патчем формируется небольшой объем памяти (тот самый
working set), которую запрещается перегружать даже самым хитрым приложениям, откусывающим память по килобайтам.
А чем это отличается от "pinned memory" в IBM AIX и "nonpaging memory" Windows Server 2012+?
Эти штуки имеют ряд ограничений при использовании. Никак не тянут на панацею от свопинга при недостатке памяти.
Почитайте соответствующие редбуки и статьи на Microsoft.
Памяти должно быть достаточно для выполнения задачи.
Это правило.
Своп должен составлять рекомендованный процент от объема ОЗУ.
Есть, правда, RTS с разделением времени для любителей.
Это действительно - панацея для Вашего случая.
Очень медленно, но не свопится.
Но может купить списанный IBM 12-летней давности с террабайтом ОЗУ DDR3, если хочется локальных нейросетей?
Но может купить списанный IBM 12-летней давности с террабайтом ОЗУ DDR3, если хочется локальных нейросетей?
С козырей зашли )
Жаль IBM ушел из РФ, вам бы там точно бонус выдали за такую-то продажу )
Есть ведь Lenovo.
И потом - Я же написал - "списанный".
На алике вполне себе есть DDR3 ECC по 64ГБ, матплата Lenovo на 16-ть слотов памяти и процессор на много ядер.
Все лучше, чем своп с помощью pinned memory лечить.
Качество софта сейчас такое, что непонятно, что нужно в невытесняемую память пихать...
Качество софта сейчас такое, что непонятно, что нужно в невытесняемую память пихать...
ОС и ее либы, как примерно, в Андроид
есть DDR3 ECC по 64ГБ, матплата Lenovo на 16-ть слотов памяти и процессор на много ядер.
Ну уж нет, я в такое давно наигрался (аж целая серверная стойка стояла в квартире), нафиг.
Ныне только ноутбуки, а серверу место в серверной.
Ныне только ноутбуки, а серверу место в серверной.
Я думал Вам - ехать, а Вам - шашечки нужны.
Почему-то я так и подумал, что за статьей нет реальной проблемы...
Просто описание пакета, который написали люди, думающие, что на дворе 80-е и Linux устроен по правилам "BSD-style"...
Напишите, пожалуйста, что у Вас получится в итоге.
Почему-то я так и подумал, что за статьей нет реальной проблемы...
Конечно это не реальная проблема, когда система зависает под нагрузкой, просто какие-то мелочи жизни из 80х.
И для решения разумеется нужен мейнфрейм IBM, иначе никак.
Напишите, пожалуйста, что у Вас получится в итоге.
В итоге опять получится, что молиться будут на AI, роботов и высокие технологии а платить будут мне — за решение реальных проблем.
Ничего нового.
Конечно это не реальная проблема, когда система зависает под нагрузкой, просто какие-то мелочи жизни из 80х.
Если памяти недостаточно - любая система с вытесняющей многозадачностью будет тормозить.
Потому что в своп попадут системные процессы.Размер свопа на этот процесс не влияет.
Вам бы матчасть поизучать...
просто какие-то мелочи жизни из 80х.
При чем тут жизнь в 80-х?
BSD-style Unix - это концепция архитектуры Unix из 80-х, когда знаний было накоплено мало и люди чувствовали себя пионэрами в этой области. Керниган с Пайком свое "Программное окружение..." не написали опять же...
И для решения разумеется нужен мейнфрейм IBM, иначе никак.
Я ничего про мэнфрейм не писал. Это Ваши домыслы. "RTS", если что - "Real-time system". Это когда каждому процессу выделяется квант процессорного времени не глядя на его приоритет.
Во-первых, автор целую статью написал, с ясной обозначении цели. Зачем предлагать вариант не связанной с этой целью?
Во-вторых, дело не в свопинге так таковом. Если своп тупо увеличить, то мертвого зависания не будет. Именно речь про зависание, когда помогает только ресет.
С точки зрения пользователя же, если не знать как лечить, линукс выглядит стрёмной системой: на винде ничего не висло - перешёл на линукс виснет, ну его, перейду обратно на винду. Сотни сообщений таких встречал.
Винда при перегрузе памяти нормально справляется, не виснет намертво. У микрософта эта проблема решена по умолчанию. И многие задаются вопросом, почему же в линуксе не сделали какой нибудь механизм по умолчанию, не включили это в ядро.
Именно системы, которые из коробки работают стабильно, не требуют ковыряний, и ценятся пользователями.
Во-вторых, дело не в свопинге так таковом. Если своп тупо увеличить, то мертвого зависания не будет. Именно речь про зависание, когда помогает только ресет.
"Своппинг" - это не "зависание", тем более не "мертвое". Это когда часть системных процессов вытесняется в своп.
Если не возникнет "kernel panic" по таймауту, то вытесненный системный процесс вернётся в ОЗУ и вызов отработает.
Увеличение размера свопа не поможет. Нужно, чтобы все нужные для работы процессы помещались в ОЗУ. Если ОЗУ мало - следует его добавить....
Если не возникнет "kernel panic" по таймауту, то вытесненный системный процесс вернётся в ОЗУ и вызов отработает.
Вообще то нет. Точнее, вопрос когда отработает. Ибо количество запросов на своп растёт быстрее возможностей обработки. Конец
Вот именно, что речь и идёт про мёртвое зависание и как его лечить. Это главная цель текущей темы, а не что то другое.
Увеличение размера свопа в линуксе помогает избавиться от этой проблемы. Чтобы своп не пух ставим его сжималку.
Именно так я поборол у себя зависание системы: увеличением swap + zswap. Никакое железо модифицировать не пришлось. Тормозов не замечаю т.к. nvme стоит.
Такое же решение на vps ставлю, где ресурсы ограничены и везде nvme стоит.
Вот именно, что речь и идёт про мёртвое зависание и как его лечить
Если бы Вы определили как-то термин "мертвое зависание" и описали бы чем оно от обычного "своппинга" отличается - было бы легче Вас понять.
Или nmon с индикацией памяти с записью в файл запустить, а вывод здесь опубликовать. Тогда будет видно, что предшествовало "мёртвому зависанию"...
Или у Вас своп был меньше размера ОЗУ?
По правилам - размер свопа нужно выбирать около 2-х объемов ОЗУ.
Постоянно сталкивался с такой проблемой, 8gb RAM, причём без всякого спецсофта, тупо Firefox. Решил установкой расширения, которое выгружает фоновые вкладки.
Если это десктоп/ноутбук со встройкой - проблемой ещё становится время доступа к памяти.
В тикете разработчиков ядра за 2008(9)г, на который ссылается автор было написано, что "проблему" удалось решить включением режима DMA.
Фоновые вкладки рубить - тоже себе решение для компьютеров с малым количеством медленной памяти.
Невытесняемая область памяти точно в случае браузера не поможет.
У каждого процесса множество пайпов.
Кого в pinned memory помещать - хз.
l9ec: волшебный патч ядра Linux