Что лучше по производительности? Раздел, расположенный ближе к внутренней части диска, будет иметь более медленное время доступа, и мы должны дождаться, пока диск переключится между разделами ОС и разделами подкачки.
С другой стороны, раздел подкачки обходит всю файловую систему, позволяя производить запись на диск напрямую, что может быть быстрее, чем файл.
Какой компромисс в производительности?
Насколько важен файл подкачки фиксированного размера?
Может ли быть, что переход на раздел подкачки будет дольше, но производительность будет лучше, пока он находится в разделе подкачки, чем если бы это был файл подкачки?
На жестких дисках пропускная способность и поиск часто быстрее к началу диска, потому что эти данные хранятся ближе к внешней области диска, у которой больше секторов на цилиндр. Таким образом, создание подкачки в начале диска может улучшить производительность.
Для ядра Linux 2.6 нет разницы в производительности между разделом подкачки и разделом подкачки. нефрагментированный файл подкачки. Когда раздел / файл подкачки включен подкачкой, ядро 2.6 находит, на каких дисковых блоках хранится файл подкачки, так что, когда приходит время подкачки, он вообще не имеет дела с файловой системой.
Таким образом, если файл подкачки не фрагментирован, это точно так же, как если бы в том же месте был раздел подкачки. Или, другими словами, вы получите идентичную производительность, если бы использовали необработанный раздел подкачки или отформатировали его с файловой системой, а затем создали файл подкачки, который заполнил все пространство, поскольку в любом случае на этом диске есть непрерывная область, используемая для подкачки, которые ядро использует напрямую.
Таким образом, если вы создаете файл подкачки, когда файловая система свежая (таким образом, гарантируя, что она не фрагментирована и в начале тома), производительность должна быть такой же, как при наличии раздела подкачки непосредственно перед томом. Кроме того, если кто-то создал файл подкачки, скажем, в середине тома, с файлами по обе стороны, можно получить лучшую производительность, поскольку меньше требуется подкачки.
В Linux, если файл подкачки создается нефрагментированным и никогда не расширяется, он не может стать фрагментированным, по крайней мере, с обычными файловыми системами, такими как ext3 / 4. Он всегда будет использовать одни и те же блоки диска, которые являются смежными.
Я пришел к выводу, что единственное преимущество выделенного раздела подкачки - это гарантированная нефрагментация, когда вам нужно его расширить; если ваш своп никогда не будет расширен, файл, созданный в новой файловой системе, не требует дополнительного раздела.
На самом деле это не имеет большого значения, пока вы не используете разреженные файлы.
Создание «обычного» файла с помощью dd выделит файл (если это вообще возможно) за один прогон, в то время как создание разреженного файла сообщит вам, что у вас есть файл размером 10 ГБ, но на самом деле не используется все пространство. Я не совсем уверен, что mkswap все равно не будет выделять пространство, но обычно файл подкачки будет расти со временем и, следовательно, не будет выделять непрерывный сектор (как часть диска), а выделять блоки по мере необходимости, что приводит к фрагментация с течением времени (конечно, в зависимости от того, как вы используете диск)
Внутренне ядро Linux будет обращаться к базовым блокам файла подкачки более или менее напрямую - я не могу сейчас найти ссылку, что происходит под капотом, вы должны доверять мне в этом, если кто-то не найдет что-то более официальное. Все, что я могу сейчас придумать, это:
все это относится только к линейке ядер Linux 2.6.
Если вам нужна оптимальная производительность (и что это на самом деле? ... замена выполняется медленно, точка. Увеличьте оперативную память, чтобы не использовать Лучший производительность), вы захотите использовать раздел.
Это интересный вопрос, и я много читал о нем. Как правило, раздел подкачки лучше файла из-за базовой файловой системы. Но если вам всегда нужно увеличивать размер свопа, лучше использовать файл. До ядра 2.4 считалось, что раздел подкачки работает быстрее, чем файл, но теперь, с улучшениями ядра 2.6, производительность почти такая же.
Что-то я тоже нашел в Интернете.
http://www.go2linux.org/swap-file-vs-swap-partition
и
http://www.sunmanagers.org/pipermail/summaries/2005-November/006913.html
В нашей работе мы думаем, что, поскольку файл подкачки может стать фрагментированным, а фрагментация замедляет доступ к подкачке, раздел - лучший подход. Конечно, определение файла подкачки статического размера делает то же самое, но субъективно это кажется более аккуратным.
Это единственно верный подход? Наверное, нет, поскольку такая практика сложилась около 10 лет назад. Единственное серьезное изменение в технологии накопителей за прошедшие годы - сложность используемых нами RAID-контроллеров (мы еще не достаточно богаты для SSD). Увеличение размеров дисков означает, что создаваемый нами раздел подкачки находится ближе к началу накопителя, чем он был тогда, когда диски объемом 18 ГБ были стандартными, поэтому скорость подкачки даже выше, чем в былые времена.
Конечно, на наших ESX-систем на базе Windows, положение файла подкачки полностью, полностью спорно. Между файлом подкачки и пластинами физического диска существует так много уровней виртуализации, что это не имеет значения. Но мы храним его в отдельном разделе, потому что это стандарт.
Я думаю, что на данном этапе, если вы не используете ноутбук с конфигурацией, которая записывает данные в своп, когда он приостанавливается / спит, своп действительно следует рассматривать как «последнее средство». Лучше всего поместить в коробку достаточно оперативной памяти, чтобы она никогда не выгружалась на диск.
При этом раздел, вероятно, является лучшим способом с точки зрения производительности, хотя файл более гибкий. Просто убедитесь, что он на шпинделе 7200+ об / мин.
Использование файла подкачки может потребовать немного дополнительной памяти для преобразования файла в память. Мы говорим о менее 1 МБ памяти на 1 ГБ подкачки. Кэш файловой системы НЕ кэширует данные подкачки, а только данные организации, которые должны составлять большую часть дополнительных требований к памяти.
Кроме того, я сомневаюсь, что вы потеряете какую-либо разумную производительность, за исключением, может быть, одного из 1000 раз одного дополнительного поиска головы.
Забавный факт, использование zswap вместе с динамически расширяющимся файлом подкачки приводит к впечатляющему ускорению операций подкачки при очень небольших затратах, пока он не используется.