Sądzę, że istnieje dobry powód, ale nie rozumiem, dlaczego czasami umieszczamy na przykład 5 instancji mających te same aplikacje internetowe na tym samym serwerze fizycznym.Dlaczego korzystamy z wielu wystąpień serwera aplikacji na tym samym serwerze?
Czy ma to jakiś związek z optymalizacją architektury wieloprocesorowej? Maksymalny dozwolony limit pamięci dla JVM lub czegoś innego?
Hmmm ... Po długim czasie jestem znowu widząc to pytanie :)
basenik A wiele wystąpień JVM na pojedynczej maszynie rozwiązuje wiele problemów. Po pierwsze, pozwól nam stawić temu czoła: Mimo że JDK 1.7 pojawia się w obrazie, wiele starszych aplikacji zostało opracowanych przy użyciu JDK 1.3 lub 1.4 lub 1.5. I nadal duża część JDK jest podzielona między nimi.
Teraz na pytanie:
Historycznie, istnieją trzy podstawowe kwestie, które architekci systemów zostały rozwiązane poprzez wprowadzenie wielu JVMs na jednym polu:
Garbage collection inefficiencies: Jako rozmiary sterty rosną, cykle zbierania śmieci - zwłaszcza w przypadku dużych zbiorów - skłonność do wprowadzania znacznych opóźnień w przetwarzaniu dzięki jednokrotnym GC. Wiele JVM walczy z tym, umożliwiając ogólnie mniejsze rozmiary sterty i umożliwiając pewną miarę współbieżności podczas cykli GC (np. Przy czterech węzłach, gdy przechodzi się do GC, nadal aktywnie przetwarzane są trzy inne).
Resource utilization: Starsze maszyny JVM nie były w stanie skalować wydajnie po czterech procesorach. Odpowiedź? Uruchom oddzielną maszynę JVM na każde 2 procesory w pudełku (przebieg może się różnić w zależności od aplikacji, oczywiście).
64-bit issues: Starsze maszyny JVM nie były w stanie przydzielić wielkości sterty powyżej 32-bitowego maksimum. Ponownie, wiele JVM pozwala zmaksymalizować wykorzystanie zasobów.
Availability: Ostatnim powodem, dla którego ludzie czasami uruchamiają wiele maszyn JVM w jednym pudełku, jest dostępność. Prawdą jest, że ta praktyka nie rozwiązuje problemów sprzętowych, ale rozwiązuje problem awarii pojedynczej instancji serwera aplikacji.
Zrobione z (http://www.theserverside.com/discussions/thread.tss?thread_id=20044)
mam przeważnie postrzegane WebLogic. Tu jest link do dalszego czytania
http://download.oracle.com/docs/cd/E13222_01/wls/docs92/perform/WLSTuning.html#wp1104298
nadzieję, że to pomoże.
Dzięki. W moim przykładzie był to również weblogic;) –
Podejrzewam, że masz na myśli tworzenie klastrów aplikacji.
AFAIK, JVM, które pojawiły się z naprawdę dużymi rozmiarami sterty, mają problemy z odśmiecaniem, choć jestem pewny, że dzięki playing around with the GC algorithm and parameters można zmniejszyć obrażenia do minimum. Ponadto aplikacje klastrowe nie mają pojedynczego punktu awarii. Jeśli jeden węzeł ulegnie awarii, pozostałe węzły mogą nadal obsługiwać klientów. Jest to jeden z powodów, dla których "architektura oparta na komunikatach" jest odpowiednia do skalowalności. Każde żądanie jest mapowane na komunikat, który może następnie zostać odebrany przez dowolny węzeł w klastrze.
Inną kwestią jest obsługa wielu żądań jednocześnie w przypadku, gdy aplikacja niestety używa zsynchronizowanego słowa kluczowego rozważnie. Obecnie mamy starszą aplikację, która ma dużo wspólnego stanu (niestety), a zatem obsługa jednoczesnych żądań odbywa się poprzez odradzanie około 20 procesów JVM z centralną jednostką dyspozytorską, która wykonuje wszystkie prace dyspozytorskie. ;-)
Proponuję użyć około najmniej JVM na region NUMA. Jeśli pojedyncza JVM wykorzystuje więcej niż jeden region NUMA (często pojedynczy procesor), wydajność może znacznie się obniżyć, ze względu na znaczny wzrost kosztów dostępu do głównej pamięci innego procesora.
Dodatkowo przy użyciu wielu serwerów może zezwolić na
EDYCJA: Może to być historyczne. Być może w przeszłości istniało wiele powodów, dla których w przeszłości istniały oddzielne maszyny JVM, ale ponieważ nie wiesz, czym one były, nie wiesz, czy nadal je stosują, a może być prostsze pozostawienie rzeczy takimi, jakimi są.
Dodatkowym powodem do użycia instancji mutliple jest łatwość obsługi.
Na przykład, jeśli masz wiele różnych aplikacji dla wielu klientów, to oddzielne instancje aplikacji dla każdej aplikacji mogą ułatwić życie, gdy musisz wykonać restart aplikacji podczas wydawania.
Załóżmy, że masz przeciętnego hosta konfiguracji i zainstalowane jedno wystąpienie serwera WWW/aplikacji. Teraz twoja aplikacja staje się popularniejsza, a liczba trafień rośnie 2-krotnie. Co teraz robisz ?
Dodaj jeszcze jeden serwer fizyczny o tej samej konfiguracji i zainstaluj aplikację, a następnie wyważ wagę tych dwóch hostów.
To nie jest koniec życia dla twojej aplikacji. Twoja aplikacja będzie coraz popularniejsza, a tym samym konieczność jej skalowania. Jaka będzie Twoja strategia?
Która opcja będzie daleko?
Zrobisz analizy kosztów, które obejmie czynniki jak- rzeczywisty koszt sprzętu, koszty zarządzania tymi serwerami (koszt moc, przestrzeń zajmowana w centrum danych) itp
Widocznie, że chodzi decyzja nie jest łatwa. W większości przypadków bardziej wydajne jest posiadanie bardziej wydajnej maszyny.
Kim jest to "my"? Nigdy wcześniej tego nie robiłem, to nie ma sensu. – skaffman
Słynna witryna e-commerce z 10 milionami unikalnych odwiedzających miesięcznie i 99.89% dostępności, a niektóre inne widziałem –
Więc mówisz, że istnieje 5 wystąpień dokładnie tej samej aplikacji internetowej uruchomionej na oddzielnych serwerach aplikacji (a zatem JVM)? Czy wszystkie działają na maszynach wirtualnych? –