Когда файл подкачки опасен?

Технически раздел подкачки более эффективен, чем файл подкачки. Практически, если файл подкачки является непрерывным, не должно быть большой разницы, а в текущих версиях Linux вообще не должно быть разницы в производительности. Есть несколько ошибок с файлами подкачки, но они возникают только при некоторых странных обстоятельствах.

Когда swap больше вреден, чем полезен, полностью зависит от загруженности вашей системы. Если рабочая нагрузка вашей системы никогда не приводит к использованию свопа, то проблем нет. Если у вас есть программы, которые выделяют много памяти (, которая попадает в своп )и больше никогда его не использует, своп сильно помогает (утечке памяти? ).

Но если ваш общий размер рабочего набора (того, что программа хочет в физическом ОЗУ )для всего, что работает, больше, чем физическая память, и часть переполнения оказывается в подкачке, тогда ваша система будет постоянно зависать. пытаясь подтолкнуть вещи к обмену и загрузить другие вещи обратно. Это может привести к тому, что производительность вашей системы составит 1/10 от нормальной, и может показаться, что система заблокирована, где без обмена что-то убило бы OOM.

Спорно и ситуативно, лучше ли системе тормозить и тормозить,или если будет лучше, если что-то будет убито, а производительность системы вернется к чему-то более нормальному.

Любой анализ, выходящий за рамки этого, или попытки определить соотношение баран/своп будут зависеть либо от конкретной ситуации, либо от мнения.

Подкачка также используется для других целей, таких как спящий режим, который требует, чтобы у вас было как минимум столько же подкачки, сколько оперативной памяти, и, возможно, аварийные дампы.

Хочу добавить, что все вышесказанное относится конкретно к linux. Некоторым версиям Unix требуется достаточно места подкачки, чтобы затенить всю оперативную память, и если вам нужна виртуальная память поверх этого, вам нужно больше подкачки, чем оперативной памяти. Текущий linux прекрасно работает без свопа --, некоторые юниксы этого не делают, и очень ранние версии linux также нуждались в свопе.

Обмен может быть плохим, поскольку он может сделать некоторые случаи сбоя более длительными . Рассмотрим ситуацию, когда какой-либо процесс начинает использовать чрезмерное количество памяти из-за ошибки, неправильной настройки или по другой подобной причине. Если подкачки нет, в конечном итоге системе не хватит памяти, в результате чего ОС решит проблему, в конечном итоге уничтожив процесс. (Но, возможно, в любом случае причинит другие неприятности.)

Но если места подкачки много, процесс начнет потреблять пространство подкачки, возможно, перебрасывая страницы между основной памятью и подкачкой, и это замедляет -ry -работу. В конечном итоге системе не хватит памяти, но до этого вы будете страдать дольше.

В основном я имею в виду медленные устройства подкачки, т. е. диски с вращающейся ржавчиной, так как именно там я столкнулся с этим... Вероятно, это не такая уж большая проблема с современными высокоскоростными -твердотельными накопителями.

(Конечно, правильным решением для этого было бы -ограничение использования памяти процессом, но при их отсутствии, как это, вероятно, происходит в вашей обычной произвольной настольной системе, факт наличия или отсутствия пространства подкачки может играть роль.)

Я не комментирую, хорошо это или плохо в целом , это только одна возможная ситуация. Я также не комментирую коэффициенты и тому подобное; обычно они являются обобщениями и могут быть основаны на требованиях, которые больше не действительны.

1. Имейте в виду, что управление пространством подкачки потребляет как ОЗУ, так и циклы ЦП -, даже если вы не используете пространство подкачки на самом деле. Конечно, это немного, но следует учитывать использование ОЗУ, например, 1/20 пространства подкачки. Давление памяти увеличивается. Циклы ЦП, вероятно, намного меньше.

2. Подкачка скрывает утечки памяти -это может быть как хорошо (, когда вы запускаете плохое программное обеспечение, с которым вам нужно жить ), так и плохое (это то, как плохое программное обеспечение может жить в первую очередь ).

   В некоторых случаях предпочтительнее кратковременный перезапуск из-за нехватки -из -памяти, чем длительный период плохой производительности. В других случаях это не так.

