Как часто мне следует перезагружать серверы Linux?


30

У меня есть много серверов Linux (SUSE 9 и 10), используемых для запуска веб-сервисов, которые предоставляют данные в большие расчетные сетки. Недавно у нас возникли некоторые трудности с объяснением сбоев (т. Е. В журналах аппаратного и программного обеспечения не было выявлено каких-либо явных ошибок), и мы начинаем задумываться о том, является ли проблема длительным временем безотказной работы (обычно 200–300 дней). Учитывая, что эти серверы интенсивно используются, я должен рассмотреть регулярный цикл перезагрузки?

Ответы:


47

Вы должны перезагрузиться после обновления ядра (если вы не используете KSplice), все остальное не является обязательным. Лично я перезагружаюсь ежемесячно во время периода обслуживания, чтобы убедиться, что сервер и все службы возвращаются, как ожидалось. Таким образом, я могу быть достаточно уверен, если мне придется выполнить внеплановую перезагрузку (то есть критическое обновление ядра), что система вернется к нормальной работе. Автоматизированный мониторинг серверов и служб (например, Nagios) также помогает этому процессу (перезагрузите компьютер, посмотрите, как загорятся красные индикаторы, а затем, надеюсь, все снова станет зеленым).

PS, если вы регулярно перезагружаетесь, вам нужно убедиться, что вы настроили свои проверки fsck (т. Е. Максимальное число монтирований между проверками надлежащим образом, в противном случае быстрая 2-минутная перезагрузка может занять 30 минут, если сервер начинает fsck, собирая пару терабайт данных. Обычно я устанавливаю счетчик монтирования равным 0 (tune2fs -c 0) и интервал между проверками до 6 месяцев или около того, а затем вручную принудительно запускаю fsck время от времени и сбрасываю счетчик.


1
Регулярное тестирование DRBCP является обязательным, и этот тип проверки является отличным началом в этом направлении.
Скотт Пак

Вам не нужно перезагружаться после обновления ядра - ksplice.com
raspi

1
KSplice верен, с KSplice вы можете использовать патч, работающий с программным обеспечением (ядро, база данных и т. Д.). Однако, поскольку Oracle купил KSplice, это, вероятно, не решение для тех, кто не использует Oracle (кто недавно купил KSplice).
Курт

11

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


6

Серверы Linux никогда не нужно перезагружать, если вам абсолютно не нужно менять работающую версию ядра. Большинство проблем можно решить, изменив файл конфигурации и перезапустив службу с помощью сценария инициализации.

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

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


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

1
@JonasDralle, службы должны автоматически останавливаться и перезапускаться при обновлении. В противном случае, это ошибка в реализации этого сервиса!
Алексис Уилке

4

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


3
Linux может нормально обрабатывать свою память, а отдельные приложения - нет - их кучи могут стать фрагментированными, если они будут работать долго. Конечно, такие вещи, как prefork Apache (который перерабатывает свои процессы), обычно не страдают от этого. Другие вещи, которые используют один очень долгоживущий процесс (например, MySQL), могут. Зависит от вашего приложения.
MarkR

4

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

Например, даже простые вещи, такие как / bin / ls и другие вещи в / bin, используют libc. Если вы просто используете консоль и используете bash, вы используете libc.

$ ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
        libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
        libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
        /lib/ld-linux.so.2 (0xb804b000)

$ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
        libc.so.6 => /lib/libc.so.6 (0xb7de7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f61000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)

И да, если вы измените файлы в /etc/init.d, которые каким-то образом влияют на запуск, я бы порекомендовал перезагрузку. Вы не хотите узнавать, что допустили небольшую ошибку в файле запуска, когда вам нужно быстро все запустить и запустить снова.

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

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


3
+1 за «перезагрузку раньше»
kubanczyk

2

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


+1 - не все сбои вызваны проблемой с ядром.
pcapademic

2

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


1

Для правильной работы Linux-сервера необходима только перезагрузка для обновления ядра. То же самое не всегда может быть сказано для некоторых программ - например, мне иногда приходится перезапускать apache2 или mailman.


0

В моей инфраструктуре есть два сайта данных: альфа (где операции выполняются ежедневно) и бета (резервный сайт, на случай, если в альфе что-то пойдет не так). Хотя в настоящее время это не так, я настаиваю на запланированном простое на альфа-сайте каждые 6 месяцев, чтобы мы могли запускать все службы из бета-версии.

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

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


0

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

Что я имею в виду под этим ...

  • /etc/init.d/*
    • Убедитесь, что все службы, запущенные в данный момент, помечены для запуска при загрузке.
    • Убедитесь, что все не запущенные сервисы помечены как не запускающиеся при загрузке
  • /etc/fstab
    • Убедитесь, что все смонтированные файловые системы (т.е. /etc/mtab) имеют соответствующую запись в/etc/fstab
    • Убедитесь, что все файловые системы, указанные для монтирования при загрузке /etc/fstab, также смонтированы.

Это, конечно, не полная проверка какими-либо средствами, но она снижает риск возникновения проблем после перезагрузки.

В дополнение к этому, вы должны (imo) установить политику для обновлений пакетов серверов, в некотором разумном порядке, скажем, 1 группа в неделю ...

  • Crash & Burn Сервера
  • Серверы разработки, серверы обучения
  • Тестовые серверы
  • Опытные серверы
  • Производственные серверы

Также имейте общий план, такой как «Все серверы будут проходить полное обновление ОС каждые 6 месяцев».


0

Зависит от задач, выполняемых на сервере. Для некоторых виртуальных серверов мы часто используем перезагрузку вместо перезапуска apachectl, и это занимает 5-10 секунд дольше. Но некоторые тяжело нагруженные машины перезагружаются несколько раз в год, и весь процесс контролируется всей командой администраторов.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.