Является ли наилучшей отраслевой практикой периодический перезапуск веб-серверов? [закрыто]

28

У нас есть веб-приложение (разработанное третьей стороной), которое работает на Tomcat. Мы получили очень плохую производительность от приложения. Разработчик приложения утверждает, что это лучшая в отрасли практика перезапускать веб-серверы каждую ночь, чтобы освободить все использование памяти и начать заново.

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

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

Geo
источник
41
Скажите им, что разработчикам приложений лучше всего находить и устранять утечки памяти.
Барт Сильверстрим
4
@ Барт О, хватит!
mfinni
1
+1 только для того, чтобы сделать мой день (PS: я сам разработчик)
RN.
1
Он сказал, что серверы или услуги? У нас есть приложение tomcat, которое нуждается в перезапуске службы каждую ночь. Если я этого не сделаю, в какой-то момент в будущем он рухнет. Я бы предпочел не делать этого, но обслуживание в течение дня важнее.
Ванны
1
Начните мониторинг файлов журнала и загрузите некоторые инструменты мониторинга JVM. Если в течение дня происходит сбой, вы должны увидеть исключения или что-то регистрируемое - даже если это исключения по умолчанию. Это даст вам некоторое представление об общей природе ошибки. Также следите за использованием памяти JVM. Шансы действительно хороши, у них есть утечка памяти, и вы поймете это, если посмотрите на кучу JVM сервера. Борьба с плохой разработкой с хорошими данными сисадмина. Он разрушает защиту «Ты просто не знаешь, что делаешь» и заставляет их на самом деле отвечать за то, почему все облажалось.
FloppyDisk

Ответы:

29

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

EEAA
источник
1
Это очень хороший момент. Если вы никогда не перезапускаете свои серверы, как указано ниже, вы можете не знать, что у вас есть определенные службы, которые не запускаются должным образом. Затем, в случае сбоя питания / жесткого перезапуска ваш сервер может вернуться не правильно.
2010 года
1
+1. Ежемесячно может иметь больше смысла - не только для перезапуска, но и для обычной процедуры работы, для применения исправлений и т. Д. Я когда-то был частью команды администраторов около 1500 серверов, 24/7, и каждый месяц было «3 ночи» restart "запланировано, после чего все исправления и т. д. также будут помещены на серверы Это дает некоторую стабильность при планировании и стандартную рабочую процедуру.
TomTom
12

Есть разница между «Лучшей практикой», тем, что многие люди делают по уважительным причинам, и «Обычной практикой», тем, что многие люди делают, потому что они ленивы и / или невежественны.

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

Сделав так, чтобы СОП регулярно перезапускал приложение, ваша компания скрывает серьезную ошибку. Это непростительно, ошибка должна быть обращена вниз и устранена, или она вернется, чтобы укусить вас позже.

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

Учитывая, что вы не можете быть в состоянии заменить разработчика, несколько предложений:

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

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

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

безделье
источник
2
На самом деле, часто это ошибка инфраструктуры, а не кода разработчика. У нас не было никаких проблем с приложениями J2EE, которые периодически попадают в ад сбора мусора на JBoss, но отлично работают на других серверах приложений commercail. Так что это может быть не ошибка разработчика, а скорее среда развертывания.
rmalayter
6

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

Максимус Минимус
источник
3

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

Кроме того, чтобы указать причину плохих разработчиков или плохой практики разработки, не в корне проблемы. Это может быть, но чаще всего не плохой код приложения. Эти проблемы уже встроены в большую часть системного кода. Небольшие утечки памяти, куча Java и проблемы с permgen, если у вас много маленьких приложений, как у нас. Современные серверы и программное обеспечение, которое они запускают, очень сложны. Когда вы думаете о том, что должен делать сервер, такой как tomcat - обслуживать файлы, обрабатывать веб-запросы, сетевые коммуникации, обмен данными с базой данных и т. Д., Он делает очень многое. В этом стеке чертовски много движущихся частей.

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

Клод
источник
2

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

matpie
источник
Абсолютно - я думаю, что ОП должен сказать кому-то, что ему нужно найти лучшего разработчика.
Хелвик
2
Есть причина, по которой крупные компании платят большие деньги за время безотказной работы нескольких девяток и почему компании тратят тысячи на резервные источники питания, RAID, клетки с горячей заменой и т. Д., И это, разумеется, не так, что им нужно перезагружаться только один раз в день.
Барт Сильверстрим
1

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

einstiien
источник
1

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

Я работал с Tomcat раньше, и у меня была та же проблема, в следующий раз, когда я буду работать с контейнером Java, я буду искать другой, может быть, JBoss или GlassFish.

Изменить: Если вам придется перезапускать его каждую ночь, то вам, вероятно, придется перезапускать его чаще, если / когда нагрузка возрастет. Будьте уверены, чтобы иметь твердые приложения, это лучшее решение.

Jonas
источник
4
Я не думаю, что я согласен, когда вы говорите, что сервер никогда не должен быть перезапущен. Серверы должны быть перезапущены, чтобы применить исправления безопасности. Они никогда не должны быть перезапущены для вещей, кроме запланированного обслуживания, хотя.
Зоредаче
Это правда, что некоторые серверы должны быть перезапущены, чтобы применить исправления безопасности. Но если у вас достаточно хорошая система, вам не нужно перезагружать систему. Существуют системы, которые работают год за годом. Вы должны стремиться к высокой доступности, если вы обслуживаете услугу в Интернете. Если у вас есть отказоустойчивая система, такая как кластер, вы можете отключить узлы один за другим и обновить их, когда служба еще работает.
Джонас
1
Если у вас есть только один сервер и / или часть оборудования, такого понятия, как высокая доступность, не существует. Вы делаете это неправильно, если вы предоставили только один сервер, и ваша служба настолько критична, что не может терпеть 15 минут простоя, время от времени перезапуская сервер. Если у вас есть приложение с нулевым временем простоя, то у вас будет настоящая система высокой доступности с несколькими узлами. В этом случае периодическая перезагрузка для исправлений и т. Д., Как вы указали, довольно проста.
EEAA
1
«В следующий раз ... я буду искать другой [контейнер Java, отличный от Tomcat]». Я бы не стал винить Tomcat. Я уже несколько лет запускаю на нем производственные сервисы, и каждый раз, когда у меня возникала эта проблема, это оказывалось проблемой приложения. «Убедитесь, что у вас есть надежные приложения, это лучшее решение». Как ни странно, каждый другой сервер приложений Java, который я использовал до сих пор, сталкивается с подобными проблемами, когда я запускаю на нем негерметичный код. Тем не менее, Tomcat 7 должен иметь какое-то проактивное обнаружение утечки памяти.
Киф
0

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

Джоэл Коэль
источник
Когда я начал работать в одном месте, я обнаружил, что у них были ночные перезагрузки на месте ... Это было ужасно, особенно с учетом того, что с вероятностью 1-2% сервер не смог правильно вернуться (ошибка синхронизации в драйвере жесткого диска) ). Потребовалось некоторое время, чтобы исправить «причины» для перезагрузок. Время ХОРОШО потрачено.
Брайан Кноблаух
0

Хотя я согласен с тем, что перезапуск сервера не идеален, существуют ситуации, когда он не является ни ошибкой разработчика, ни неправильным решением. У нас есть приложение с хорошим поведением, которое теряет память из-за проблем в библиотеке Python Popen. Это старое приложение, которое скоро будет удалено, но оно критично для бизнеса. Мы должны продолжать работать с минимальными усилиями для наших клиентов. Поэтому мы просто решили перезапускать сервер каждую ночь.

Ник Меллор
источник