3. Подкачка может записывать конфиденциальную информацию на диск. Включая, помимо прочего, криптографические ключи, пароли, личные данные и т. д., и хранить их там неопределенно долго, даже если программное обеспечение намерено хранить их в памяти ненадолго. Некоторое программное обеспечение явно блокирует страницы с известной конфиденциальной информацией в памяти, но эту функцию нельзя распространить на всю возможную конфиденциальную информацию. Это растущая экспозиция риска по этим данным.

   Я еще не видел ИТ-компании с хорошей (работающей и всегда применяемой )политикой очистки дисков, удаленных из работающих систем.

   Зашифрованные области подкачки (файлы/разделы )существуют, но за них приходится платить дополнительной сложностью и производительностью. По крайней мере, какое-то время в Linux зашифрованные файлы подкачки, а также некоторые методы шифрования разделов имели известные проблемы со стабильностью. Зашифрованные разделы подкачки dm -crypt/luks в порядке -.

4. Производительность -Вы достигли предела памяти, клянутся ваши пользователи. SSD в этом плане лучше, но см. ниже.

   И в некоторых ОС (, например. Windows, я еще не видел, чтобы Linux делал то же самое, но плохие привычки заразны )память «разгружается» для подкачки задолго до того, как у вас закончится физическая память -на всякий случай. Да, это несколько повышает скорость отклика ()ценой общего ухудшения производительности и дополнительного дискового трафика.

5. Нагрузка на SSD при записи. -SSD изнашиваются при записи. Современные твердотельные накопители довольно долговечны, но никогда нельзя быть уверенным, насколько -и режимы их отказов довольно неприятны.

   Они довольно быстрые, и можно не знать об использовании свопа, пока не станет поздно.

Подкачка — очень изменчивая тема, которую не облегчает тот факт, что каждая ОС, а часто даже разные версии одной и той же ОС, могут обрабатывать это по-разному.

Я вижу эти потенциально опасные аспекты свопа:

• Слишком большой файл подкачки занимает место; если ваше хранилище ограничено, это может быть проблемой.
• Приложение может «думать», что у него больше доступной оперативной памяти, чем на самом деле, и, таким образом, резервировать больше, чем ему строго необходимо, и, таким образом, заставлять другие приложения выполнять подкачку, которая не должна быть там изначально. У меня была эта проблема в OS/2 3.0 (или Windows NT4 или 2000, я не был уверен )и хорошо помню, что написал программу, которая захватывает как можно больше памяти (, т. е. всю физическую оперативную память ). ], чтобы заставить часть действительно неиспользуемой оперативной памяти, зарезервированной некоторыми плохими приложениями, подкачать... Эта проблема может быть немного теоретической в ​​наши дни; Я предполагаю/надеюсь, что за последние десятилетия основные операционные системы со всем этим разобрались.
• Подкачка выполняется медленно . Невероятно медленный. Иногда я бы предпочел иметь четкую -вырезанную -из -ошибку памяти, чем ударяться о кирпичную стену при попадании в своп.

Единственный вредный аспект отсутствия наличия (достаточного )свопа заключается в том, что вы получаете -из -ошибок памяти, а процессы уничтожаются ОС. С моей точки зрения, когда это вообще возможно, правильное решение — получить больше оперативной памяти, а не увеличивать объем подкачки. Если приложению на самом деле требуется медленное хранилище для разгрузки некоторых своих данных (, это довольно обычное дело в РСУБД, например ), приложение должно обрабатывать это самостоятельно оптимизированным способом, а не полагаться на ОС и подкачку. Если нет возможности увеличить ОЗУ, то второе правильное решение — уменьшить нагрузку на ОЗУ, т. е. не использовать больше, чем у вас есть, удалив процессы с машины или настроив их на использование меньшего объема.

