Вопрос: подкачка раздела vs файл для производительности?


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

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

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

Сколько стоит фиксированный размер swapfile?

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


51
2018-06-15 03:06


Источник


Просто из любопытства. Можете ли вы предоставить системные данные, такие как версия ядра, оперативная память, раздел и схема файловой системы? - Viky
На какой ОС вы ищете? - Mathieu Chateau
Для информации о Linux см. lkml.org/lkml/2005/7/7/326 - Adam Monsen


Ответы:


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

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

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

все это относится только к линейке ядер 2.6.

Если вам нужна оптимальная производительность (и что это такое, на самом деле? ... обмен медленный, период. Увеличьте объем оперативной памяти, чтобы не менять Лучший производительность), вы хотели бы использовать раздел.


21
2018-06-15 08:28



Современные версии swapon полностью откажутся работать с разреженными файлами, отформатированными как swap, ссылаясь на то, что в файле есть отверстия. - Tim Post♦


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

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

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

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

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

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


20
2018-06-07 13:48



Единственное, что нужно добавить здесь, это то, что если ваша машина настроена на «приостановку на диск», то на самом деле происходит то, что материал в памяти записывается для обмена. Чтобы это сработало, своп должен быть на своем собственном разделе, так как своп не может быть в активной файловой системе, чтобы это произошло. Поэтому, если у вас есть сервер, вы, вероятно, не используете эту функцию и можете с радостью использовать файл подкачки. Если у вас есть ноутбук, вам, вероятно, нужен раздел подкачки, чтобы вы могли «приостановить файл» для спящего режима. - Nathan S. Watson-Haigh
@ NathanS.Watson-Haigh Что происходит с данными, которые уже находятся в свопинге? Его нельзя выбросить. - XTF
@ NathanS.Watson-Haigh Вы можете связать источник? Ubuntu 17.04 использует файл подкачки по умолчанию. Было бы удивительно, если бы он не мог «приостановить диск». - Matthias Weiler


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

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


3
2018-06-15 03:21



Почему раздел должен быть более эффективным с точки зрения производительности, когда время доступа может быть скорее фактором задержки? - Bill Gray
Поскольку для использования файла может потребоваться больше движений головы, поскольку при поиске страницы для чтения / записи данные могут быть в любом месте файловой системы, поэтому, возможно, нужно будет искать структуры fs, тогда как с разделом подкачки каждая страница будет находиться в известном месте в пределах раздел. Это делает время доступа (в зависимости от объемной пропускной способности) дифференцирующим фактором. - David Spillett
«Не настраивайте подкачки, если нет необходимости в спящем режиме» спорный вид. Иногда, когда система находится на низком уровне, реальный обмен памяти может позволить системе восстановить. Не имея swap может ограничить вас от запуска программ, которые делают огромные выделения памяти, но на самом деле не затрагивают большинство из них (например, некоторые инструменты отладки). Иногда занятый, но незанятый регион памяти лучше использовать в качестве дискового кэша, и этот компромисс может быть выполнен только в том случае, если имеется своп. Видеть unix.stackexchange.com/questions/2658/... для обсуждения. - Anon


Это интересный вопрос и много читал о том же. Как правило, раздел подкачки лучше, чем файл из-за базовой файловой системы. Но если вы всегда нуждаетесь в увеличении размера своего свопа, тогда файл является лучшим вариантом. До появления ядра 2.4 считалось, что раздел подкачки быстрее, чем файл, но теперь с улучшениями ядра 2.6 производительность практически не изменилась.

Что-то я нашел и в интернете.

http://www.go2linux.org/swap-file-vs-swap-partition

а также

http://www.sunmanagers.org/pipermail/summaries/2005-November/006913.html


3
2018-06-15 03:27



Однако ни одна из этих ссылок не объясняет причины их решений. - Bill Gray
Причиной является то, что файл будет иметь перегруженную файловую систему. Если вы создадите файл, его можно будет отбросить. и в зависимости от файла, который кэшируется при свопинге, чтение может быть медленным по сравнению со всем разделом, который является файловой системой подкачки в своем собственном. - Viky
Пытался копать дальше и нашел относительную статью по вики. Чтобы помочь вам, есть несколько параметров настройки подкачки, которые вы можете проверить. Также ознакомьтесь с пояснениями по поводу реализации для linux. Может помочь. en.wikipedia.org/wiki/Paging - Viky
Последовал один из ссылок на вышеупомянутую ссылку на wiki и нашел интересную тему о той же проблеме. Можете проверить это. lkml.org/lkml/2005/6/28/427 - Viky
Я упомянул о перегрузке файловой системы в моем вопросе, но это не такой блок производительности, как наличие раздела рядом с внутренним диском. Эта задержка будет отличной, чем накладные расходы файловой системы. - Bill Gray


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

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

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


3
2018-06-15 05:12



Файл подкачки не фрагментируется, так как ядро ​​использует прямой метод mmap и никогда не будет увеличивать или сокращать файл. +1 хотя для вашего комментария о виртуализации: это часто не имеет значения. - parasietje


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

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

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


0
2017-07-14 16:22



Можете ли вы предоставить какие-либо обоснования для своих требований? Это кажется довольно анекдотическим. - austinian