Назад | Перейти на главную страницу

Рекомендуется ли периодически перезапускать веб-серверы?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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