Нужен ли раздел Swap на сервере LAMP?


14

Нужно ли нам на самом деле менять раздел на Ubuntu-сервере с LAMP? Я думаю, что мне это не нужно, но лучше знать наверняка, не приведет ли это к непредсказуемому поведению.
На самом деле мои мысли были:

  • Сервер никогда не спит
  • Если это происходит, нужно подумать о балансировке нагрузки / формировании трафика и т. Д.

Правильно ли я могу отключить своп для производственного сервера?

Благодарность!

Ответы:


14

Правильно ли я могу отключить своп для производственного сервера?

Нет. Всегда есть место для обмена.

Я попытался запустить рабочий сервер без подкачки один раз и примерно неделю спустя, после обновления Wordpress, PHP начал потреблять гораздо больше оперативной памяти, чем мы рассчитывали. Когда у вас заканчивается ОЗУ и у вас включен режим подкачки, все замедляется (иногда сильно, иногда совсем немного, в зависимости от того, что там происходит), но вы можете войти в систему, найти проблему и попытаться ее исправить. Это.

Когда у вас заканчивается ОЗУ и у вас нет свопа, процессы умирают, все останавливается, и в большинстве случаев единственным вариантом является перезагрузка. Но до тех пор, пока вы не перезагрузите компьютер, возможно, что-то сломается.

В моем мире сломано гораздо хуже, чем медленно.

Конечно, если вы обнаружите, что ваша система постоянно использует большие части подкачки (она будет часто использовать некоторые просто как способ удаления старых кэшированных данных), у вас, очевидно, есть проблема («вставьте ОЗУ, пожалуйста»), но ее сеть безопасности определенно рекомендуется.


В ответ на комментарий от SpamapS:

В мире «успешных веб-сайтов» у вас есть горячие отказоустойчивости, балансировка нагрузки и другие инструменты, которые позволяют машине взрываться и не оказывают никакого влияния на остальную часть сайта. Но это занимает много денег. Наличие избыточного оборудования не выгодно для большинства сайтов, даже если они тратят деньги.

Я полностью не согласен с вашим комментарием по поводу доступности. В традиционной системе электронной коммерции, если люди не видят ваш сайт, они не могут покупать у вас. Это не просто электронная коммерция, все коммерческие интересы в Интернете становятся намного более плачевными, если вы находитесь в каком-либо периоде. Я знаю, потому что я размещаю сайты и услуги для компаний и управляю своими собственными сайтами. Медленно = сварливый, но вниз = ярость. Даже если вы выходите из строя только на минуту, если пользователь более двух раз видит уведомление об отказе в обслуживании, он полагает, что вы не можете поддерживать работу сайта.

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

Вы также предполагаете, что на машине работает только одна служба. Опять же, это может быть правдой, если у вас есть мегабаки, чтобы разделить все, но в реальном мире все смешивается. Несколько веб-сайтов, ssh-демоны, ftp-серверы, почтовые серверы и т. Д. Один процесс, попадающий в swap, может даже не повлиять на другой сервис. Без обмена все имеют равные шансы на мгновенное и случайное завершение. Вы не можете это контролировать.

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


То же самое и здесь, вроде ... это была ошибка с моей стороны, а не обдуманное решение. Сервер без свопа - это ад, который нужно починить, особенно если он решает убить sshd.
Хавьер Ривера

У меня около 16 Гб ОЗУ, половина кешируется для быстрого ввода-вывода, остальное для ЛАМПЫ, своп всегда свободен, или иногда бывает мало мегабайт, но я думаю, что он всегда выключен ...
Арман

3
В мире успешных сайтов безразличный хуже, чем сломанный. Пользователи на самом деле оценят сбой FAST (который, между прочим, ваш код веб-интерфейса javascript должен корректно обрабатывать), но они НЕНАВИЖУ вас за медлительность. Отмените обмен, это только задерживает неизбежное. -1
SpamapS

1
@Oli: Запуск N + 1 больше не требует мегабаксов или даже много баксов. На самом деле это даже не требует специальных навыков. Это неизбежно, что сервер выйдет из строя по любому количеству причин, и не так сложно, чтобы это не было проблемой. Если у вас есть автономный сервер LAMP, который делает все, то что стоит дороже; Настроить еще два и балансировщик нагрузки (на EC2 со снимками t1.micros и EBS, это может быть ОЧЕНЬ дешево), или ваш сайт необычайно медленно работает в самый большой день? Проверьте данные из Google ... Я думаю, что это ясно bit.ly/hB1AD1
SpamapS

