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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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