В общем есть 2 вопроса:
1. Что лучше/надо использовать под swap раздел или же файл?
2. Какой объём swap нужно делать для сервера?
Мои мысли таковы:
Лучше использовать раздел ибо если использовать файл то будет дополнительная прослойка, а так swap будет размечаться напрямую на своей fs
Для десктопа понятно (1,5-2)*RAM (1,5 или 2 зависит от объёма RAM на компе) это понятно. А вот для сервера думаю 0,5*RAM *SCRATCH* Было дело в сети встречал такое же мнение *DRINK*
LinuxForum.Fans
Пара вопросов по swap
Автор: lone_wolf
52 сообщений
2252 просмотров
lone_wolf, :) Размр под SWAP определяте сами. Это как вам удобно.
Если сервер достаточно мощный, то вообще подкачку не делать.
Если же решили заняться своппингом, то делайте разделом.
Если сервер достаточно мощный, то вообще подкачку не делать.
Тему создать я решил после прочтения статьи на хабре, в которой рекомендуют какой бы не был сервер создавать подкачку.
Добавлено: 16.02.2018 20:03:10
Размр под SWAP определяте сами. Это как вам удобно.
это да, у каждого свой взгляд на данную тему.
Для десктопа понятно (1,5-2)*RAM
М.б. для ноута - спящий режим и т.п... Сервер не спит.... , но - подкачка бывает нужна... Файл - да, ИМХО, прослойка... лучше уж раздел, но бывают ситуациии :D ИМХО, лучше раздел, хотя.....
Подкачка нужна. Сколько бы ни было памяти, возможен вариант, что кто-нибудь ее всю съест. И тут начинается разница: без swap система резко встает колом так, что невозможно что-либо сделать. А по мере его заполнения система начинает заметно замедляться, но так, что можно, например, найти и прибить взбесившийся процесс.
С размером тоже просто: если он по сравнению с ram маловат, то от него и пользы мало. Если велик, то система слишком затормозится задолго до его полного заполнения. Так что размер 50...200% памяти считается разумным.
Верно.Подкачка нужна. Сколько бы ни было памяти, возможен вариант, что кто-нибудь ее всю съест.
Но подкачка нужна не только для этого. Для гипернейта, кстати, и желательно не в файл, а на отдельный диск. И вот в этом случае размер подкачки должен быть равен объему памяти. А вообще своп рассчитывался всегда так VSwap=VRAM*2. Ограничения на использование памяти явно вылезают только в оффтопике, а в пингвинарии такого никогда не наблюдалось (в x64 - по умолчанию, в x686 - при ядре PAE).
Добавлено: 17.02.2018 22:05:30
Да, да. Внезапное отключение ЭЭ, совсем не влияет на работу сервера, особенно, когда длится пару дней (Какой UPS такое перенесет?). В этом случае не в спящий, и не выключать, а в гипернейт лучше переводить, чтобы сохранить все, что было на момент "ooops" UPS'а.Сервер не спит....
Для гипернейта, кстати, и желательно (1) не в файл, а на отдельный диск. И вот в этом случае (2) размер подкачки должен быть равен объему памяти.
Источник сих двух "мудрых" утверждений можно узнать?
Ежели что, оба два противоречат официальной документации ядра.
PS. В части "на отдельный диск" vs. "файл/раздел на том же диске" -- не противоречат.
Добавлено: 17.02.2018 20:13:57
Лучше использовать раздел ибо если использовать файл то будет дополнительная прослойка, а так swap будет размечаться напрямую на своей fs
Точно будет? Будет именно при использовании файла подкачки (сейчас речь не про создание файла подкачки)?
Задумайтесь, как бы из такого файла могла восстанавливаться система, возвращаясь из гибернации, если бы работала с ним используя в качестве прослойки ФС?
Ага, я в принципе раздел тоже имел в виду.В части "на отдельный диск" vs. "файл/раздел на том же диске" -- не противоречат.
А почему не в файл, а в раздел/диск, чтобы меньше хлама валялось. И представьте себе файлик в 64 или в 128 гигов? А если еще больше?
P.S. А почему лучше другой диск для сервера - это быстродействие. Если же брать раздел на том же диске, где и система, то скорость восстановления немного скучней будет.
Точно будет? Будет именно при использовании файла подкачки (сейчас речь не про создание файла подкачки)?
Задумайтесь, как бы из такого файла могла восстанавливаться система, возвращаясь из гибернации, если бы работала с ним используя в качестве прослойки ФС?
Да согласен, оно бы не работало *SCRATCH*
Лучше в файле делать. Разницу с разделом вы не заметить, зато сможете гибко менять размер подкачки.
В целом, если система построена нормально и свап не требуется для работы, можно его и отключить. В крайнем случае система не "встанет колом", а избавится от жрущего процесса через OOM kill.
Есть вариант без swapoff/swapon?зато сможете гибко менять размер подкачки
Есть вариант без swapoff/swapon?[/quote][quote="Vascom"] зато сможете гибко менять размер подкачки
Нет. А чем он не устраивает?
Просто не понял, в чем в этом случае гибкость изменения размера подкачки.Нет. А чем он не устраивает?
С "зато сможете менять размер подкачки" не спорю. Но вот назвать гибкостью swapoff / swapon язык не повернется.
Кстати, что будет, когда ФС фрагментирована настолько, что одним куском файл желаемого размера выделить нельзя, корректно этот случай обрабатывается (не могу вспомнить)?
Кстати, что будет, когда ФС фрагментирована настолько, что одним куском файл желаемого размера выделить нельзя, корректно этот случай обрабатывается (не могу вспомнить)?
Непрерывность и не требуется, нужно только, чтобы все блоки были аллокированы на диске.
И, похоже, вы неправильно понимаете назначение swapon и swapoff. Они лишь включают и выключают использование предварительно подготовленных областей подкачки. А готовить их надо с помощью mkswap
И заодно про фрагментацию: она фрагментируется "настолько" только если места совсем мало, у файловой системы дурная структура (как у FAT) или у драйвера глупая стратегия работы со свободным местом. В общем, это "не наши проблемы"
Правильно-правильно, или вы умеете сделать mkswap на неотключенном swapspace ^) ?похоже, вы неправильно понимаете назначение swapon и swapoff
А в остальном все так, mkswap готовит список аллоцированных блоков, дальнейшее обращение идет по этому списку мимо ФС. Разреженный (sparse) файл использовать под swapfile нельзя.
Потому и говорю -- "гибко" слишком громко сказано. Если только добавить еще несколько свап-файлов, так и к разделу их добавить тоже никто не помешает. Единственно, что в голову приходит, при малом размере свап-раздела и интенсивной на него нагрузке есть риск получить в этом месте поврежденную область. (По крайней мере диски "протёртые до дыр" в области $MFT на NTFS-разделе в руках держать приходилось ^) ) Но свап-фалы регулярно гонять по диску не сильно проще ^)
bormant, нет никаких причин изменять его на лету. Да и вообще особых причин его изменять нет. Если хотите увеличить -- создайте и подключите ещё один.
Но если он у вас используется регулярно -- задумайтесь о добавлении ram
s.xbatob,
не надо писать это мне, пишите Vascom, это его идея "гибко менять размер подкачки" (сообщение #10).
То есть протереть диск разделом swap - вам не страшно?
Конечно гибкость ограниченная и не "на лету", но всё равно она выше, чем при исмользовании раздела. Ведь чтобы увеличить или уменьшить раздел вам придётся отрезать куски от обычных разделов.
Ну и опять же: не надо закладываться на использование swap вообще. Если он используется - что-то в системе не так и надо добавлять ОЗУ.
bormant, Нет уж, реплика была именно вам! Идеи vascom неоднозначные, но разумные. Ваши же -- на грани каприза.
Идеи vascom неоднозначные, но разумные. Ваши же -- на грани каприза.
Какие такие мои идеи? Мои были только замечания про "гибко" в той части, что "гибко" не получится.
swap file:
1. смена размера: swapoff, dd/rm/..., mkswap, swapon. Если причиной стала нехватка памяти, то этот сценарий из-за необходимости swapoff не сработает, с этим-то никто не спорит, надеюсь.
2. добавление места: dd, mkswap, swapon
swap partition:
1. смена размера: в меньшую сторону -- ровно также, fdisk вместо dd, вернуть место для полезного использования сложнее, но сколько там того места?
2. добавление места: добавим swap file, см. п.2 выше.
Вот про это вот и было замечание -- ровно то ж на то ж и выходит.
Если речь об экстремально малом носителе, возможно, предмет стоил бы какого-то обсуждения...
Войдите или зарегистрируйтесь, чтобы ответить.