1
Отличный ответ, охватывающий реальные случаи сервера. Добавление избыточного оборудования, LB, мониторинг, кэш-память ОЗУ и т. Д. Невероятно важны, и у вас будет время на их настройку и отладку, если вы не спешите, потому что вы сэкономили на обменном пространстве.
ImaginaryRobots

4

Я должен не согласиться с тем, чтобы иметь своп на производственных серверах.

По моему опыту, ротационная замена диска делает вашу систему менее предсказуемой и более склонной к срыву отказа всей системы. Популярный сервер с высокой нагрузкой, который делает что-либо с локальным медленным диском, быстро превратится во что-то гораздо худшее, чем состояние сбоя. Время отклика увеличится в 100 раз по сравнению с нормальным уровнем, и такие простые вещи, как вход в систему через консоль или ssh, могут занять минуты.

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

Без свопа ваш сервер LAMP просто убьет процессы, чтобы освободить оперативную память. Надлежащий мониторинг должен предупредить вас об этом и удалить серверы с производства, если критические процессы будут убиты. В худшем случае все ваши методы входа в систему убиты, и вы должны сделать полный сброс / выключение питания. Этот наихудший случай все еще столь же вероятен с неконтролируемой подменной машиной, но намного труднее обнаружить.

Если вы используете PHP, включите ограничения памяти и следите за своими ошибками в журналах. Вот трюк, установить предел ниже на вашем Dev сервере , чем в производстве. Если вы используете mod_php под apache, установите MaxRequestsPerChild в несколько тысяч, чтобы httpd умер, прежде чем он станет слишком большим со временем. Прежде всего, следите за использованием памяти! Часто со временем память переполняется, и вам просто нужно периодически перезапускать службу с утечками, пока вы устраняете проблему.


1
Спасибо за обмен вашего опыта. Я был с аналогичными проблемами, когда ssh принимал Inf. Я просто заставил процессы иметь ограниченную память, что позволило мне запустить ssh и исправить ошибки в скриптах.
Арман

Одна из самых интересных дискуссий о пространстве подкачки в производстве, которую я видел в Интернете. (вся тема, за и против)
дпб

3

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

Такая ситуация будет происходить много раз на сервере.

а). Неоптимизированный скрипт может потреблять большой объем памяти.
Б). Скрипты типа резервного копирования всегда будут занимать огромную память
в). интенсивное движение

Поэтому хорошей практикой является наличие некоторого пространства подкачки.

Более подробная информация: https://help.ubuntu.com/community/SwapFaq


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

aneeshep, если вы меняете местами во время интенсивного трафика, ваша система будет работать в 100 раз медленнее, чем обычно. Это вообще не приемлемо.
SpamapS

2

Использование свопа даст вам еще одну защиту от нестабильности сервера. Вполне может быть, что когда ОЗУ заканчивается, и на сервере без подкачки это может привести к мягкому сбою.

Я, наверное, сейчас в меньшинстве, когда говорю, что все равно имеет смысл, как они обычно рекомендовали, иметь в два раза больше свопа, чем у вас есть основная память. Даже в системе с 96 ГБ ОЗУ.

Это не стоит дорого, и если вам это понадобится однажды, вы будете рады, что получили его. Причиной включения свопа является просто очень простой анализ затрат и выгод. Сделай это! :-)


0

Я хотел бы поблагодарить Оли за красивый - я знаю старый - ответ. Я считаю разделение это всегда зеленая тема! Я полностью согласен со строкой поста Оли, и я хотел бы поделиться этим - конечно же, неправдоподобным - сценарием, который я использую для мониторинга использования подкачки моих серверов.

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

Я создаю этот сценарий каждые полчаса в производственной среде. Он отправит мне уведомление, если использование Swap! = 0k. В большинстве случаев я смогу оперативно расследовать / предпринять действия по этой проблеме, прежде чем что-то пойдет не так .

Ожидает, что у вас будут: bash, top, echo, awk и рабочая почтовая команда, без каких-либо проверок.

Надеюсь, это поможет.

#!/bin/bash
CURRSWAP=$(top -b -n1 |grep Swap |awk '{print $4}')
ECOMM="echo $CURRSWAP means healthy, I wont take any action."
CURRDATE=$(date)
MAILDST="your@email.addr"

case $CURRSWAP in
  [0]k) $ECOMM
        exit 0
        ;;
  *)    echo -e "Server: $HOSTNAME \n Date: $CURRDATE \n Current Swap partition usage: $CURRSWAP" | mail -s "Warning from $HOSTNAME" -- $MAILDST
        exit 0
        ;;
esac
exit 0
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.