своп раздел против файла для производительности?

Что лучше для производительности? Раздел ближе к внутренней части диска будет иметь более медленное время доступа, и мы должны дождаться, пока диск переключится между ОС и разделами подкачки.

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

Каков компромисс производительности?

Какое значение имеет наличие файла подкачки фиксированного размера?

Является ли это случаем, что переход на раздел подкачки будет дольше, но производительность будет выше, если он находится на разделе подкачки, чем если бы это был файл подкачки?

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

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

Таким образом, если файл подкачки не фрагментирован, это точно так же, как если бы в том же месте находился раздел подкачки. Или, другими словами, вы получили бы одинаковую производительность, если бы использовали раздел подкачки raw или отформатировали его с помощью файловой системы, а затем создали файл подкачки, который заполнил все пространство, поскольку в любом случае на этом диске есть непрерывная область, используемая для подкачки, которое ядро ​​использует напрямую.

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

В Linux, если файл подкачки создается не фрагментированным и никогда не расширяется, он не может стать фрагментированным, по крайней мере с обычными файловыми системами, такими как ext3 / 4. Он всегда будет использовать одни и те же дисковые блоки, которые являются смежными.

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

На самом деле это не имеет большого значения, если вы не используете разреженные файлы .

Создание «нормального» файла с помощью dd выделит файл (если это вообще возможно) за один прогон, а создание разреженного файла скажет вам, что у вас есть файл размером 10 ГБ, но на самом деле он не занимает все пространство. Я не совсем уверен, что mkswap не будет выделять пространство в любом случае, но обычно файл подкачки будет расти со временем и, следовательно, не будет выделять непрерывный сектор (как в части диска), а будет выделять блоки по мере необходимости, что приведет к фрагментация с течением времени (конечно, в зависимости от вашего использования диска)

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

• обсуждение слэшдота
• страничка в википедии
• некоторые часто задаваемые вопросы по Ubuntu

все это относится только к линейке ядер 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

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

При этом раздел, вероятно, является лучшим способом с точки зрения производительности, хотя файл является более гибким. Просто убедитесь, что он на шпинделе 7200+ об / мин.

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

Является ли этот подход единственно верным? Вероятно, нет, так как практика была создана около 10 лет назад. Единственное существенное изменение в технологии накопителей за прошедшие годы - это сложность используемых нами RAID-контроллеров (мы еще недостаточно богаты для SSD). Увеличение размеров дисков означает, что созданный нами раздел подкачки ближе к началу диска, чем это было тогда, когда диски емкостью 18 ГБ поставлялись в стандартной комплектации, поэтому скорости подкачки даже выше, чем в прежние времена.

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

Использование файла подкачки может использовать немного дополнительной памяти для преобразования файла в память. Мы говорим о менее чем 1 МБ памяти на 1 ГБ подкачки. Кэш файловой системы НЕ кэширует подкачанные данные, а только организационные данные, что должно соответствовать большинству дополнительных требований к памяти.

Кроме того, я сомневаюсь, что вы потеряете какую-либо разумную производительность, кроме, может быть, один раз в 1000 раз один дополнительный поиск головы.

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