Почему система без свапа работает *&^ей чем со свапом?!
Ну чо, чуваки, вы решили что отключили свап в этом нашем линупсе и у вас система теперь ваще быстро работает патамушта ни свапицца? А вот хрен вам на палочке в карамельном соусе, а не "быстро". И сейчас разберем почему. Для начала, давайте посмотрим на любой процесс в выводе top или ps. А если говорить точнее, нас интересуют два столбца - RSS - Resident Set Size и Virtual - Virtual size. Как правило, RSS в разы меньше чем Virtual. Почему?
Тривиально. В RSS учитываются только личные данные процесса, которые он ни с кем не делит. Фактически это данные этого процесса (за исключениеи Copy-On-Write после fork(), там всё чуть по иному). А вот огромный объем Shared по сравнению с RSS объясняется тем, что в Shared учитывается дох*^-предох*&^% мног-много всего, включая загруженные разделяемые библиотеки. А эти библиотеки, в свою очередь отображены как через страницы кеша, управляемого VFS.
Ты вот сейчас наверное думаешь - нахрена этот самовлюбленный удод рассказывает мне тошто я и так знаю? А вот зачем - вся эта схема работает зашибись, пока мы не подошли к тому моменту, когда память занята (практически) полностью.
И вот тогда начинается самое интересное.
Процесс через sbrk() запрашивает у системы фрагмент памяти.
Система его выделяет, но не аллокейтит под него страницы, пока не будет обращений к ним.
Произошло обращение, необходимо выделить реальные страницы... Но свободных нет. Что делать?
Освобождать кэш! Причем освобождать именно те страницы, которые можно всегда подчитать - то есть "чистые" - в которых нет "грязных" данных, которые надо сбросить на диск.
И как на зло, такими страницами яляются - да-да, за'mmap'ленные участки разделяемых библиотек. Они ведь не меняются, и их проще всего забыть, отдать процессу которому срочно нужна память, и потом "подсвапить" обратно.
А теперь самое забавное - ведь в большинстве случаев в RSS процессов с большим RSS лежат данные, которые в действительности не особо нужны. Не, они понадобятся - но потом, секундй через 10. Или минут через 10. Или через 20. Типа пиксмапов картинок браузера на одной и з40 вкладок, или глифов шрифта Andale Mono китайской кодировки которые сгенерировались час назад когда у вас выскочило китайская-рекламная-объявления-дёсива-плодам.
Но поскольку свап отключен, система НЕ МОЖЕТ снести в свап такие неиспользуемые данные - их, блджад, некуда сносить, ибо ты, оптимизатор, отключил свап! - и сносит страницы с исполняемым кодом. Которые потребуется снова поднять как только до этого кода дойдет дело. А оно дойдет скоро, ибо страницы подгружаются on-demand, и если их подтянули - там нужный код, да.
Поэтому как только ты, безсваперный чувак, что-то делаешь, у тебя начинается свопинг.
А насчет ресурса SSD не беспокойся, те данные которые чаще всего улетают в свап, они не постоянно перезаписываются, и если у тебя не постоянный memcpy по всему объему памяти, у тебя меняется малое количество страниц, которые отсвапливаться не будут, и по сути свап будет работать в режим "один раз записал - много раз прочел".
Такие дела, да. Система НЕ БУДЕТ свапить то, что не надо свапить. Она умнее чем 99% сисадминов, поэтому ДОВЕРЬСЯ СИСТЕМЕ.
Тривиально. В RSS учитываются только личные данные процесса, которые он ни с кем не делит. Фактически это данные этого процесса (за исключениеи Copy-On-Write после fork(), там всё чуть по иному). А вот огромный объем Shared по сравнению с RSS объясняется тем, что в Shared учитывается дох*^-предох*&^% мног-много всего, включая загруженные разделяемые библиотеки. А эти библиотеки, в свою очередь отображены как через страницы кеша, управляемого VFS.
Ты вот сейчас наверное думаешь - нахрена этот самовлюбленный удод рассказывает мне тошто я и так знаю? А вот зачем - вся эта схема работает зашибись, пока мы не подошли к тому моменту, когда память занята (практически) полностью.
И вот тогда начинается самое интересное.
Процесс через sbrk() запрашивает у системы фрагмент памяти.
Система его выделяет, но не аллокейтит под него страницы, пока не будет обращений к ним.
Произошло обращение, необходимо выделить реальные страницы... Но свободных нет. Что делать?
Освобождать кэш! Причем освобождать именно те страницы, которые можно всегда подчитать - то есть "чистые" - в которых нет "грязных" данных, которые надо сбросить на диск.
И как на зло, такими страницами яляются - да-да, за'mmap'ленные участки разделяемых библиотек. Они ведь не меняются, и их проще всего забыть, отдать процессу которому срочно нужна память, и потом "подсвапить" обратно.
А теперь самое забавное - ведь в большинстве случаев в RSS процессов с большим RSS лежат данные, которые в действительности не особо нужны. Не, они понадобятся - но потом, секундй через 10. Или минут через 10. Или через 20. Типа пиксмапов картинок браузера на одной и з40 вкладок, или глифов шрифта Andale Mono китайской кодировки которые сгенерировались час назад когда у вас выскочило китайская-рекламная-объявления-дёсива-плодам.
Но поскольку свап отключен, система НЕ МОЖЕТ снести в свап такие неиспользуемые данные - их, блджад, некуда сносить, ибо ты, оптимизатор, отключил свап! - и сносит страницы с исполняемым кодом. Которые потребуется снова поднять как только до этого кода дойдет дело. А оно дойдет скоро, ибо страницы подгружаются on-demand, и если их подтянули - там нужный код, да.
Поэтому как только ты, безсваперный чувак, что-то делаешь, у тебя начинается свопинг.
А насчет ресурса SSD не беспокойся, те данные которые чаще всего улетают в свап, они не постоянно перезаписываются, и если у тебя не постоянный memcpy по всему объему памяти, у тебя меняется малое количество страниц, которые отсвапливаться не будут, и по сути свап будет работать в режим "один раз записал - много раз прочел".
Такие дела, да. Система НЕ БУДЕТ свапить то, что не надо свапить. Она умнее чем 99% сисадминов, поэтому ДОВЕРЬСЯ СИСТЕМЕ.