Вы находите аргументы в пользу того, что даже если у вас больше оперативной памяти, чем вам когда-либо понадобится, вы все равно должны создать своп. Это может быть или не быть полезным; вероятно, придется углубиться в подпрограммы управления оперативной памятью каждой ОС, чтобы выяснить, есть ли какая-то рифма или причина в этой теории. У меня не было бы проблем с попыткой без свопа, если бы я чувствовал, что знаю, что нужно моим процессам, и мое внутреннее чувство для любой современной ОС будет заключаться в том, что даже если предлагается иметь определенный минимальный объем свопа, он будет нормально работать без свопа совсем, если это позволяет настроить таким образом.

Использовать ли файл подкачки или раздел подкачки для меня больше вопрос управления (проще создать или изменить файл, чем раздел ). Особенно при замене на SDD это не имеет значения для производительности -. При обмене на жесткий диск наличие фрагментированного файла подкачки, конечно, было бы некрасиво, но любая современная ОС должна иметь возможность создавать большой файл в относительно больших непрерывных пространствах на жестком диске.

I can imagine a background-running application or service foo whose correct functionality depends on instant memory access. Dropping the memory space foo uses to swap would slow down the access to it slowing foo itself down causing warnings, errors or even a total failure.

Это рассуждение ошибочно. Это рассуждение содержит неявное предположение, что положить что-то в своп и выбросить это из физической ОЗУ — одно и то же. Одно может происходить без другого.

1. Чистые страницы можно удалять из ОЗУ без записи в своп. Это может произойти, даже если у вас нет файла подкачки. Таким образом, ваша программа, функциональность которой зависит от мгновенного доступа к памяти, может быть испорчена, потому что ее кодовые страницы были удалены из ОЗУ, даже если файла подкачки нет. На самом деле, это, скорее всего, произойдет без файла подкачки, потому что грязные страницы не могут быть отброшены без файла подкачки, а это означает, что чистые страницы (, такие как код ), с большей вероятностью отсутствуют в физической ОЗУ.

2. Страницы, записанные в своп, не обязательно удаляются из физической памяти. Страница может существовать как в свопе, так и в физической памяти. Страницы могут находиться как в физической памяти, так и в свопе.

Из-за этих двух вещей приведенный выше аргумент просто не имеет смысла. Swap позволяет извлекать грязные страницы, к которым долгое время не обращались, из физической оперативной памяти. Без подкачки могут быть извлечены только чистые страницы, даже если нет чистых страниц, к которым не обращались в течение длительного времени.

Не гарантируется, что ваш критический процесс найдет данные в ОЗУ с подкачкой или без нее. Однако вероятность найти данные в ОЗУ выше, если у вас есть своп. Почему? Потому что то, найдете ли вы что-то в ОЗУ, зависит от того, помещается ли рабочий набор системы в ОЗУ. Подкачка удаляет грязные страницы, к которым никогда не обращаются, из рабочего набора, уменьшая его размер и увеличивая вероятность того, что он поместится в ОЗУ.

Замена на неподходящий носитель

SD-карты, используемые в качестве подкачки, имеют тенденцию к преждевременному и неприятному сбою из-за ограниченного количества циклов записи. Это особенно проблема на ранних установках Raspberry Pi из-за ограниченной пропускной способности USB, дешевых SD-карт и ограниченного объема оперативной памяти.

Я прочитал другие ответы и подумал, что могу написать что-нибудь покороче, но, видимо, нет. По крайней мере, я отвечу на главный вопрос, а не поменяю местами вообще и ssd vs. hdd...

Это реальные -жизненные ситуации из моего опыта, когда обмен оказался сомнительным. Я кратко представлю сценарии, а затем подробно расскажу о плюсах и минусах.

• На моем личном рабочем столе

В случае, если вы сделаете что-то глупое, например, разветвите -бомбу в терминале, гораздо предпочтительнее, чтобы этот скрипт / терминал OOM -был убит ядром, а не наблюдал за вашей X-сессией, а все остальное стало полностью не отвечает.

• На рабочем сервере MySQL

