Еще раз, для особо упорных — ни свапинга ни вытеснения из кэша не случается если достаточно памяти. Они случаются когда памяти становится недостаточно — поэтому свап не ухудшит ситуацию своим наличием.
Свап это единственное место куда система может скинуть неиспользуемые анонимные страницы. У вас есть например /run с его контентом, /tmp куда какая-нибудь утилита распакует и забудет удалить архив. Много вариантов. Но все они сводятся к одному и тому же — без свапа анонимные страницы с неиспользуемыми данными остаются в памяти.
Поэтому отключение свапа может лишь уменьшить эффективность работы подсистемы виртуальной памяти, снизив объем доступной памяти, которой может оперировать система.
Есть набор исключений, но они из серии «как прострелить себе голову еще более неадекватным способом» типа «а не сделать ли мне свап на HDD»
Это могла быть не вкладка хром о окно либреоффиса, окно вскода, окно терминала, дисплейный сервер. Не повезло хрому с вкладкой гуглдокса, который решил проявить активность невовремя.
Задачи ревьюшников в эппле — банить всё что похоже на эппловские приложения. А всё, что не похоже — оценивать на перспективность и подавать в отдел разработки «скопируйте фичу а мы после следующего релиза забаним их и соберем себе их клиентскую базу».
Я правильно понимаю, исходя из вашего замечания, что юзер-спейс не свапится, и поэтому не имеет отношения к публикации?
Именно так. Юзерспейс может делать всё что угодно на самом деле — вести собственную буферизацию, сам делать весь I/O, управлять кэшами и т.д. — но это уже его кухня и к логике работы ядерных механизмов это отношения не имеет
А какой смылс сравнивать с RAM + RAM? Если я удвою объем памяти — у меня все данные + кэш влезут в оперативку — системе даже не нужно будет искать свободную память. Вопрос в том что чтобы удвоить их, нужно вложить шестизначную сумму, а это… Несколько неадекватная сумма, скажем так — особенно если учесть, что система загоняетя в такие граничные условия нечасто — а точнее, очень редко. Если это станет систематическим кейсом — можно думать об апгрейде. Но если это происходит раз-два в квартал на пару часов — то почему бы и нет, если система сохраняет достаточную отзывчивость.
Или потому, что запустил ресурсоемкую задачу, которую ранее не было необходимости решать но которая вроде бы должна влазить в ресурсы. И теперь не понимает, почему всё тормозит хотя вроде бы показатели в пределах нормы
Я уже русскими буквами писал — все проблемы возникают в граничных состояниях. Если вы «заменили своп на память» — то вы просто докидали ресурсов и вышли из граничного состояния.
А сейчас вы ведете себя как пациент, который читает рекомендации врача и говорит «Доктор, зачем вы мне написали всякую фигню — я же могу просто выздороветь и тогда не надо никаких ограничений».
Ну без проблем. Запустите андроид студию и андроид эмулятор с оперативкой на пару гигабайт и к ним какую-нибудь идею с питоновским проектом или vscode, желательно поставленные через всякие контейнероподобные извращения.
Ну или вы просто не замечаете, потому, что не с чем сравнивать.
Только не надо забывать, что все эти ораклы, db2 и прочие mssql считают себя монопольными владельцами соответствующих систем, когда в системе фактически крутится одна задача — и поэтому требования фиксированы и расчитываются по вполне себе документированным правилам.
Которые часто имеют вид «каждой сессии потребуется N мегабайт на сессионные данные, поэтому из суммарного объема вычтите X на систему, N * Y на сесии где Y количество сессий и оставшееся отдайте в БД указав конфигурационном файле вот такие параметры ....».
И поскольку правила (формулы) написаны так, чтобы укладываться в рамки системы, вопросов связанных с менеджментом ресурсов у ядра не возникает — ресурсов всегда хватает, посокльку потребитель запрашивает заранее определенный объем. Поэтому вопроса конкуренции за память просто не стоит.
Решение же надо принимать в многозадачных системах общего назначения (где много задач список и колтчество которых заранее неизвестны, а значит и требования к ресурсам варьируются). И на этот случай для тех кто считает что сам лучше справится с управлением ресурсами есть механизмы — они могут запросить ресурсы в монопольное использование и ядро их трогать не будет. Но надо понимать что такие ресурсы исключаются из общего менеджмента.
Поняете «осознанности» действий ядра вы как-то можете раскрыть?
У ядра была возможность выбора из двух групп страниц, и сброс кэша был выбран потому, что кэш не используется — а значит непродуктивно занимает место и его можно отдать кому надо. Вплоть до «сбросить кэш и отдать под кэш». Но если пользователь запретил свапинг или объем свап-файла мал — и одновременно с этим у него есть приложение которое заранее запросило себе большой объем памяти, заполнило данными но не использует — тогда сброс кэша это вынужденное решение.
Я почему-то считал, что подгрузка из свопа всегда вынужденная.
В идеальном мире управление памятью не нужно и ее всегда достаточно и под кэш и под данные. В реальном мире память ограничена и иногда надо выбирать чем пожертвовать (в смысле что выкинуть из памяти). И чем больше множество вариантов выбора — тем эффективней можно сделать выбор. Ядро не сбрасывает кэши и не свапит если есть свободная память. Оно делает это только если свободной памяти нет или её недостаточно для обеспечения стабильной работы.
Будет ли система из примера выше работать лучше, если увеличить своп?
Если просто «увеличить своп» — в текущем описании «нет». Если свап использовался бы полностью — однозначно «да». И даже если свап «сейчас» на оптане — нет. Но если на оптане и поднять сваппинес — то скорее да. А если на HDD и поднять сваппинесс — то скорее нет. Какой ответ вас устроит? Можно долго продолжать.
чем обычная загрузка «чистых страниц» с диска хуже подкачки чего-то из свопа?
Если реклейминг кэша это «осознанное» рещение ядра, а не вынужденное решение — то ничем не хуже (осознанное — значит что ядро имело возможность выбрать что сделать — скинуть неиспользуемую память или скинуть кэши). Вот тогда такое решение может быть ничем не хуже или даже лучше, ибо у ФС например есть прелоад. Проблема в том, что чтобы это решение было осознанным, нельзя отбирать у ядра возможности оптимизации.
Как в примере. На каждой итерации 3 гигабайта «код» + 3 гигабайта активно используемых данных. Неиспользуемые данные можно отсвапить без фатального падения для производительности системы и отдать их под необходимый код — что и происходит в успешном тесте. Но можно отобрать у системы возможности оптимизации — хоть отключив свап, хоть установив в 0/1 vm_swappiness и получить «тыкву». «Зато не свапится». Правда и не работает.
Вместо того, чтобы мне попросту не дать выстрелить себе в ногу — что делает линукс? Абсолютно верно — позволяет пострелять по ногам, как обычно.
Уже раз тридцать было сказано — если вы хотите гарантировать выделение памяти — cgroups, ulimit, overcommit. Все эти инструменты вам даны — но вы вместо того чтобы ими пользоваться пытаетесь изобрести искуственный псевдоинтеллект который должен делать хорошо (но получится как всегда — «вроде бы работает»).
К тому же, память иначе выделяется, где же кучи, чанки, арены?
Ужасно много красивых слов. К сожалению, они не относятся к рассматриваемой теме. Потому, что ядру мало интересно что юзерспейс чудит, ведь а) malloc относится к юзерспейсу и б) существовуют и другие реализации malloc — в том числе пофичастей чем глибсишная. Взаимоотношения ядра и юзерспейса заканчиваются в районе brk/madvise/mmap/mlock/mprotect и родственных им функций. Список можно продолжать, но есть надежда, что тот, кто кодил на Си сумеет прочесть see also в man и раскрутить этот граф.
overcommit и не рассматривал описывать — это инструмент скорее ближе к ulimit и cgroups resource management по назначению
с точки зрения того, рабочая станция или сервер разницы нет. Механизмы там одни и те же. Если вы знаете как работает механизм выделения памяти, то проанализировав ВАШУ нагрузку и собранную ВАМИ статистику вы сможете понять какие механизмы для вас более предпочтительны. И вообще сможете понять какая статистика вам нужна чтобы принять решение. А если вы не знаете и действуете по инструкции «как настроить vm.swappiness в линуксе на сервере убунту» и слепо вводите команды, то с вероятностью 70% сделаете только хуже. Поэтому сначала багаж знаний и на основании этого багажа оценивать чужие советы и принимаем решения.
В случае со свапом — если система находится в зоне достаточного количества ресурсов свап не используется. если система находится в зоне недостаточности ресурсов — свап не сделает хуже (мы не говорим о особых случаях когда надо гарантировать ресурсы — я в предыдущей статье отмечал, что там свои способы, и решения там должны быть намного более комплексные).
Рассказывать про тюнинг ООМ также нет никакого желание и на самом деле никакого смысла. Если OOM пришел — это авария, финита, конец, финиш, приехали, всё — называйте как хотите. Вы не можете предсказать картину когда ООМ сработает. Защитили вы от ООМ ssh — а тут внезапно хлоп — ошибка/сбой и ваш SSH перестает отвечать распухает и ООМ радостно убивает всех вокруг старательно охраняя пухнущий кривой демон. Чисто для примера. Управление ресурсами, гарантирование ресурсов — да, резервирование — да. ООМ — нет.
Он его «может» использовать — но скорей всего до этого не дойдет. «Может понадобится если пользователь нажмет Ctrl+Z». Но скорее всего нет. А разработчики решили «не насиловать диск на каждый чих». И вот теперь у вас пять копий документа за пять последних шагов, бесцельно жрут память. А вы переключились в браузер и на хабре в камменты пишете и в четырнадцати вкладках обои в 4K открыли через «открыть в новой вкладке». А потом снова в редактор переключились и продолжили создавать нетленку. Разумное решение системы — 4K пиксмапы в свап, ресурсы редактору — чтобы вам лучше нетленилось. Ну если вы свап не отключили.
Всё затем, что у свапа два назначения:
1. сгладить пиковые нагрузки не дав системе упасть.
2. частично скомпенсировать проблемы [возможно] неоптимально написанного ПО, которое не освобождает память когда заканчивает его использовать. Например, какой-нибудь браузер который удерживает в памяти несколько исторических страниц, которыми вы вряд ли воспользуетесь, но место они занимают. Историю для отмены по Ctrl+Z. Если всё оно лежит в анонимных страницах и не используется, то может быть безопасно выгружено.
Потому что swap это один из двух способов восполнения свободных страниц. И если вы видите что свап существенно заполнен (один способ активно используется), то с достаточно высокой вероятностью и второй способ активно используется — просто вы его не видите.
И может случиться, что если у вас «не хватает» условно 9GB то в свапе вы например увидите 6GB а 3GB будут возмещены реклеймингом кэша.
И тогда, если вы добавите 8GB, то у вас все равно не хватит 1GB и они будут возмещаться из свапа и кэша — и 400MB пойдут из кэша а 600MB улетят в свап.
Но это всё надо смотреть на конкретно взятых системах, чтобы понимать, с какого раздела идет подъем данных — из свапа или с файловой системы.
Свап это единственное место куда система может скинуть неиспользуемые анонимные страницы. У вас есть например /run с его контентом, /tmp куда какая-нибудь утилита распакует и забудет удалить архив. Много вариантов. Но все они сводятся к одному и тому же — без свапа анонимные страницы с неиспользуемыми данными остаются в памяти.
Поэтому отключение свапа может лишь уменьшить эффективность работы подсистемы виртуальной памяти, снизив объем доступной памяти, которой может оперировать система.
Есть набор исключений, но они из серии «как прострелить себе голову еще более неадекватным способом» типа «а не сделать ли мне свап на HDD»
Именно так. Юзерспейс может делать всё что угодно на самом деле — вести собственную буферизацию, сам делать весь I/O, управлять кэшами и т.д. — но это уже его кухня и к логике работы ядерных механизмов это отношения не имеет
Или потому, что запустил ресурсоемкую задачу, которую ранее не было необходимости решать но которая вроде бы должна влазить в ресурсы. И теперь не понимает, почему всё тормозит хотя вроде бы показатели в пределах нормы
А сейчас вы ведете себя как пациент, который читает рекомендации врача и говорит «Доктор, зачем вы мне написали всякую фигню — я же могу просто выздороветь и тогда не надо никаких ограничений».
Ну или вы просто не замечаете, потому, что не с чем сравнивать.
Которые часто имеют вид «каждой сессии потребуется N мегабайт на сессионные данные, поэтому из суммарного объема вычтите X на систему, N * Y на сесии где Y количество сессий и оставшееся отдайте в БД указав конфигурационном файле вот такие параметры ....».
И поскольку правила (формулы) написаны так, чтобы укладываться в рамки системы, вопросов связанных с менеджментом ресурсов у ядра не возникает — ресурсов всегда хватает, посокльку потребитель запрашивает заранее определенный объем. Поэтому вопроса конкуренции за память просто не стоит.
Решение же надо принимать в многозадачных системах общего назначения (где много задач список и колтчество которых заранее неизвестны, а значит и требования к ресурсам варьируются). И на этот случай для тех кто считает что сам лучше справится с управлением ресурсами есть механизмы — они могут запросить ресурсы в монопольное использование и ядро их трогать не будет. Но надо понимать что такие ресурсы исключаются из общего менеджмента.
У ядра была возможность выбора из двух групп страниц, и сброс кэша был выбран потому, что кэш не используется — а значит непродуктивно занимает место и его можно отдать кому надо. Вплоть до «сбросить кэш и отдать под кэш». Но если пользователь запретил свапинг или объем свап-файла мал — и одновременно с этим у него есть приложение которое заранее запросило себе большой объем памяти, заполнило данными но не использует — тогда сброс кэша это вынужденное решение.
В идеальном мире управление памятью не нужно и ее всегда достаточно и под кэш и под данные. В реальном мире память ограничена и иногда надо выбирать чем пожертвовать (в смысле что выкинуть из памяти). И чем больше множество вариантов выбора — тем эффективней можно сделать выбор. Ядро не сбрасывает кэши и не свапит если есть свободная память. Оно делает это только если свободной памяти нет или её недостаточно для обеспечения стабильной работы.
Если просто «увеличить своп» — в текущем описании «нет». Если свап использовался бы полностью — однозначно «да». И даже если свап «сейчас» на оптане — нет. Но если на оптане и поднять сваппинес — то скорее да. А если на HDD и поднять сваппинесс — то скорее нет. Какой ответ вас устроит? Можно долго продолжать.
Если реклейминг кэша это «осознанное» рещение ядра, а не вынужденное решение — то ничем не хуже (осознанное — значит что ядро имело возможность выбрать что сделать — скинуть неиспользуемую память или скинуть кэши). Вот тогда такое решение может быть ничем не хуже или даже лучше, ибо у ФС например есть прелоад. Проблема в том, что чтобы это решение было осознанным, нельзя отбирать у ядра возможности оптимизации.
Как в примере. На каждой итерации 3 гигабайта «код» + 3 гигабайта активно используемых данных. Неиспользуемые данные можно отсвапить без фатального падения для производительности системы и отдать их под необходимый код — что и происходит в успешном тесте. Но можно отобрать у системы возможности оптимизации — хоть отключив свап, хоть установив в 0/1 vm_swappiness и получить «тыкву». «Зато не свапится». Правда и не работает.
Уже раз тридцать было сказано — если вы хотите гарантировать выделение памяти — cgroups, ulimit, overcommit. Все эти инструменты вам даны — но вы вместо того чтобы ими пользоваться пытаетесь изобрести искуственный псевдоинтеллект который должен делать хорошо (но получится как всегда — «вроде бы работает»).
Ужасно много красивых слов. К сожалению, они не относятся к рассматриваемой теме. Потому, что ядру мало интересно что юзерспейс чудит, ведь а) malloc относится к юзерспейсу и б) существовуют и другие реализации malloc — в том числе пофичастей чем глибсишная. Взаимоотношения ядра и юзерспейса заканчиваются в районе brk/madvise/mmap/mlock/mprotect и родственных им функций. Список можно продолжать, но есть надежда, что тот, кто кодил на Си сумеет прочесть see also в man и раскрутить этот граф.
с точки зрения того, рабочая станция или сервер разницы нет. Механизмы там одни и те же. Если вы знаете как работает механизм выделения памяти, то проанализировав ВАШУ нагрузку и собранную ВАМИ статистику вы сможете понять какие механизмы для вас более предпочтительны. И вообще сможете понять какая статистика вам нужна чтобы принять решение. А если вы не знаете и действуете по инструкции «как настроить vm.swappiness в линуксе на сервере убунту» и слепо вводите команды, то с вероятностью 70% сделаете только хуже. Поэтому сначала багаж знаний и на основании этого багажа оценивать чужие советы и принимаем решения.
В случае со свапом — если система находится в зоне достаточного количества ресурсов свап не используется. если система находится в зоне недостаточности ресурсов — свап не сделает хуже (мы не говорим о особых случаях когда надо гарантировать ресурсы — я в предыдущей статье отмечал, что там свои способы, и решения там должны быть намного более комплексные).
Рассказывать про тюнинг ООМ также нет никакого желание и на самом деле никакого смысла. Если OOM пришел — это авария, финита, конец, финиш, приехали, всё — называйте как хотите. Вы не можете предсказать картину когда ООМ сработает. Защитили вы от ООМ ssh — а тут внезапно хлоп — ошибка/сбой и ваш SSH перестает отвечать распухает и ООМ радостно убивает всех вокруг старательно охраняя пухнущий кривой демон. Чисто для примера. Управление ресурсами, гарантирование ресурсов — да, резервирование — да. ООМ — нет.
1. сгладить пиковые нагрузки не дав системе упасть.
2. частично скомпенсировать проблемы [возможно] неоптимально написанного ПО, которое не освобождает память когда заканчивает его использовать. Например, какой-нибудь браузер который удерживает в памяти несколько исторических страниц, которыми вы вряд ли воспользуетесь, но место они занимают. Историю для отмены по Ctrl+Z. Если всё оно лежит в анонимных страницах и не используется, то может быть безопасно выгружено.
И может случиться, что если у вас «не хватает» условно 9GB то в свапе вы например увидите 6GB а 3GB будут возмещены реклеймингом кэша.
И тогда, если вы добавите 8GB, то у вас все равно не хватит 1GB и они будут возмещаться из свапа и кэша — и 400MB пойдут из кэша а 600MB улетят в свап.
Но это всё надо смотреть на конкретно взятых системах, чтобы понимать, с какого раздела идет подъем данных — из свапа или с файловой системы.