Своп файл: что лучше один или два?

+

+

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

кстати, требования к "скорости" работы не высоки, быстрого отклика как раз и не требуется, важна скорее "стабильность" работы

ну а своп - для подстраховки, (к тому же если устанавливать тот же центос и автоматом разбить диск - своп раздел создается равный размеру озу - не зря же))

---------- Добавлено 21.10.2014 в 00:40 ----------

для меня пока никакое, просто некоторые здесь пытаются меня убедить, что "своп - зло" и "все станет раком" - так вот я и хотел узнать что именно будет происходить когда "все станет раком"

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

я просто задал банальный вопрос, как лучше сделать 2 гб свопа, либо добавить еще один такой же на 1 гб, либо удалить первый и добавить один на 2 гб (либо же третий вариант - без разницы)

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

кароче, давайте закроем эту тему!

Если вдруг "все станет раком", это произойдёт довольно быстро и вы вряд ли успеете заметить какие-то симптомы :)

Когда не хватает памяти, система запихивает в своп процессы, наименее интенсивно использующие память. Но если общая интенсивность обращения таких процессов к памяти достаточно высока, она может (самостоятельно или в совокупности с другими процессами) превысить возможности дисковой системы. В результате чего произойдёт цепная реакция и возникнет ситуация, издревле известная администраторам как "система ушла в своп".

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

Где чушь?:)

Своп файл, выгружая на диск, одновременно затормаживает его!😂

Лучше купить дополнительную планку оперативной памяти, чем создавать своп файлы!🍿

Ну если у ТС свап начнет активно использоваться - он купит память, а так - нет.

Для тех, кто не в курсе: своп создается чуть большим размером, чем RAM при установке дистрибов по дефолту на случай использования _спящего_ режима (линуксы засыпают в своп). В остальном его использование в большинстве случаев оправдано только если память "течет" - тогда неиспользуемые блоки памяти сваливаются в своп и там лежат до перезапуска или остановки сервиса. Во всех остальных случаях производительность HDD настолько низка, что сколь-нибудь значительный обмен данными со свопом ставит систему раком. Исключение - SSD, но такое использование диска не целесообразно.

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

может кто обьяснить - почему большой своп на ссд не будет спасением при нехватки оперативки? насколько хуже будет работать ФС в момент заполнения свопа на 2-3гб например?

спасибо :)

---------- Добавлено 23.10.2014 в 16:07 ----------

а вот кстати интересное дело.. вам знакомо наверное в момент билда исходников случается ООМ и билд не проходит. я только что добавил 2гб свопа на свой экспериментальный амазон сервер (микро, 1гб рам) и хотел проверить пройдет ли тяжелый билд который обычно не проходит на 1гб (взял mapnik - штука для open-street-map сервера с картами)

так вот, смотрю в одном окошке free. в другом смотрю на какой стадии сдохнет билд.

память быстренько заполняется до 1гб, в своп выгружается 6 МБ всего! и билд останавливается, на том же месте, как и всегда при 1гб.

может кто знает что за безобразие? почему RHEL6.5 не хочет юзать своп хотя бы в такой "экстренной" ситуации, что бы просто закончить билд и все. ведь было бы полезно. нужна мне прога вот на сервере с 1гб, а скомпилировать ее надо 3гб например. если бы через свап процесс можно было бы довести до конца, было бы удобно :( .

подскажите что делать? оно хоть и копейки стоит на амазоне, а знать хочется все равно, почему проги не билдятся в свопе :) .

спасибо!

Потому что вот: http://computer.howstuffworks.com/virtual-memory.htm

Я сказал "нецелесообразно" - первое. Скорость рандомного чтения/записи всё же как-то спасёт, но (!) оперативка прокачивает

несколько больше (прогоните такую же штуку на SSD - медленне, да? А у меня ноут с не самой шустрой памятью, на серверах там до 10 Гб/с можно легко получить - и да, с реальной скоростью оперативки оно не сильно коррелирует - просто общий "попугай"). Второй момент - не будет работать технология trim, к примеру - а это значит, что при записи будет значительное замедление при перезаписи блоков. Такие дела... Ну и сжирание ресурса самого SSD ни к чему хорошему не приводит: постоянная работа со свопом в силу технологии быстро убьет твердотельник, как замена оперативке он не катит. Кстати, я не говорил, что HDD проработает дольше :D.

overcommit виноват.

спасибо.

А можно как то заставить линукс все таки использовать своп именно хотя бы для окончания этой билд операции? указать что этот таск до конца надо сделать во что бы то ни стало, и юзай своп :) это возможно?

оверкомит:

vm.overcommit_memory = 2 (пробвал 1 и 2)

vm.overcommit_ratio = 100

не помогло. ни 1 ни 2. доходит до той же точки билда. может есть еще какой параметр кроме этих двух? гуглю, но про другие не пишут нигде.. тока эти 2...

Размечает памяти больше, чем доступно со свопом. Virtual memory