«Я видел такое, во что вы, люди, просто не поверите. Штурмовые корабли в огне на подступах к Ориону. Я смотрел, как Си-лучи мерцают во тьме близ врат Тангейзера. Я видел как ООМ убивает ноду с 1TB RAM»
Моему ноутбуку сейчас «памяти хватает» (7.5GB free). Но если я запущу еще две VM размером 6 и 4GB оперативки, её «внезапно» перестанет хватать. Но со свапом отзывчивость системы практически не изменится, поскольку эти ВМ примерно 50% своей оперативки не используют — и её можно отгрузить в свап.
А вот и нет. Система снесет в свап те данные, к которым реже всего идет обращение. Как правило, это редко меняющиеся данные, и когда они понадобятся — они будут прочитаны, использованы — и если не изменены — что, как правило, и бывает — то будут просто забыты как чистые странциы и снова будут прочитаны из свапа
ЕСЛИ у вас достаточный объем свапа, чтобы сгрузить туда такие редко используемые редко меняющиеся данные.
В кэше есть чистые страницы и грязные страницы. И есть анонимные страницы.
Когда вы записываете большой файл, у вас возникает большой пул грязных страниц. При массовой записи, система может начать освобождать чистые страницы и отдавать их под буфер записи. Ситуация очень похожая на анонимные страницы с тем только отличием, что грязные страницы можно сохранить (превратив в чистые) и снова использовать.
Ситуация очень похожа на то как если бы приложение начало активно отъедать память и описывается как вытеснение часто используемых данных из кэша.
Она имеет другую причину, но в целом получается то же следствие — просто есть шанс, что ситуация вернется в нормальное состояние, когда грязные страницы будут сброшены на диск
Код не уходит в свап.
Код лежит в кэше и свап позволяет этот кэш сохранить.
Код может быть «вымыт» из кэша неиспользуемыми данными, если у вас нет свапа.
В андроиде, если что, приложение которое не находится в foreground вообще может быть снято системой, и при «переключении» на него будет просто повторно запущено.
preload. Сделайте какой-нибудь ldd на бинарник браузера и прочтите с диска все файлы на которые укажет ldd, и будет вам немножко счастье. Но смысла в этом никакого нет — всё равно через 30-40 секунд система сама придет в такое же состояние
Можно вообще почти все сигналы перехватывать — но нужность этого вызывает большие сомнениея. Всякие переполнения, деления на ноль и прочие — да, можно. И даже может иметь смысл. В случае конкретно sefault нужность этого вызывает очень большие сомнения. Вы обратились «куда-то» куда не должны были, а это значит что ошибку допустили раньше — и возможно, намного раньше. Надежность повышается другими способами. В такой ситуации проще (и, как правило, предписывается) процессу убиться — возможно сбросить дамп, и возможно, запуститься заново, прочесть данные, и обработать их корректно. А может и не перезапускаться до проведения диагностики. А соотвтетсвующую функцию возьмет на себя резервный модуль.
электростанции, управление транспортом, да автоматические космические аппараты, в конце концов.
В таких случаях не занимаются нетрадиционными практиками камасутры, а используют более логичные инструменты типа гарантированного выделения ресурсов и лимитирования использования ресурсов потребителям в общей среде. А проще говоря, ставят ulimit и железо такое, чтобы в оперативку влез весь объем потребителей и делают mlock на свою память.
Влияние этого параметра несколько преувеличено. Там есть и другие парамтеры и статистики которые оказывают влияние на то, будет система свапиться или нет — точнее, КАК ИМЕННО система будет свапиться — будет ли она отгружать в свап анонимные страницы или освобождать кэш
А может ваши приложения, видя меньший объем доступной памяти, начинают меньше использовать? И тогда получается что у вас появляется быстрый файл подкачки и одновременно снижаются требования приложений к памяти?
Если «есть достаточное количество быстрой», то «медленная» использоваться не будет. Весь смысл статьи в том, что кэш это намного больше чем кэш, и если вы считаете, что кэш может быть освобожден и использован для данных — это неправильное предположение.
Есть такой очень неплохой инженер Chris Down — chrisdown.name
Он, среди прочего, поучаствовал активно в разработке линуксового ядра и у него есть несколько интересных статей — в том числе про swap.
И почему-то мне кажется, что мнение человека, который участвовал в разработке подсистем, которые используются едва ли не половиной современного IT (cgroup и cgroups_v2, которые в общем то лежат по дкапотом systemd, докера — а значит и кубика и много чего ещё) обосновано на существенно более широком и глубоком представлении о предмете, чем привычная многим «доказательная база» «а вот у меня на ноутбуке» :-)
тупит будет. Но будет работать
Но можно добавить внешний SSD пусть даже по USB, станет существенно стабильней
ЕСЛИ у вас достаточный объем свапа, чтобы сгрузить туда такие редко используемые редко меняющиеся данные.
Когда вы записываете большой файл, у вас возникает большой пул грязных страниц. При массовой записи, система может начать освобождать чистые страницы и отдавать их под буфер записи. Ситуация очень похожая на анонимные страницы с тем только отличием, что грязные страницы можно сохранить (превратив в чистые) и снова использовать.
Ситуация очень похожа на то как если бы приложение начало активно отъедать память и описывается как вытеснение часто используемых данных из кэша.
Она имеет другую причину, но в целом получается то же следствие — просто есть шанс, что ситуация вернется в нормальное состояние, когда грязные страницы будут сброшены на диск
Код лежит в кэше и свап позволяет этот кэш сохранить.
Код может быть «вымыт» из кэша неиспользуемыми данными, если у вас нет свапа.
В таких случаях не занимаются нетрадиционными практиками камасутры, а используют более логичные инструменты типа гарантированного выделения ресурсов и лимитирования использования ресурсов потребителям в общей среде. А проще говоря, ставят ulimit и железо такое, чтобы в оперативку влез весь объем потребителей и делают mlock на свою память.
Он, среди прочего, поучаствовал активно в разработке линуксового ядра и у него есть несколько интересных статей — в том числе про swap.
И почему-то мне кажется, что мнение человека, который участвовал в разработке подсистем, которые используются едва ли не половиной современного IT (cgroup и cgroups_v2, которые в общем то лежат по дкапотом systemd, докера — а значит и кубика и много чего ещё) обосновано на существенно более широком и глубоком представлении о предмете, чем привычная многим «доказательная база» «а вот у меня на ноутбуке» :-)