Если доступной системной памяти меньше, чем требуется экземпляру mysql (плюс все остальное в этой системе ), тогда некоторые активные пользовательские данные из запроса могут оказаться в свопе. Если в это время отключится питание, скорее всего, вы получите неправильное логическое состояние вашего приложения. Несмотря на то, что сервер может перезапуститься без повреждений на уровне данных, восстановление после потери данных может быть очень болезненным для вас или ваших клиентов.

• На передних -конечных узлах веб-приложения

Если один узел обрабатывает больше подключений, чем у него есть памяти, и ему разрешен обмен, все транзакции будут выполняться намного медленнее, а время отклика веб-приложения будет выше допустимого. Время ожидания веб-приложения будет периодически истекать с ошибками 503 или 504, и вам нужно будет обратиться в службу поддержки.

Плюсы и минусы

• Рабочий стол

Я знаю два способа восстановить систему из процесса, который крадет всю вашу память и подкачку за разумное время.

1. Оболочка с другой машины и завершение процесса-нарушителя. Очевидно, что это не всегда возможно.
2. Переключатель сброса, который может быть очень неудачным в зависимости от того, что вы делали в это время.
3. Подготовьтесь к такому сценарию / укрепите свою систему (да, верно..)

"Экономия памяти" за счет размещения некоторых -редко используемых битов на диске на самом деле не является преимуществом. Система должна использовать CPU и DISK -IO для обмена памятью с/на диск, вы этого не хотите. Если рабочий процесс ядра [kswapd0] находится в списке первых -пяти или первых -трех процессов, ранжированных по общему -процессорному времени, используемому в вашей системе, я думаю, это повод для беспокойства. Поэтому уменьшите vm.swapiness до 0 или 1 -5 с помощью sysctl на вашем компьютере или вообще отключите подкачку.

Если вам изначально не хватает памяти, то попросите у начальника новый ноутбук, купите собственный или страдайте от низкой производительности. Вы также можете потратить свое время на оптимизацию использования памяти -приложениями-нарушителями и дайте мне знать, что вы думаете о рентабельности инвестиций в это через десятилетие или два;)

• Рабочий сервер MySQL

По моему мнению, наличие свопа на рабочем сервере MySQL не имеет никаких плюсов. Необходимость подкачки означает, что вы не знаете, какова рабочая нагрузка. С свопом он будет тормозить и производительность приложения будет неприемлемой.

• Работники WWW

Наличие подкачки может помочь вам «изящно» обнаруживать проблемы. Предполагая, что у вас есть мониторинг, это может считаться нормальным в тех же случаях. В большинстве случаев приложение будет слишком медленным для комфортного использования. Если внешние узлы не масштабируются по горизонтали, а подкачка/память используются какой-либо фоновой задачей, например отчетом -, то конечный результат будет таким же или даже хуже. Время отклика будет слишком большим.

В общем, вам нужно иметь некоторый опыт и цели для рассматриваемой системы, чтобы принимать правильные решения. Надеюсь, я ясно выразил свое негативное отношение к обмену, но в реальной жизниУ меня есть подкачка как на настольных, так и на рабочих серверах, потому что у подкачки (есть преимущества, такие как обнаружение утечек памяти, наличие предупреждений/времени для действий до того, как службы будут убиты, гибернация ). Если вы не можете доказать, что подкачка снижает производительность, можно безопасно выделить некоторые из них.

Does having a separate swap partition instead of a swap file change the situation?

Короткий ответ — нет.

Prompted by user10489's answer: *NIX-like OS:s don't have a separate hiberfile similar to what Windows uses?

Это не вопрос, это утверждение со знаком вопроса в конце. В Windows есть «скрытый системный раздел» и необязательный файл гибернации. Linux использует разделы подкачки для гибернации или файлы подкачки, которые нельзя использовать для гибернации. Концептуально эти разделы/файлы/гиберфайлы выполняют одну и ту же цель. Детали реализации бессмысленно сравнивать для ответа на первый вопрос, если вы спросите меня.