Чи потрібен насправді поміняти розділ на ubuntu-сервері LAMP? Я думаю, мені це не потрібно, але краще точно знати, чи це не спричинить якусь непередбачувану поведінку.
Насправді мої думки були:
Чи я правий, чи можу вимкнути заміну для сервера виробництва?
Спасибі!
Відповіді:
Чи я правий, чи можу вимкнути заміну для сервера виробництва?
Ні. Завжди майте місце для заміни.
Я спробував запустити виробничий сервер один раз і приблизно через тиждень, після оновлення Wordpress, PHP почав їсти набагато більше оперативної пам'яті, ніж ми рахували. Коли у вас закінчилася оперативна пам’ять і у вас увімкнено заміну, все сповільнюється (іноді багато, іноді просто небагато, залежно від того, що потрапило туди), але ви можете увійти, знайти проблему та спробувати виправити це.
Коли у вас закінчується оперативна пам’ять і не відбувається заміну, процеси вмирають, все затримується, і багато часу ваш єдиний варіант - це перезавантаження. Але поки ви не зробите цю перезавантаження, все, ймовірно, зламається.
У моєму світі зламане набагато гірше, ніж повільне.
Звичайно, якщо ви виявите, що ваша система постійно використовує великі порції swap (вона дуже часто використовує деякі просто як спосіб переміщення старих кешованих речей), у вас, очевидно, виникає проблема ("вставити RAM будь ласка"), але мати її як Безпечна сітка, безумовно, рекомендується.
У відповідь на коментар SpamapS:
У світі "успішних веб-сайтів" у вас є гарячі відмовки, балансування завантаження та інші інструменти, які дозволяють машині вибухнути і мати нульовий вплив на решту сайту. Але це вимагає багато грошей. Наявність зайвого обладнання не є економічним для більшості сайтів, навіть якщо вони залучають гроші.
Я повністю не згоден з вашим коментарем щодо оновлення. У традиційній системі електронної комерції, якщо люди не можуть бачити ваш сайт, вони не можуть купувати у вас. Це не просто електронна комерція, якщо всі комерційні інтереси в Інтернеті займають набагато більше уваги, якщо ви перебуваєте на будь-який період. Я знаю, бо розміщую сайти та служби для компаній та керую своїми власними сайтами. Повільно = бурхливо, але вниз = лють. Навіть якщо ви спускаєтесь лише на хвилину, якщо користувач бачить повідомлення про "непридатність для обслуговування" більше ніж кілька разів, вони припускають, що ви не можете тримати сайт.
Повільний сервер є менш ідеальним, але своп не має працювати постійно, це в крайньому випадку, щоб дозволити речам працювати, поки ви їх виправляєте.
Ви також припускаєте, що на машині працює лише одна служба. Знову ж це може бути правдою, якщо у вас є мегабуки, щоб розділити все, але в реальному світі все зібралося разом. Кілька веб-сайтів, ssh-демон, ftp-сервери, сервери електронної пошти тощо. Один процес, що протікає в свопі, може навіть не вплинути на іншу послугу. Без свопу все має рівний шанс на миттєве, випадкове припинення. Ви не маєте над цим контролю.
Звичайно, своп - не єдина відповідь. Вам потрібен моніторинг, щоб попереджати вас про те, що у вас немає барана, але просто витягнути штекер та перезавантажити не є відповіддю для більшості людей. Я впевнений, що це працює для будь-якого багатонаціонального веб-сайту, за який ви несете відповідальність, а лише для нас простих смертних (які складають більшість Інтернету), і це комерційне самогубство.
Я не погоджуюся з тим, щоб проводити обмін на виробничих серверах.
На мій досвід, обертовий обмін диска робить вашу систему менш передбачуваною та більш схильною до розладів всієї системи. Популярний сервер із високим навантаженням, який робить що-небудь із локальним повільним диском, швидко перетвориться на щось набагато гірше, ніж у стан відмови. Час відповідей підвищиться до 100x свого нормального рівня, а прості речі, такі як вхід через консоль або ssh, можуть зайняти кілька хвилин.
SSP-swap - це окремий випадок і, принаймні, усуне сповільнення часу пошуку, яке зазвичай вбиває систему. Однак записи все ще повільні, тому ви все-таки будете чекати довгий і довгий час, щоб відновитись поза процесом контролю.
Без підкачки ваш LAMP-сервер просто знищить процеси, щоб звільнити оперативну пам’ять. Правильний моніторинг повинен попереджати вас про це та видаляти сервери з виробництва, якщо критичні процеси будуть вбиті. Найгіршим випадком є те, що всі ваші методи входу вбиваються, і вам доведеться провести жорсткий цикл скидання / живлення. Цей найгірший випадок все ще настільки ж ймовірний із машиною, що перебуває поза контролем, але виявити набагато складніше.
Якщо ви використовуєте PHP, увімкніть обмеження пам'яті та стежте за тим, щоб ваші журнали не виникали. Ось хитрість: встановіть ліміт на вашому сервері розробників нижчим, ніж у виробництві. Якщо ви використовуєте mod_php в апаші, встановіть MaxRequestsPerChild на кілька тисяч, щоб httpd помер, перш ніж вирости занадто великим. Перш за все, слідкуйте за використанням пам'яті! Часто пам’ять повзає з часом, і вам просто потрібно періодично перезапускати пропускний сервіс під час налагодження проблеми.
Простір для обміну використовується, коли ваша система вирішить, що фізична пам'ять їй потрібна для активних процесів і недостатньо невикористаної фізичної пам'яті. Якщо системі потрібно більше ресурсів пам'яті або місця, неактивні сторінки фізичної пам’яті переміщуються до місця обміну, вивільняючи цю фізичну пам’ять для інших цілей.
Така ситуація буде багато разів траплятися на сервері.
а). Неоптимізований сценарій може споживати велику кількість пам'яті
b). Сценарії, такі як резервне копіювання, завжди будуть споживати величезну пам'ять
c). інтенсивний рух
Тож є хорошою практикою мати місце для заміни.
Детальніше: https://help.ubuntu.com/community/SwapFaq
Використання swap дасть вам додатковий захист від нестабільності сервера. Цілком може бути час, коли оперативна пам’ять закінчується, і на сервері без заміни, що може призвести до м'якого збою.
Я, мабуть, зараз у меншості, коли я кажу, все одно має сенс, як і раніше, рекомендувати проводити в два рази більше своп, ніж у вас основна пам'ять. Навіть на системі з 96 ГБ оперативної пам’яті.
Це не дорого коштує, і якщо вам це буде потрібно одного дня, ви будете раді, що отримали його. Причиною включення свопу є лише дуже простий аналіз витрат і вигод. Зроби це! :-)
Я хотів би подякувати Олі за прекрасну - я знаю стару - відповідь. Я вважаю, що розділення - це завжди зелена тема! Я повністю згоден з рядком поста Олі, і я хотів би поділитися цим сценарієм, - звичайно, незмінним -, який я використовую для моніторингу використання своїх серверів своп.
Я завжди налаштовую сервери та сервіси для роботи без виникнення змін. Коли це станеться, будьте впевнені, що щось або піде не так, або в кращому випадку щось переверне ваші початкові плани.
Я створюю цей сценарій кожні півгодини у виробничих умовах. Він надішле мені сповіщення, якщо використовувати 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