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

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

<ol> <li> <p>на жестких дисках пропускная способность и поиск часто быстрее к началу диска, потому что эти данные хранятся ближе к внешней области диска, которая имеет больше секторов на цилиндр. таким образом, создание раздела подкачки в начале диска может повысить производительность.</p> </li> <li> <p>для ядра linux 2.6 нет разницы в производительности между разделом подкачки и <i>нефрагментарный</i> файл подкачки. когда swapon включает раздел/файл подкачки, <a href="http://lkml.indiana.edu/hypermail/linux/kernel/0507.0/1690.html">ядро 2.6 находит, на каких дисковых блоках хранится файл подкачки</a> , поэтому, когда приходит время подкачки, ему не нужно иметь дело с файловой системой. совсем.</p> </li> </ol><p>таким образом, если файл подкачки не фрагментирован, это точно так же, как если бы в том же месте находился раздел подкачки. или, другими словами, вы получили бы одинаковую производительность, если бы вы использовали раздел подкачки raw или отформатировали его с помощью файловой системы, а затем создали файл подкачки, который заполнил все пространство, поскольку в любом случае на этом диске есть непрерывная область, используемая для подкачки, которое ядро использует напрямую.</p><p>таким образом, если создать файл подкачки, когда файловая система свежая (таким образом, она не фрагментирована и находится в начале тома), производительность должна быть такой же, как и у раздела подкачки непосредственно перед томом. кроме того, если кто-то создал файл подкачки в середине тома с файлами по обе стороны, можно получить более высокую производительность, так как меньше стремятся поменяться.</p><p>в linux, если файл подкачки создается не фрагментированным и никогда не расширяется, он не может стать фрагментированным, по крайней мере с обычными файловыми системами, такими как ext3/4. он всегда будет использовать одни и те же дисковые блоки, которые являются смежными.</p><p>я пришел к выводу, что единственным преимуществом выделенного раздела подкачки является гарантированная нефрагментация, когда вам нужно его расширить; если ваш своп никогда не будет расширен, файл, созданный в новой файловой системе, не требует дополнительного раздела.</p>

<p>на самом деле это не имеет большого значения, если вы не используете <a href="http://en.wikipedia.org/wiki/sparse\_file">разреженные файлы</a> .</p><p>создание "обычного" файла с помощью dd выделит файл (если это вообще возможно) за один прогон, а создание разреженного файла скажет вам, что у вас есть файл размером 10 гб, но фактически он не занимает все пространство. я не совсем уверен, что mkswap не будет выделять пространство в любом случае, но обычно файл подкачки будет расти со временем и, следовательно, не будет выделять непрерывный сектор (как в части диска), а будет выделять блоки по мере необходимости, что приведет к фрагментация с течением времени (конечно, в зависимости от вашего использования диска)</p><p>внутренне ядро linux будет более или менее напрямую обращаться к базовым блокам файла подкачки - я не могу сейчас найти ссылку на то, что происходит под капотом, вы должны верить мне в этом, если кто-то не найдет что-то более официальное. все, что я могу придумать прямо сейчас, это:</p><ul> <li> <a href="http://ask.slashdot.org/article.pl?sid=02/03/12/2029211&mode=thread&tid=106">обсуждение slashdot</a> </li> <li> <a href="http://en.wikipedia.org/wiki/paging#linux">пейджинговая статья в википедии</a> </li> <li> <a href="https://help.ubuntu.com/community/swapfaq">некоторые faq в ubunt</a> </li> </ul><p>все это относится только к линейке ядер linux версии 2.6.</p><p>если вам нужна оптимальная производительность (и что это такое, на самом деле? ... обмен происходит медленно, точка. увеличьте ram, чтобы вы не меняли местами для <em> лучшая </em> производительность), вы хотели бы использовать раздел.</p>

<p>это интересный вопрос, и много читал о том же. обычно раздел подкачки лучше файла из-за базовой файловой системы. но если вам всегда нужно увеличить размер вашего свопа, тогда файл - лучший вариант. до ядра 2.4 считалось, что раздел подкачки быстрее, чем файл, но теперь с улучшениями ядра 2.6 производительность почти одинакова.</p><p>что-то я также нашел в интернете.</p><p> <a href="http://www.go2linux.org/swap-file-vs-swap-partition">http://www.go2linux.org/swap-file-vs-swap-partition</a> </p><p>а также</p><p> <a href="http://www.sunmanagers.org/pipermail/summaries/2005-november/006913.html">http://www.sunmanagers.org/pipermail/summaries/2005-november/006913.html</a> </p>

<p>я думаю, что на том этапе, на котором мы сейчас находимся, если вы не используете ноутбук с конфигурацией, которая записывает данные в своп, когда он приостанавливается/спит, своп должен действительно считаться "последним средством". лучше всего поставить ram) в коробку, чтобы она никогда не вставляла страницы на диск.</p><p>при этом раздел, вероятно, является лучшим способом с точки зрения производительности, хотя файл является более гибким. просто убедитесь, что он на шпинделе 7200+ об/мин.</p>

<p>в нашей работе мы думаем, что, поскольку файл подкачки может стать фрагментированным, а фрагментация замедляет доступ к подкачке, лучше использовать раздел. конечно, определение статического размера файла подкачки делает то же самое, но это кажется субъективно более аккуратным.</p><p>является ли этот подход единственно верным? вероятно, нет, так как практика была создана около 10 лет назад. единственное существенное изменение в технологии накопителей за прошедшие годы - сложность используемых нами raid-контроллеров (мы еще недостаточно богаты для ssd). увеличение размеров дисков означает, что созданный нами раздел подкачки ближе к началу диска, чем это было тогда, когда диски емкостью 18 гб поставлялись в стандартной комплектации, поэтому скорости подкачки даже выше, чем в прежние времена.</p><p>конечно, на наших esx-систем на базе windows, положение файла подкачки полностью, полностью спорно. существует так много уровней виртуализации между файлом подкачки и дисками физического диска, что это просто не имеет значения. но мы держим его в отдельном разделе, потому что это просто стандарт.</p>

<p>использование файла подкачки может использовать немного дополнительной памяти для преобразования файла в память. мы говорим о менее чем 1 мб памяти на 1 гб подкачки. кэш файловой системы не кэширует подкачанные данные, а только организационные данные, что должно соответствовать большинству дополнительных требований к памяти.</p><p>кроме того, я сомневаюсь, что вы потеряете какую-либо разумную производительность, кроме, может быть, один раз в 1000 раз один дополнительный поиск головы.</p><p>забавный факт: использование zswap вместе с динамически расширяемым файлом подкачки приводит к впечатляющему ускорению операций подкачки при очень небольших затратах, когда они не используются.</p>