Czy najlepszą praktyką branżową jest okresowe restartowanie serwerów sieciowych? [Zamknięte]

Mamy aplikację internetową (opracowaną przez firmę zewnętrzną), która działa na Tomcat. Z aplikacji mamy bardzo słabą wydajność. Twórca aplikacji twierdzi, że najlepszą praktyką branżową jest restartowanie serwerów sieciowych co noc, aby zwolnić całe użycie pamięci i zacząć od nowa.

Z perspektywy klienta, która łagodzi problem awarii strony w ciągu dnia, ale z perspektywy SysAdmin jest to okropne rozwiązanie.

Obsługujemy 20 takich aplikacji na różnych serwerach dla różnych klientów, a koordynacja zapewniania, że ​​wszystkie są restartowane każdej nocy, wydaje się po prostu błędna.

Z pewnością nie jest to najlepsza praktyka. Chociaż dobrze jest okresowo restartować serwery, aby upewnić się, że wszystko działa poprawnie, konieczność ponownego uruchomienia w nocy wskazuje na bardzo poważny przeciek pamięci w aplikacji.

Istnieje różnica między „najlepszymi praktykami”, rzeczami, które wiele osób robi z dobrych powodów, a „powszechnymi praktykami”, rzeczami, które wiele osób robi, ponieważ są leniwe i / lub ignoranckie.

Aplikacje i (gorsze) serwery, które muszą być rutynowo restartowane lub ponownie uruchamiane, aby nadal działały poprawnie, są dość powszechne. Ale jest to również wyraźny sygnał, że masz krytyczny błąd.

Dzięki regularnemu ponownemu uruchamianiu aplikacji przez SPO firma ukrywa poważny błąd pod dywan. Jest to niewybaczalne, błąd musi być zakryty i zgnieciony, albo wróci, by cię ugryźć później.

W idealnym przypadku Twoja firma powinna znaleźć lepszego programistę. Niestety może to spowodować sporo pracy przy przepisywaniu dużych fragmentów kodu. Fakt, że deweloper albo uważa, że ​​źle napisany kod jest akceptowalny, albo nie wie wystarczająco, aby rozpoznać objawy błędnego kodu, sugeruje niską jakość kodu. Dobry deweloper będzie konstytucyjnie niezdolny do pozostawienia go w tym stanie.

Biorąc pod uwagę, że możesz nie być w stanie zastąpić programisty, kilka sugestii:

• Sprawdź, czy możesz poprosić lepszego programistę o sprawdzenie kodu i zgłoszenie jego oceny komuś, kto może coś z tym zrobić,
• Zobacz narzędzia do profilowania. Jeśli masz umiejętności i / lub skłonność, spróbuj samodzielnie profilować kod, aby znaleźć wyciek i zgłosić go.

Nawet bez wchodzenia w narzędzia profilujące zorientowane na programistę, istnieje wiele narzędzi zorientowanych na sysadmin do profilowania i monitorowania wykorzystania pamięci w aplikacjach Java. W każdym razie powinieneś naprawdę skonfigurować monitorowanie pamięci (szczególnie sterty) na serwerach produkcyjnych. Polecam to, nawet jeśli korzystasz z kodu jakości. Może to dać ostrzeżenie z wyprzedzeniem, gdy Twoje błędne aplikacje wkrótce się przewrócą.

Ale jeszcze lepiej, powinny one pomóc w zebraniu dowodu na wyciek, a nawet mogą wskazywać, gdzie jest problem w aplikacji. To da ci lepszą amunicję do lobbowania za jej naprawieniem.

Deweloper aplikacji prawdopodobnie twierdzi, że w jego najlepszym interesie jest objęcie jego tyłka przez obejście nieprofesjonalnej pracy, którą wykonał. Być może przestał przyznawać, że napisał coś z ogromnym wyciekiem pamięci, ale niezbyt daleko.

Wydaje się, że wiele odpowiedzi tutaj nie pasuje do praktycznych rozwiązań. Wydaje się, że unikają dogmatów - serwerów nigdy nie należy restartować - dlaczego mamy 5 dziewiątek? tolerancja na awarie? Cóż, więc kiedy mają wstać, nie ruszają się.

Ponadto stwierdzenie, że jest to przyczyną złych programistów lub złych praktyk programistycznych, nie prowadzi do sedna problemu. Może to być, ale najczęściej niezły kod aplikacji. Te problemy są już wbudowane w znaczną część kodu systemowego. Małe wycieki pamięci, sterty Java i problemy z permgenem, jeśli korzystasz z wielu małych aplikacji. Nowoczesne serwery i uruchamiane przez nich oprogramowanie są bardzo złożone. Kiedy myślisz o tym, co musi zrobić serwer taki jak tomcat - obsługuje pliki, przetwarza żądania sieciowe, komunikację sieciową, komunikację z bazą danych itp. - robi to dużo. Na tym stosie jest mnóstwo ruchomych części.

Proaktywne ponowne uruchamianie serwerów pozwala powiedzieć, że raz w tygodniu lub miesiącu jest moim zdaniem inteligentny i wydajny. Jeśli masz klaster i obracasz serwery, nie powinieneś wpływać na klientów ani trochę. Klienci będą znacznie bardziej zadowoleni z wydajności twoich serwerów.

Serwery IMO powinny być zamykane jak najmniej. Bardziej prawdopodobne jest, że twórca aplikacji zbudował tandetną aplikację z wyciekiem pamięci.

Co wieczór mam skrypt uruchamiający jeden z naszych serwerów WWW, ale to więcej z powodu źle napisanej aplikacji Java niż standardu branżowego. Powiedziałbym jednak, że ponowne uruchomienie usług sieciowych nie jest rzadkością. Może to zrobić czyszczenie pamięci, którego szukasz, i mniej obciążać serwer w porównaniu do pełnego ponownego uruchomienia.

Serwer najlepiej nigdy nie uruchamiać ponownie. To jeden z powodów, dla których mamy tolerancję na awarie . Jeśli musisz zrestartować serwer z powodu aplikacji, oznacza to, że aplikacje wyciekają z pamięci i są źle zbudowane.

Pracowałem wcześniej z Tomcat i miałem ten sam problem, następnym razem, gdy będę pracować z kontenerem Java, szukam innego, może JBoss lub GlassFish.

Edycja: Jeśli musisz teraz uruchamiać go co noc, prawdopodobnie będziesz musiał go uruchamiać częściej, jeśli / kiedy obciążenie wzrośnie. Pamiętaj, aby mieć solidne aplikacje, to najlepsze rozwiązanie.

Najczęstsze, jakie kiedykolwiek widziałem, to cotygodniowe. Gdzie jestem teraz, jesteśmy sklepem z oknami i robimy to co miesiąc w weekend po wtorkowym patchu.

Chociaż zgadzam się, że ciągłe ponowne uruchamianie serwera nie jest idealne, ale są sytuacje, w których nie jest to wina programisty ani niewłaściwa czynność. Mamy dobrze działającą aplikację, która przecieka pamięć z powodu problemów w bibliotece Python Popen. To stara aplikacja, która wkrótce zostanie wycofana, ale ma kluczowe znaczenie dla biznesu. Musimy utrzymywać go przy minimalnym wysiłku dla naszych klientów. Właśnie postanowiliśmy zrestartować serwer co noc.