Вот второе утверждение, совершенно неочевидно и, имхо, в статье не раскрывается.
Потому, что не факт, что той памяти, которую вы добавили, будет достаточно, даже если вы добавить столько памяти, сколько использовано свапа. То есть если у вас 8GB физическая, 8GB свап и из них 6GB использовано, то добавление 8GB практически гарантированно недостаточно. Просто потому, что 6GB у вас отсвапленых анонимных страниц — но сколько у вас зареклеймилось страниц кэша одновременно со свапингом? 1GB? 3GB?
Но конечно увеличение памяти в четыре раза — да, оно практически гарантированно избавляет от проблем за исключением очень-очень редких случаев.
Не надо читать всякие… глупости. Потому что swappiness определяет НЕ ПРОЦЕНТ ПАМЯТИ а относительную стоимость IO файловой системы относительно IO свапа.
swappiness
This control is used to define the rough relative IO cost of swapping and filesystem paging, as a value between 0 and 200
Дешевый FS paging < swappines < Дешевый swap
То есть swappines определяет не КОГДА начинается свапинг или реклейминг кэша, он определяет КАКАЯ МЕТОДИКА освобождения страниц будет чаще выбираться — будет ли чаще дропаться кэш (low swappiness) или анонимные страницы будут чаще уноситься в swap (high swappiness). И сваппинга вообще не будет ни при каком значении swappiness если не достигнут соответствующий watermark.
И отдельно идет vm.dirty_ratio при котором грязные страницы начинают флашиться на диск и превращаться в чистые.
как было у одного из комментаторов в прошлой статье — 64 Гб незанятой памяти и своп 4 Гб
Там «было» только слова. Ни выводе free, ни шапки топа процессов по памяти. Поэтому не вижу смысла о чем-то там гадать. И то у там vm_swappiness=0, то уже 1. Гадать так это то же самое, что ставить диагноз на основании СМС написанных со слов услышанных в скайпе.
Посмотрите на последний пример top. Если бы я не показал исходников программы — что бы можно было подумать? Ну конечно же — линукс свапится и тормозит хотя свап отключен и у него море кэша, добавил еще 16ГБ и всё полетело, вот такой он глючный этот ваш линукс.
Фризы пропадают, но иногда может возникнуть ситуация, что система просто встаёт колом и почти не реагирует ни на что
А это типа не фриз?! Какая-то странная логика — «фризов нет но иногда всё встает колом».
Использование zram. На этом варианте я и остановился
И про этот кейс я также рассказал в конце. zram хорошо помогает в сочетании с обычным swap, иначе, в случае несжимаемых страниц, он даже добавляет тормозов.
система пытается трактовать память, занятую библиотеками, как «условно свободную» и с радостью выгружает эти библиотеки, чтобы впихнуть на их место данные
Нет. Система должна впихнуть данные и обычно у неё два ресурса — кэш и свап, между которыми она выбирает. Но владелец системы отключивший или ограничивший свап запретил ей прибегать ко второму пути — поэтому чтобы предоставить память, система начинает дропать кэши (которые совсем не ненужные кэши, а очень даже наоборот).
И вместо того, чтобы прикидываться, словно у нас есть этот «условно свободный» гигабайт, ими занятый (на самом деле нет), нужно просто запретить такую выгрузку.
И придет ООМ. И похоронит какой-нибудь процесс. Например, дисплейный сервер, который обратился к системе «дай мне двойной буфер размером 3840x2060x32». Или клиента этого дисплейного сервера который получил ссылку на этот буфер и начал в него рисовать (а значит активно потреблять память).
Есть такой флаг в Linux?
man mlock/man mmap на предмет MAP_LOCKED. Но вам этот флаг не нужен. Он породит совершенно внезапные сегфолты в условиях memory pressure.
Вы неправильно поняли прочтенное — прежде чем у вас случится «fail fast» у вас всё начнет лагать, потому что с точки зрения систему ресурсы еще есть — и этот ресурс это страницы кэша, который можно дрогнуть и отдать под данные. А потом когда данные понадобятся поднять их снова с диска.
Тест с отключённым свапом это очень хорошо показывает — процесс едва-едва шевелится и затормозил десятикратно.
Если вы хотите «fail fast» — вам надо включать лимиты на cgroup и механизмы ulimit. И активировать ограничения на размер закоммиченой памяти (overcommit ratio).
Так вот весь смысл в том, что если вы сидите без свапа но ООМ ещё не пришел (а это вполне себе реально если у вас куча фтапаков/снапов которые используют «принесенное с собой» а не системное окружени, то вы пойдете пить чай. А мифические «тормоза из-за свапа» выражаются в которотких подлагиваниях при переключении в другое приложение, и только.
Я обещаю сегодня опубликовать еще одну статью в продолжение обсуждаемой. Там будет приведен тривиальнейший код, который позволит поисследовать (и понять) механизмы работы VM и сапа в линуксе. Stay tuned
Паямти «не хватает» всегда. Рано или поздно ее становится «под обрез» — то есть вроде бы хватает, но на самом деле уже нет. Утверждение «программы разжирели и тормозят» вызывается в том числе и трэшингом, проблему которого для большинства пользвателей свап достаточно хорошо решает.
Да не уходит код в свап. Вы хоть прочтите внимательно то что было написано — если код это clean page (как по умолчанию оно и есть) то он не отсвапливается.
Страницы просто реклеймятся и НЕ отправляются в свап, и потом поднимаются НЕ из свапа а с системного раздела. Поэтому если у вас есть свап — у вас есть шанс сохранить код в памяти при стрессовой нагрузке, а если свапа нет — то ваш код гарантированно из памяти вылетит — и начнется трешинг и 12309.
Никакого. Отношения к механизмам свапинга overcommit не имеет. Он просто не дает процессам запросить слишком много памяти, и он никак не влияет ни на свап, ни на OOM-killer
Анонимные страницы отсвапливаются если маркер свободной памяти опускается ниже определенного порога и к странице не было обращений очень/достаточно давно. Если свободной памяти много — свапиться ничего не будет. И overcommit тут ни при чем вообще.
Вот как раз «редко используемые библиотеки» в свап не вытесняются. Они просто вытесняются из кэша и подгружаются обратно в кэш по мере необходимости. А в свап улетают анонимные страницы — то есть данные программ, к которым не было обращения.
Со свапом вообще парадоксальная ситуация, очень много рассуждающих о нем, в действительности, не понимают механизмов его работы, например:
активная запись в свап в целях превентивного вытеснения анонимных страниц НЕ означает, что система будет тормозить — этот процесс просто в фоне создаст пул свободных страниц, которые приложения смогут использовать когда потребутеся. Такой пул (внезапно!!!) на самом деле необходим, потому что в линуксе (да и везде в общем то) аллокация памяти оптимистичная — память обещается но выделяется при первом обращении. Поэтому чтобы программы могли при необходимости быстро достучаться до своей памяти, часть анонимных страниц может быть унесена в свап, равно как и часть чистых страниц кэша отреклаймлена. И что именно туда будет унесено — будет решено через LRU. То есть к чемы по статистике реже всего ходите — то и уходит на диск
нехватка памяти не обязательно выражается в активной ЗАПИСИ в свап — она может выражаться в активном ЧТЕНИИ из свапа — например вы загрузили десяток 4K картинок в смотрелку и переключаетесь между ним и скроллите их. При этом анонимные страницы пиксмапов могут легко уехать в свап и постоянно — и многократно — оттуда доставаться, но не перезаписываться.
overcommit отдельная история, к работе со свапом она не имеет отношения. Это просто «точка отсечения» аналогично ulimit, только ulimit лимитирует на уровне процесса а overcommit на уровне системы.
Если бы вы сделали свап не 1-2 GB, а например 4-8, то с достаточно высокой вероятностью у вас объем общения с диском бы резко упал, потому что системе не надо было бы многократно перезаписывать данные в свапе. Я объяснял это в статье — если в свап вытесняются редко меняющиеся данные с редкими обращениями, то наличие большего объема позволяет системе намного эффективней оперировать с выгрузкой анонимных страниц. Чем меньше объем свапа, тем чаще система будет в него писать.
Потому, что не факт, что той памяти, которую вы добавили, будет достаточно, даже если вы добавить столько памяти, сколько использовано свапа. То есть если у вас 8GB физическая, 8GB свап и из них 6GB использовано, то добавление 8GB практически гарантированно недостаточно. Просто потому, что 6GB у вас отсвапленых анонимных страниц — но сколько у вас зареклеймилось страниц кэша одновременно со свапингом? 1GB? 3GB?
Но конечно увеличение памяти в четыре раза — да, оно практически гарантированно избавляет от проблем за исключением очень-очень редких случаев.
Swap used 1MB (при 20GB доступных), результат тот же самый, то есть
Preparing test …
Doing test …
Iteration 1 of 11
[1]+ Done { sleep 120; killall swapdemo; }
Terminated
Поскольку если границы срабатывания механизма свапинга не достигнуты (граничные улсоивя не достигнуты) — свапинга не происходит и смотреть нечего
www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html
Дешевый FS paging < swappines < Дешевый swap
То есть swappines определяет не КОГДА начинается свапинг или реклейминг кэша, он определяет КАКАЯ МЕТОДИКА освобождения страниц будет чаще выбираться — будет ли чаще дропаться кэш (low swappiness) или анонимные страницы будут чаще уноситься в swap (high swappiness). И сваппинга вообще не будет ни при каком значении swappiness если не достигнут соответствующий watermark.
И отдельно идет vm.dirty_ratio при котором грязные страницы начинают флашиться на диск и превращаться в чистые.
Там «было» только слова. Ни выводе free, ни шапки топа процессов по памяти. Поэтому не вижу смысла о чем-то там гадать. И то у там vm_swappiness=0, то уже 1. Гадать так это то же самое, что ставить диагноз на основании СМС написанных со слов услышанных в скайпе.
А это типа не фриз?! Какая-то странная логика — «фризов нет но иногда всё встает колом».
И про этот кейс я также рассказал в конце. zram хорошо помогает в сочетании с обычным swap, иначе, в случае несжимаемых страниц, он даже добавляет тормозов.
Нет. Система должна впихнуть данные и обычно у неё два ресурса — кэш и свап, между которыми она выбирает. Но владелец системы отключивший или ограничивший свап запретил ей прибегать ко второму пути — поэтому чтобы предоставить память, система начинает дропать кэши (которые совсем не ненужные кэши, а очень даже наоборот).
И придет ООМ. И похоронит какой-нибудь процесс. Например, дисплейный сервер, который обратился к системе «дай мне двойной буфер размером 3840x2060x32». Или клиента этого дисплейного сервера который получил ссылку на этот буфер и начал в него рисовать (а значит активно потреблять память).
man mlock/man mmap на предмет MAP_LOCKED. Но вам этот флаг не нужен. Он породит совершенно внезапные сегфолты в условиях memory pressure.
Тест с отключённым свапом это очень хорошо показывает — процесс едва-едва шевелится и затормозил десятикратно.
Если вы хотите «fail fast» — вам надо включать лимиты на cgroup и механизмы ulimit. И активировать ограничения на размер закоммиченой памяти (overcommit ratio).
Страницы просто реклеймятся и НЕ отправляются в свап, и потом поднимаются НЕ из свапа а с системного раздела. Поэтому если у вас есть свап — у вас есть шанс сохранить код в памяти при стрессовой нагрузке, а если свапа нет — то ваш код гарантированно из памяти вылетит — и начнется трешинг и 12309.
Анонимные страницы отсвапливаются если маркер свободной памяти опускается ниже определенного порога и к странице не было обращений очень/достаточно давно. Если свободной памяти много — свапиться ничего не будет. И overcommit тут ни при чем вообще.
Со свапом вообще парадоксальная ситуация, очень много рассуждающих о нем, в действительности, не понимают механизмов его работы, например:
активная запись в свап в целях превентивного вытеснения анонимных страниц НЕ означает, что система будет тормозить — этот процесс просто в фоне создаст пул свободных страниц, которые приложения смогут использовать когда потребутеся. Такой пул (внезапно!!!) на самом деле необходим, потому что в линуксе (да и везде в общем то) аллокация памяти оптимистичная — память обещается но выделяется при первом обращении. Поэтому чтобы программы могли при необходимости быстро достучаться до своей памяти, часть анонимных страниц может быть унесена в свап, равно как и часть чистых страниц кэша отреклаймлена. И что именно туда будет унесено — будет решено через LRU. То есть к чемы по статистике реже всего ходите — то и уходит на диск
нехватка памяти не обязательно выражается в активной ЗАПИСИ в свап — она может выражаться в активном ЧТЕНИИ из свапа — например вы загрузили десяток 4K картинок в смотрелку и переключаетесь между ним и скроллите их. При этом анонимные страницы пиксмапов могут легко уехать в свап и постоянно — и многократно — оттуда доставаться, но не перезаписываться.
То есть ваш «p.s.» неправилен вообще :-)