Недавно мой друг сказал мне, что было бы неплохо отключить свопинг на веб-серверах Linux с достаточным объемом памяти. Мой сервер имеет 12 ГБ и в настоящее время использует 4 ГБ (не считая кеша и буферов) при пиковой нагрузке.
Его аргумент заключался в том, что в нормальной ситуации сервер никогда не будет использовать всю свою оперативную память, поэтому единственный способ столкнуться с ситуацией OutOfMemory - это ошибка / ddos / и т. Д. Итак, если своп повернут выключен системе не хватит памяти, что в конечном итоге приведет к сбою программы, занимающей память (скорее всего, процесса веб-сервера) и, возможно, некоторых других процессов. Если своп включен на он будет съедать как оперативную память, так и подкачку, и в конечном итоге приведет к тому же сбою, но перед этим он выгружает важные процессы, такие как sshd, на подкачку и начинает выполнять множество операций подкачки, что приводит к серьезному замедлению. Таким образом, когда система под ddos может перейти в полностью непригодное для использования состояние из-за огромных задержек, я, вероятно, не смогу войти в систему и убить процесс веб-сервера или запретить весь входящий трафик (все, кроме ssh).
Это правильно? Я что-то упускаю (например, тот факт, что раздел подкачки в некотором роде очень полезен, даже если у меня достаточно оперативной памяти)? Стоит выключить?
Я бы сказал, что это зависит от вашего варианта использования, и в остальных ответах это довольно хорошо. 4G swap - это, в конце концов, дешевый способ подкупить себя. И я чувствую, что именно из-за этой дешевизны люди не хотят его выключать.
Но позвольте мне ответить риторическим вопросом. Если деньги не проблема, и у вас есть выбор между двумя системами - одна с 12 ГБ ОЗУ и 4G подкачки, а другая с 16 ГБ ОЗУ и без подкачки - какую из них вы бы выбрали? К сожалению, большинство людей все равно ответят, что выбрали бы 16 ГБ ОЗУ и по-прежнему добавить 4G подкачки, чего я не понимаю.
И с другой стороны, я лично считаю, что система с подкачкой хуже, чем неисправная. В случае сбоя системы резервный сервер резервного копирования перейдет на работу гораздо раньше. А в режиме «активный-активный» (или с балансировкой нагрузки) аварийная система будет выведена из строя гораздо раньше. Снова выигрыш для системы без обмена.
НЕ рекомендуется отключать подкачку, даже если у вас достаточно памяти. Если вашему серверу нужно больше памяти, а он не получил его, он выйдет из строя. Однако этого можно избежать (до некоторой степени), если у вас есть область подкачки.
Да, при использовании подкачки производительность вашего сервера снизится, но, по крайней мере, он будет работоспособен и доступен. Затем вы можете запланировать добавление дополнительной памяти при необходимости, если ваш сервер начнет использовать подкачку.
я нашел эта страница говорю о свопе. Взгляните на 3-й раздел.
Вместо отключения свопа вы можете управлять обмен.
Нет, это плохая идея. "какой-то процесс сошел с ума" означает, что вы уже должны были заранее вызвать
ulimit -d
во время создания процесса или до него, чтобы установить ограничение на память для каждого сегмента данных процесса - И, возможно, ограничение на количество потоков
ulimit -T
за процесс. ulimit - ваш друг. Пожалуйста, прочтите одно из руководств по настройке памяти, прежде чем отключать свопинг. Вы также можете изменить параметры ядра на некоторые вещи, чтобы попытаться справиться с атаками DOS или плохими программами.
Посмотрите на это так: общая память в вашей системе - это RAM + swap. Если у вас 12 ГБ подкачки, вы просто уменьшите емкость системной виртуальной машины вдвое, отключив подкачку. Плохая идея. На самом деле это не дискуссия, это просто чтение того, что другие люди знали из прошлого плохого опыта в течение многих лет. Возможно, вашему другу тоже нужно почитать.
Как уже говорили другие, вы можете эффективно остановить свой сервер, используя подкачку, за исключением случаев, когда это абсолютно необходимо, повозившись с параметром «swappiness». Это контролирует, насколько агрессивно ядро будет выгружать страницы памяти.
Вы можете увидеть, на что он сейчас настроен:
cat /proc/sys/vm/swappiness
и вы можете редактировать его "вживую" с помощью (как root):
# echo "10" > /proc/sys/vm/swappiness
и чтобы он сохранялся, добавьте в /etc/sysctl.conf следующее:
vm.swappiness=10
Еще одна хорошая вещь, которую вы можете сделать, - это переключиться в RAM с помощью zRAM. Я считаю, что это отличная идея! Для производительности это похоже на отсутствие свопа вообще, но также предотвращает сбои, когда система очень загружена!
Посмотри на это:
http://www.webupd8.org/2011/10/increased-performance-in-linux-with.html
Мой опыт: На этой машине, на которой я сейчас пишу, я отключил своп, потому что у меня 4 Гб ОЗУ (в 2009 году это было много!). У меня возникла всего пара проблем, одна из них по ошибке открывала около 127 изображений одновременно!
НО .. это рабочая станция, и я могу позволить себе перезагрузку, если она зависнет. На сервере, я думаю, лучше иметь подкачку, и подкачка в ОЗУ мне нравится.
Как уже было совершенно ясно, это не лучшая идея. По крайней мере, своп дает вам некоторую передышку, когда дела идут не совсем нормально. например Я смотрю на одну систему, которая обычно имеет всего несколько посетителей в день, и произошел значительный всплеск трафика, вызванный упоминанием страницы в журнале. Это привело к тому, что веб-сервер впервые с момента ввода в эксплуатацию использовал пространство подкачки. Без этого места подкачки дела пошли бы не очень хорошо.
Не хорошая идея. Вы можете определить 2 файла подкачки с разным приоритетом. Один меньшего размера, который используется, и один большего размера, который будет использоваться в случае первого заполнения.
Также vm.swappiness может помочь вам контролировать, насколько агрессивно происходит подкачка диска.
Если вы вставите 0 в vm.swappiness, это не обязательно означает, что система не будет менять местами. Это параметр, определяющий, насколько агрессивной будет тенденция керна к подкачке, но он не отключает подкачку.
Опять же, свопинг - это неплохо, но трэшинг - это плохо. Взгляните на данные sysstat, и они должны дать довольно хороший указатель на них.