Sun sprzedany!!!
Michał Margiel
Sun Microsystems sprzedany panu z Oracle.
Tyle było plotek o IBM, a tu niespodzianka. Ludzie przepowiadają
koniec MySQLa,.
I co o tym myślicie? Co będzie z ,...z nami?:)
--
Michał Margiel
Zygmunt M. Zarzecki
> 7,4 miliarda po raz pierwszy... po raz drugi... i... po raz trzeci.
> Sun Microsystems sprzedany panu z Oracle.
>
> Tyle było plotek o IBM, a tu niespodzianka. Ludzie przepowiadają
> koniec MySQLa,.
Właśnie, plotek.
Mnie to wcale nie dziwi, za dużo oracle'a widziałem w SUNie.
zyga
Waldemar Kłaczyński
> 7,4 miliarda po raz pierwszy... po raz drugi... i... po raz trzeci.
> Sun Microsystems sprzedany panu z Oracle.
>
> Tyle było plotek o IBM, a tu niespodzianka. Ludzie przepowiadają
> koniec MySQLa,.
SQLMy :), a może NaszSQL, fajnie by brzmiało :)
>
> I co o tym myślicie? Co będzie z ,...z nami?:)
>
> --
> Michał Margiel
JAVA Także ma otwarty kod :)
A.L.
<Michal....@gmail.com> wrote:
>7,4 miliarda po raz pierwszy... po raz drugi... i... po raz trzeci.
>Sun Microsystems sprzedany panu z Oracle.
Jeszcze nie. Tranzakcja musi byc zatwierdzona przez komisje
amtymonopolistyczna. Owa komisja byla glownym powodem zneichecenia
IBMu
A.L.
Mateusz Ludwin
> Tyle było plotek o IBM, a tu niespodzianka. Ludzie przepowiadają
> koniec MySQLa,.
Super, nareszcie koniec tego crapu.
> I co o tym myślicie? Co będzie z ,...z nami?:)
Wreszcie cała rodzina (DBMS, WL, J) w komplecie :> Jestem za.
--
Omniscient, omnipotent, omnipresent, without judgment
Mateusz Ludwin mateuszl [at] gmail [dot] com
Piotr Pietrzak
wrote:
> Michał Margiel pisze:> 7,4 miliarda po raz pierwszy... po raz drugi... i... po raz trzeci.
> > Sun Microsystems sprzedany panu z Oracle.
razem z SUN z wyjątkiem sprzętu. Podsumujmy:
Najważniejszy JVM:
Oracle miał własny JVM na długo przed zakupem BEA - jest dystrybuowany
z bazą od dawna i jest to inny JVM, niż SUN i BEA.
Teraz ma trzy i chyba wszystkie trzy będzie dalej rozwijał, aby nie
stracić klientów... Enterprise to nie PHP, że sobie można w trakcie
zawodów zmieniać zasady - jak się w coś władują to ciągną to latami -
np Oracle Forms.
Mniej ważny, ale chyba bardziej kontrowersyjny MySQL:
Tuż po zakupie przez SUN większość developerów i tak odeszła z MySQL,
ale mniejsza o to - Oracle już kupiło kiedyś bazę open source -
BerkeleyDB (chyba najczęściej używaną bazę świata). Nic złego się nie
stało... Też było wiele zamieszania - że kupili tylko po to by
zamknąć, by MySQLa pozbawić silnika transakcyjnego (bazującego na
BDB). Nic takiego sie nie stało.
MySQL nie jest też tak do końca wolny i już od dłuższego czasu taki
nie był, więc nie będzie(ma) czego żałować, bo to jedynie sentymenty;
prawdziwy wolny silnik bazodanowy to PostgreSQL i moim zdaniem to
właśnie on zarobi na tym najwięcej (choć przyznam, że dziś na SUNie
można było zarobić 36% - imponujący wynik).
PostgreSQL zarobi na tym tyle, że dziś stojąc przed wyborem silnika
bazodanowego OS - nie mam już żadnych wątpliwości, nawet jeśli nie
będę musiał mieć transakcyjności, procedur składowanych ...
Wirtualizacje, system operacyjny - wszystko to Oracle już tak czy
inaczej dostarcza.
Najważniejsze IDE + Serwer aplikacyjny:
Oracle miał już Oracle jdeveloper, który rozgałęził się na jdeveloper
i SQLdeveloper, potem kupili BEA z Eclipsem na sterydach i teraz
dokupili jeszcze NetBeans.
Mieli swój serwer aplikacyjny kupili WL, teraz dołączył do tego GF...
Wszystkiego mają zatem po trzy różne sztuki:) Będzie trzeba nazywać
jak w M$ - "desperate edition", "professional", "ultimate edition".
Ciekawe czy to nie zdezorientuje klientów - mamy tu trzy takie -
wszystkie dobre, ale jeden to ma tu na niebiesko a tamten jest szybszy
jak się tu na zielonym kliknie... Już widzę naradę u mnie, jak każdy
ma inne zdanie na ten temat:)
Ciekawy będzie też temat portali - w sumie też są trzy sztuki... Do
tego dochodzi jeszcze to, że tego Liferaya co się inaczej nazywa to
można postawić na prawie każdym serwerze aplikacyjnym, czy kontenerze
serwetów. Nazw edycji zabraknie...
>
> > Tyle było plotek o IBM, a tu niespodzianka. Ludzie przepowiadają
> > koniec MySQLa,.
Jakieś przesądy z tym końcem MySQL - liczba znaków w komunikacie
prasowym o zakupie SUNa to :666 idzie koniec świata.
Żartowałem - na bloombergu komunikat tylko taki:
Oracle kupuje Suna po tym jak biznes z IBM "collapse". Czyli to nie
były plotki, tylko negocjacje.
>
> MySQL ma otwarty kod, nie SUN to kto inny, podobnie DIVX i XVID, może
> SQLMy :), a może NaszSQL, fajnie by brzmiało :)
No i to właśnie zabija bazy open source - kiedyś spory potencjał miała
baza firebird, ale powstało kilka forków (np taki fyracle, który ponoć
działa jak oracle, ale cena ponoć lepsza) i żaden nie odniósł jakiegoś
spektakularnego sukcesu. Im więcej forków, tym gorzej dla projektu...
>
>
>
> > I co o tym myślicie? Co będzie z ,...z nami?:)
Co z nami?
Myślę, że obudzimy się we wtorek i pójdziemy do pracy jak w
poniedziałek i środę:)
>
> > --
> > Michał Margiel
>
> JAVA Także ma otwarty kod :)
Chmmm, czy to cokolwiek zmienia? Kto miałby dbać o rozwój w tym samym
kierunku, aby się wszystko nie rozleciało? Przecież nie ma kierownika
internetu, który wszystkie forki okiełzna i powie, że tylko jeden jest
najlepszy i trzeba go właśnie rozwijać. To było najlepsze w układzie z
SUNem - była sobie firma, która była niezależna od Oracle i od IBM,
która nie pozwalała żadnemu za daleko ciągnąć w swoją stronę. Teraz
sytuacja się nieco zmieniła, mam nadzieję, że nie zmniejszy to
zainteresowania IBMa samą javą (choć np panel sterujący do nowej lini
bladeów IBM jest napisany w PHP [co znacznie zmienia wizerunek całego
produktu]).
I tu jakoś tak doszedłem do Hardware-u. Do dziś Oracle sam nie
produkował sprzętu - mieli dil z HP, że maszyny HP pozwalają
przyspieszyć działanie hurtowni danych i miało to w nazwie Oracle.
Teraz SUN ze swoimi maszynami na AMD - ponoć lepszymi w zastosowaniach
aplikacyjnych z systemem operacyjnym Solaris /Oracle Linux /Bazą
danych /Serwerem aplikacyjnym /Middleware też od BEA, czy SUNa; do
tego konsultanci i w sumie to już nikt nic nie wciśnie... Kto będzie
kupował sprzęt/usługi od innych, jak ten od SUNa - przepraszam Oracle
- będzie działał z bazą lepiej - miał tańsze wsparcie i inne takie...
Jak to mawia ObiŁanKenobi - "Wyczuwam mocne zawirowanie mocy".
Tak, czy inaczej dalej piszę plugin NetBeans do JAXR... Nic mnie nie
zatrzyma - baterii starczy jeszcze na 5 godzin. Polscy kibice mawiają
w takich sytuacjach: "nic się nie stało"...
Zygmunt M. Zarzecki
>> Tyle było plotek o IBM, a tu niespodzianka. Ludzie przepowiadają
>> koniec MySQLa,.
>
> Super, nareszcie koniec tego crapu.
>
>> I co o tym myślicie? Co będzie z ,...z nami?:)
>
> Wreszcie cała rodzina (DBMS, WL, J) w komplecie :> Jestem za.
A ja jestem ciekaw, w którą stronę java sunowska pójdzie, bo w
niektórych testach jrockit miażdży.
zyga
Piotr Pietrzak
> Rzecze Michał Margiel:
>
> > Tyle było plotek o IBM, a tu niespodzianka. Ludzie przepowiadają
> > koniec MySQLa,.
>
> Super, nareszcie koniec tego crapu.
>
> > I co o tym myślicie? Co będzie z ,...z nami?:)
>
> Wreszcie cała rodzina (DBMS, WL, J) w komplecie :> Jestem za.
rodzina była w komplecie już od dawna:) Teraz można powiedzieć przybył
Ojciec Chrzestny i pobłogosławi całe przedsięwzięcie.
> --
> Omniscient, omnipotent, omnipresent, without judgment
mnie po oczach bije - co dokładnie Kolega chce przekazać potomności
zamieszczając ją po raz 1000czny? Nie to, że się czepiam, ale po
prostu językowo nie ogarniam, a co do grup zajrzę, to się zawsze
napatoczy.
>
> Mateusz Ludwin mateuszl [at] gmail [dot] com
Piotr Pietrzak
Ta sygnaturka została dodana ze zwykłej złośliwości, bo mi Pani w
kolejce wymusiła pierwszeństwo a w metrze stał za mną gość co słuchał
polskiego rapu i nie mogłm się skupić na książce, więc wszystko mi się
pomieszało i teraz już nie wiem, czy ten Spring to jara to zioło, czy
nie...
piotr [at] jestem [dot] dzis [dot] zlosliwy [dot] macintosh [dot] com
[delete] pl
P.S.
Proszę potraktować to jako żart, to nie jest personalny atak.
Piotr Pietrzak
wirtualnej VMWare, więc nie trzeba Operating Systemu instalować. Jeśli
cloud computing się przyjmie, to może lepiej, że nie ma tam tego OSu,
to łatwiej się instaluje i nie trzeba co chwile aktualizować
poszczególnych komponentów. W przypadku kilku maszyn to jest to do
ogarnięcia, ale jak ktoś ma ich setki, to chyba jeden admin na etacie
tylko paczuje dzień w dzień te OSy, które i tak w sumie nie robią nic
ważnego...
Z JRockitem jest problem tylko jeden, że fajne narzędzia - taki
powiedzmy dtrace/instruments to jest na Solarisie i na OSX a na tych
platformach nie ma z kolei JRockita (jest na solarisa - SPARKa,ale kto
sobie do domu do debugowania kupuje SPARKa).
Z drugiej jednak strony, to zazwyczaj klient decyduje na jakim JVM ma
działać i jak powie Java 1.4, to żadne inwestycje największych
korporacji już nic nie zmienią. Podobnie jak można sobie do
developerki używać OSX do momentu, gdy nie trzeba mieć zgodności z IE
(tak - wiem, odpaliłem IE na OSX, ale niestety wygląda inaczej niż na
XP).
Moim zdaniem Java Sunowska będzie dalej mainstream, a taki JRockit
będzie do zastosowań serwerowych z naciskiem na enterprajz - czyli
VMWare, może Virtual Box zamiast VMWare, ale bardziej na serwer, niż
pod strzechy (integracje z JavaFX, OpenGL na wszystkich platformach
itd.).
Mateusz Ludwin
>> Omniscient, omnipotent, omnipresent, without judgment
> Miałem już wcześniej zapytać, bo ta sygnaturka już od dłuższego czasu
> mnie po oczach bije - co dokładnie Kolega chce przekazać potomności
> zamieszczając ją po raz 1000czny? Nie to, że się czepiam, ale po
> prostu językowo nie ogarniam, a co do grup zajrzę, to się zawsze
> napatoczy.
Ależ proszę, oto i źródło:
http://bobo.ds5.agh.edu.pl/~mathu/06%20-%20Tool%20-%20Merkaba%20(Live).mp3
Owa sygnaturka przekazuje że nie ma przede mną ucieczki w usenecie.
Nadziei też nie ma.
--
Omniscient, omnipotent, omnipresent, without judgment
Mateusz Ludwin mateuszl [at] gmail [dot] com
Wojciech Jaczewski
> Nie tylko tak miażdży - Jrockit można puścić na gołej maszynie
> wirtualnej VMWare, więc nie trzeba Operating Systemu instalować. Jeśli
> cloud computing się przyjmie, to może lepiej, że nie ma tam tego OSu,
> to łatwiej się instaluje i nie trzeba co chwile aktualizować
> poszczególnych komponentów. W przypadku kilku maszyn to jest to do
> ogarnięcia, ale jak ktoś ma ich setki, to chyba jeden admin na etacie
> tylko paczuje dzień w dzień te OSy, które i tak w sumie nie robią nic
> ważnego...
Jeśli komponenty są nieużywane, to i aktualizować ich nie trzeba, bo nie ma
jak wykorzystać luki w programie, który nie działa, a jedynie leży sobie na
dysku. Można też zainstalować samego kernela + małe initrd, to wtedy
nieużywane komponenty nawet na dysku leżeć nie będą.
System operacyjny jest potrzebny do obsługi sprzętu. Owszem można wziąć
poszczególne elementy systemu operacyjnego i w ramach wypisywania
marketingowego bełkotu nazwać je jakoś inaczej, po czym udawać, że system
nie jest potrzebny... ale ta zmiana nazwy żadnej rzeczywistej korzyści
użytkownikowi nie przyniesie.
Piotr Pietrzak
> Piotr Pietrzak wrote:
> > Nie tylko tak miażdży - Jrockit można puścić na gołej maszynie
> > wirtualnej VMWare, więc nie trzeba Operating Systemu instalować. Jeśli
> > cloud computing się przyjmie, to może lepiej, że nie ma tam tego OSu,
> > to łatwiej się instaluje i nie trzeba co chwile aktualizować
> > poszczególnych komponentów. W przypadku kilku maszyn to jest to do
> > ogarnięcia, ale jak ktoś ma ich setki, to chyba jeden admin na etacie
> > tylko paczuje dzień w dzień te OSy, które i tak w sumie nie robią nic
> > ważnego...
>
> Jeśli komponenty są nieużywane, to i aktualizować ich nie trzeba, bo nie ma
> jak wykorzystać luki w programie, który nie działa, a jedynie leży sobie na
> dysku. Można też zainstalować samego kernela + małe initrd, to wtedy
> nieużywane komponenty nawet na dysku leżeć nie będą.
trzeba restartować. Sshd się przyda - a jak pamiętamy z filmu Matrix
nawet sshd przytrafiały się wpadki. Trzeba pamiętać co się ma i
monitorować aktualność wersji. Jak przeglądam procesy, to nie za
wszystkie bym sobie dał rękę obciąć - np taki DNS...
> System operacyjny jest potrzebny do obsługi sprzętu.
"IDENTYCZNE" podobnie działały jak im się coś tam do pamięci wrzucało.
Czy to nie prościej jak nie trzeba się przejmować różnorodnością
sprzętu. Robię raz - pakuje dla klienta i klient sobie odpala, nie
musi niczego konfigurować. Zawsze mu zadziała i to dokładnie tak jak
ja chciałem.
> Owszem można wziąć
> poszczególne elementy systemu operacyjnego i w ramach wypisywania
> marketingowego bełkotu nazwać je jakoś inaczej, po czym udawać, że system
> nie jest potrzebny... ale ta zmiana nazwy żadnej rzeczywistej korzyści
> użytkownikowi nie przyniesie.
lepiej. Marketingowo też fajne - dostaję wszystko w jednej paczce, od
jednego producenta, najlepiej aby hardware tez był od niego. Jak
przestaje działać dzwonię pod jeden numer i nikt się nie wykręca, że
coś źle skonfigurowałem, albo jakieś bajki o wirusach opowiada...
Mateusz Ludwin
> Nie tylko tak miażdży - Jrockit można puścić na gołej maszynie
> wirtualnej VMWare, więc nie trzeba Operating Systemu instalować. Jeśli
> cloud computing się przyjmie, to może lepiej, że nie ma tam tego OSu,
> to łatwiej się instaluje i nie trzeba co chwile aktualizować
> poszczególnych komponentów. W przypadku kilku maszyn to jest to do
> ogarnięcia, ale jak ktoś ma ich setki, to chyba jeden admin na etacie
> tylko paczuje dzień w dzień te OSy, które i tak w sumie nie robią nic
> ważnego...
Fajnie, ale ja do pracy z takim WL potrzebuję np.
- normalnego filesystemu
- SSH
- kompletu narzędzi konsolowych w rodzaju basha, taila itd.
- możliwości odpalenia na jednej maszynie np. 10 serwerów w osobnych JVM -
bo serwer ma na przykład 32 procesory
Gołą JVM może odpalę serwer aplikacyjny, ale co poza tym? Pracować się z
takim serwerem nie da. A jak to wszystko dołożyć do JVM, to wyjdzie z tego
normalny OS. Już lepiej niech zrobią specjalną wersję Solarisa
zoptymalizowaną pod uruchamianie serwerów aplikacyjnych i z kompletem
narzędzi WWW do zarządzania domenami.
Piotr Pietrzak
> Rzecze Piotr Pietrzak:
>
> >> Omniscient, omnipotent, omnipresent, without judgment
> > Miałem już wcześniej zapytać, bo ta sygnaturka już od dłuższego czasu
> > mnie po oczach bije - co dokładnie Kolega chce przekazać potomności
> > zamieszczając ją po raz 1000czny? Nie to, że się czepiam, ale po
> > prostu językowo nie ogarniam, a co do grup zajrzę, to się zawsze
> > napatoczy.
>
> Ależ proszę, oto i źródło:
>
>
Na szybkim fast forwardzie nie udało mi się trafić w tekst, ale ok -
jutro posłucham w słuchawkach...
> Owa sygnaturka przekazuje że nie ma przede mną ucieczki w usenecie.
Fakt - killfile nie wywala cytowanych wypowiedzi delikwenta.
> Nadziei też nie ma.
Są fachowcy co parsują pudelka i robią z tego pluginy do eclipse, to
może i Twoje wypowiedzi się da przeparsować i dodać trochę "optymizmu
z potwierdzeniem" "Więc dlatego z punktu mając na uwadze, że
ewentualna krytyka może być, tak musimy zrobić żeby tej krytyki nie
było. Tylko aplauz i zaakceptowanie."
Sygnaturkę usuwam, nie ze złośliwości, ale wyczytałem, że zgodnie z
netykietą nie powinno się jej cytować.
Waldek Kot
> jak wykorzystać luki w programie, który nie działa, a jedynie leży sobie na
> dysku. Można też zainstalować samego kernela + małe initrd, to wtedy
> nieużywane komponenty nawet na dysku leżeć nie będą.
> System operacyjny jest potrzebny do obsługi sprzętu. Owszem można wziąć
> poszczególne elementy systemu operacyjnego i w ramach wypisywania
> marketingowego bełkotu nazwać je jakoś inaczej, po czym udawać, że system
> nie jest potrzebny... ale ta zmiana nazwy żadnej rzeczywistej korzyści
> użytkownikowi nie przyniesie.
Mocnych słów używasz... Wolałbym dyskutować o technologii
wirtualizacji Javy, ale na czym miałby ten "marketingowy bełkot" Twoim
zdaniem polegać ? Wiesz co jest w środku albo chociaż widziałeś
JRockit Virtual Edition albo WebLogic Virtual Edition w działaniu
zanim sformułowałeś taką opinię ?
Pozdrawiam,
Waldek Kot
Leszek Gawron
> Mniej ważny, ale chyba bardziej kontrowersyjny MySQL:
> Tuż po zakupie przez SUN większość developerów i tak odeszła z MySQL,
> ale mniejsza o to - Oracle już kupiło kiedyś bazę open source -
> BerkeleyDB (chyba najczęściej używaną bazę świata). Nic złego się nie
> stało... Też było wiele zamieszania - że kupili tylko po to by
> zamknąć, by MySQLa pozbawić silnika transakcyjnego (bazującego na
> BDB). Nic takiego sie nie stało.
male delikatne "ale": czy probowales dowiedziec sie ile kosztuje
licencja na komercyjne wykorzystanie BDB? Ja tak: ok $20k.
Jesli tak ma wygladac dalsza otwartosc MySQLa, to ja dziekuje.
--
Leszek Gawron
Waldek Kot
> Fajnie, ale ja do pracy z takim WL potrzebuję np.
>
> - normalnego filesystemu
> - SSH
> - kompletu narzędzi konsolowych w rodzaju basha, taila itd.
> - możliwości odpalenia na jednej maszynie np. 10 serwerów w osobnych JVM -
> bo serwer ma na przykład 32 procesory
>
> Gołą JVM może odpalę serwer aplikacyjny, ale co poza tym? Pracować się z
> takim serwerem nie da. A jak to wszystko dołożyć do JVM, to wyjdzie z tego
> normalny OS. Już lepiej niech zrobią specjalną wersję Solarisa
> zoptymalizowaną pod uruchamianie serwerów aplikacyjnych i z kompletem
> narzędzi WWW do zarządzania domenami.
Mateusz - wszystko to co opisałeś jest w JRockit Virtual Edition (i
innych "wirtualnych edycjach", np. WLS-VE):
- filesystem jest
- SSH jest
- prosty shell jest (w każdym razie tail jest :-)
- na fizycznej maszynie możesz odpalić tyle VM z WLS-VE ile masz
zasobów (CPU, RAM, IO, ...)
Do tego jest klient syslog.
Z takim serwerem jak najbardziej da się pracować :-). Narzędzi do
zarządzania dostarcza software wirtualizacyjny, JVM, serwer
aplikacyjny, itd...
Technicznie to nie jest tak, że do JVM cokolwiek specjalnego dołożono
- JVM (i wszystko co w niej działa, szczególnie serwer aplikacyjny) są
z półki (= niemodyfikowane), takie same jak odpalasz na normalnym OS.
VE to cienka (~2MB) warstewka _pod_ JVM, która daje JVM wszystko czego
JVM potrzebuje od OS (od razu też wspomnę, że ta warstwa NIE jest
oparta o Linux-a - jest napisana "od zera"). JVM w zasadzie nie ma
świadomości tego, że pod spodem nie ma normalnego OS...
W ramach JVM w zasadzie dołożono tylko wewnętrzny wątek obsługujący
komunikację pomiędzy JVM-ami - (na razie) po to, aby JVMy mogły
przekazywać sobie pamięć (dynamicznie zmieniać rozmiar stosu, przez co
minimalizowany jest swapping pamięci na dyski). Używając pojęć znanych
z wirtualizacji możnaby powiedzieć, że mamy tu parawirtualizację JVM.
Podobnych optymalizacji będzie w przyszłości dużo więcej...
Do tego, na czas sesji SSH w JVM uruchamiany jest dodatkowy wątek
SSH.
Jak widać, pomysł polega nie tyle na zbudowaniu minimalnego OS (tak
jak w JeOS - Just enough OS), co na zbudowaniu "a'la OS" specjalnie
dla serwerowych JVM... To jest "a'la OS", bo wielu typowych dla OS
funkcjonalności nie ma (bo nie są potrzebne i/lub przeszkadzają JVM).
Jeśli możesz to wpadnij na GeeCon 7.maja do Krakowa - będę o mówił o
wirtualizacji, szczególnie w kontekście odpalania serwerowych
aplikacji Java bez systemu operacyjnego - w kuluarach też chętnie o
tym pogadam...
Pozdrawiam,
Waldek Kot
Mateusz Ludwin
> Jeśli możesz to wpadnij na GeeCon 7.maja do Krakowa - będę o mówił o
> wirtualizacji, szczególnie w kontekście odpalania serwerowych
> aplikacji Java bez systemu operacyjnego - w kuluarach też chętnie o
> tym pogadam...
Będę :>
--
Zygmunt M. Zarzecki
> Nie tylko tak miażdży - Jrockit można puścić na gołej maszynie
> wirtualnej VMWare, więc nie trzeba Operating Systemu instalować. Jeśli
Możesz rozwinąć?
zyga
Wojciech Jaczewski
>> Jeśli komponenty są nieużywane, to i aktualizować ich nie trzeba, bo nie
>> ma jak wykorzystać luki w programie, który nie działa, a jedynie leży
>> sobie na dysku. Można też zainstalować samego kernela + małe initrd, to
>> wtedy nieużywane komponenty nawet na dysku leżeć nie będą.
>> System operacyjny jest potrzebny do obsługi sprzętu. Owszem można wziąć
>> poszczególne elementy systemu operacyjnego i w ramach wypisywania
>> marketingowego bełkotu nazwać je jakoś inaczej, po czym udawać, że system
>> nie jest potrzebny... ale ta zmiana nazwy żadnej rzeczywistej korzyści
>> użytkownikowi nie przyniesie.
>
> Mocnych słów używasz... Wolałbym dyskutować o technologii
> wirtualizacji Javy, ale na czym miałby ten "marketingowy bełkot" Twoim
> zdaniem polegać ?
Na tym, że wmawia się użytkownikom, że jeśli zamiast systemu operacyjnego
użyjemy czegoś niewiele różniącego się od niego, a mającego inną nazwę, to
coś istotnego zyskamy.
Narzut samego kernela systemu operacyjnego (na przykładzie Linuksa, bo
akurat jego używam na codzień, do różnych zastosowań) jeśli chodzi o
wydajność, czy zajętość pamięci jest znikomy. Natomiast wygoda używania
systemu w miarę znanego, przetestowanego, jest dużo większa, niż sztucznego
tworu zrobionego przez korporację specjalnie po to, aby uzależnić
użytkowników od konkretnego produktu. I ten twór i tak musi spełnić te
zadania, które spełniał kernel standardowego systemu, więc musi wprowadzić
swój narzut; mały - mniej więcej taki sam, jak zwykły kernel.
> Wiesz co jest w środku albo chociaż widziałeś
> JRockit Virtual Edition albo WebLogic Virtual Edition w działaniu
> zanim sformułowałeś taką opinię ?
Nie widziałem.
Przeglądam tę grupę z ciekawości i wypowiadam się na tematy raczej mniej
bezpośrednio związane z Javą i produktami z którymi współpracuje.
Wypowiadam się na te tematy, którymi się interesuję i które staram się
sprawdzać w praktyce. M.in. na temat narzutów systemu operacyjnego.
Po prostu nie widzę żadnej korzyści z tworzenia rozwiązania całkowicie
innego, całkowicie inaczej administrowanego, a realizującego zadania, które
są spokojnie do zrealizowania przy pomocy istniejących systemów
operacyjnych.
Może się mylę odnośnie tego, że całkowicie inaczej się nimi administruje...
Jeśli jest to po prostu kolejna alternatywa w świecie UNIX-ów, to wtedy OK.
Ale wątpię aby to było UNIX-o-podobne, bo nikt by się tu nie zachwycał tym,
że niby pozbyto się systemu operacyjnego.
Piotr Pietrzak
Virtual Edition. Ja widziałem to po raz pierwszy właśnie na
prezentacji Waldiego na WJUGu, ale można również to pewnie zobaczyć na
prezentacjach Oracle. Sprawa wygląda fajnie - uruchamia się VMWare a
potem wstaje WebLogic.
>
> zyga
Piotr Pietrzak
> Waldek Kot wrote:
> >> Jeśli komponenty są nieużywane, to i aktualizować ich nie trzeba, bo nie
> >> ma jak wykorzystać luki w programie, który nie działa, a jedynie leży
> >> sobie na dysku. Można też zainstalować samego kernela + małe initrd, to
> >> wtedy nieużywane komponenty nawet na dysku leżeć nie będą.
> >> System operacyjny jest potrzebny do obsługi sprzętu. Owszem można wziąć
> >> poszczególne elementy systemu operacyjnego i w ramach wypisywania
> >> marketingowego bełkotu nazwać je jakoś inaczej, po czym udawać, że system
> >> nie jest potrzebny... ale ta zmiana nazwy żadnej rzeczywistej korzyści
> >> użytkownikowi nie przyniesie.
>
> > Mocnych słów używasz... Wolałbym dyskutować o technologii
> > wirtualizacji Javy, ale na czym miałby ten "marketingowy bełkot" Twoim
> > zdaniem polegać ?
>
> Na tym, że wmawia się użytkownikom, że jeśli zamiast systemu operacyjnego
> użyjemy czegoś niewiele różniącego się od niego, a mającego inną nazwę, to
> coś istotnego zyskamy.
operacyjnym, który portafi uruchamiać aplikacje, które zostały
skompilowane w javie. Jest to system specyficzny, którego twórcy nie
chcą nazywać systemem operacyjnym, bo jego specyfika czyni go bardziej
JVM niż systemem operacyjnym pod względem ilości kodu poświęconego na
daną funkcjonalność.
> Narzut samego kernela systemu operacyjnego (na przykładzie Linuksa, bo
> akurat jego używam na codzień, do różnych zastosowań) jeśli chodzi o
> wydajność, czy zajętość pamięci jest znikomy. Natomiast wygoda używania
> systemu w miarę znanego, przetestowanego, jest dużo większa, niż sztucznego
> tworu zrobionego przez korporację specjalnie po to, aby uzależnić
> użytkowników od konkretnego produktu. I ten twór i tak musi spełnić te
> zadania, które spełniał kernel standardowego systemu, więc musi wprowadzić
> swój narzut; mały - mniej więcej taki sam, jak zwykły kernel.
przewaga nad "znanymi" SO.
Nie zgodzę się ze stwierdzeniem, że narzut jest porównywalny -
systemem standardowym trzeba zarządzać - trzeba aktualizować, trzeba
dbać o spójność komponentów, trzeba monitorować biuletyny
bezpieczeństwa - to jest jeszcze droższe od narzutu na maszynie, bo
kosztuje znacznie więcej i co miesiąc...
Wygoda jest większa - fakt - ale włamywacz też ma wygodniej.
Zjawisko vendor lock in jest znane i chyba każdy, kto się
profesjonalnie(i świadomie) zajmuje IT co najmniej słyszał o tym i wie
jak sobie z tym radzić. Nie sądzę, by jednak w takim przypadku miało
to zastosowanie - po pierwsze platforma ta potrafi działać z normalnym
bytecodem javy (a nie jak Android vendor lockin). Z tego co widziałem,
to odpala się po prostu taką maszynę na VMWare, uruchamia się JRockit,
JRockit odpala WebLogic, robisz deployment war/ear/łotewer i wszystko
działa. Pominę w tym momencie związanie się z WL, bo to zupełnie inna
sprawa - poza zakresem tej dyskusji.
>
> > Wiesz co jest w środku albo chociaż widziałeś
> > JRockit Virtual Edition albo WebLogic Virtual Edition w działaniu
> > zanim sformułowałeś taką opinię ?
>
> Nie widziałem.
> Przeglądam tę grupę z ciekawości i wypowiadam się na tematy raczej mniej
> bezpośrednio związane z Javą i produktami z którymi współpracuje.
> Wypowiadam się na te tematy, którymi się interesuję i które staram się
> sprawdzać w praktyce. M.in. na temat narzutów systemu operacyjnego.
> Po prostu nie widzę żadnej korzyści z tworzenia rozwiązania całkowicie
> innego, całkowicie inaczej administrowanego, a realizującego zadania, które
> są spokojnie do zrealizowania przy pomocy istniejących systemów
> operacyjnych.
> Może się mylę odnośnie tego, że całkowicie inaczej się nimi administruje...
> Jeśli jest to po prostu kolejna alternatywa w świecie UNIX-ów, to wtedy OK.
> Ale wątpię aby to było UNIX-o-podobne, bo nikt by się tu nie zachwycał tym,
> że niby pozbyto się systemu operacyjnego.
dzieciak, który się włamie na serwer nie będzie potrafił nic popsuć.
Przykłady:
Na Uniwersytecie Warszawskim serwery wirtualne na których prawie
wszyscy instalują co chcą stały na Novelu. Nawet po włamaniu się i
uzyskaniu dostępu do systemu większość dzieciaków wymiękała - inna
struktura katalogów - nie ma dysku c:, nie ma /var/lib/log kompilator
gcc jakiś dziwny... Nic wielkiego się nie działo. Kid-scripty trochę
sobie nie dawały rady.
Gdzieś widziałem takie zestawienie systemów, które najrzadziej stają
się ofiarami włamów i zwyciązcą był IRIX(mam takiego na swoim INDY).
Wygrał nie dla tego, że jest bezbłędny, lecz dla tego, że jest
egzotyczny.
W tym przypadku masz coś jeszcze bardziej egzotycznego - Jave bez
systemu, ale z jego możliwościami (obsługi IO, tcpip). Nikt nie zmusza
do stosowania - po prostu wspomniałem o tym, bo to ciekawostka, ale
dla tych, którzy mają takie potrzeby może być przydatne. Moim zdaniem
największą zaletą jest to, że nie jest to "UNIXO podobne", bo każdy
kto ma wystarczające umiejętności, aby włamać się do czegoś takiego
może legalnie zarabiać tyle, aby nie miał czasu na zrobienie tego:)
Waldek Kot
> użyjemy czegoś niewiele różniącego się od niego, a mającego inną nazwę, to
> coś istotnego zyskamy.
Po pierwsze, to nikt nikomu nic nie wmawia. To jest grupa dyskusyjna i
myślę, że póki co w miarę udaje się nam skupiać na technologii, a
unikać sprzedawania, spamowania itd. Temat wirtualizacji jest bardzo
ciekawy, temat wirtualizacji Java też wywołuje sporo fajnych
dyskusji... Technologicznych. Na biznesowe to chyba NTG.
Różnice między VE a klasycznym OS są dosyć duże (choć wiele zależy od
tego co uznamy za wymaganą funkcjonalność w OS). Dla przykładu:
- VE jest jednoprocesowe i jednoużytkownikowe
- jedynym procesem który może działać jest JVM
- zarządzanie zasobami (pamięcią, CPU, I/O, itd) jest przykrojone do
tego co potrzebuje specyficzna aplikacja (tu: JVM). Sporo zadań
przejmuje też hypervisor znajdujący się "pod spodem" (tj. pod VE).
- sprzęt (tu jest to wirtualny sprzęt) na którym VE działa jest bardzo
ograniczony (właściwie jedyną różnicą jest CPU) - założenie jest, że
musi to być hypervisor (należy się spodziewać, że będzie to wyłącznie
bazujący na Xen Oracle VM). Przynajmniej tak to wygląda z zewnątrz, bo
technicznie da się VE uruchomić bezpośrednio na fizycznym sprzęcie
(ale nikt rozsądny na tym poziomie nie będzie babrał się w obsługę
sprzętu, pisanie driver'ów, itd - użycie hypervisor'a dramatycznie
ułatwia tu sprawę).
> Narzut samego kernela systemu operacyjnego (na przykładzie Linuksa, bo
> akurat jego używam na codzień, do różnych zastosowań) jeśli chodzi o
> wydajność, czy zajętość pamięci jest znikomy.
Akurat w przypadku wirtualizacji narzut ten może być spory, gdy weźmie
się pod uwagę, że nawet na jednym fizycznym serwerze możesz mieć SETKI
jednocześnie działających maszyn wirtualnych, czyli ten narzut należy
zmultiplikować przez liczbę maszyn wirtualnych. Ten narzut dotyczy nie
tylko CPU, pamięci, czy sieci, ale także storage'u (rozmiar pliku
maszyny wirtualnej).
Inny aspekt tego "narzutu", to to, że JVM obsługująca serwerowe
aplikacje, to z systemu operacyjnego potrzebuje bardzo niewiele:
- bardzo niskopoziomowe zarządzanie pamięcią
- bardzo niskopoziomowe zarządzanie wątkami
- I/O czyli dostęp do sieci
Stanowi to bardzo mały procent (gdy pod spodem jest hypervisor to może
jest to 0.5% ?) funkcjonalności klasycznego OS, a w dodatku OS nie
rozumie tego co dzieje się wewnątrz JVM (na przykład garbage
collection) i wręcz czasem przeszkadza JVM (swapping pamięci
wirtualnej podczas garbage collection ? nieoptymalny scheduling wątków
czekających na blokadzie ? itd.).
> Natomiast wygoda używania systemu w miarę znanego, przetestowanego,
> jest dużo większa, niż sztucznego
> tworu zrobionego przez korporację specjalnie po to, aby uzależnić
> użytkowników od konkretnego produktu.
Równie dobrze możesz zarzucać Microsoftowi, HP czy Red Hatowi
uzależnianie od OS. Zauważ też, że bardzo mocno pokazuję sytuację, w
której to podejście z wirtualizacją Java ma sens: serwerowe aplikacje
Java. W tej sytuacji klasyczny OS jest w przytłaczającej mierze NIE
UŻYWANY.
> I ten twór i tak musi spełnić te
> zadania, które spełniał kernel standardowego systemu, więc musi wprowadzić
> swój narzut; mały - mniej więcej taki sam, jak zwykły kernel.
Nie, bo dzięki przyjętym powyżej założeniom taki kernel pozwala
wprowadzić całkiem sporo optymalizacji, które nie mają sensu w kernelu
normalnego OS. Nie zrozum mnie źle - ja nie neguję klasycznych OS.
Tyle że dzięki upowszechnieniu się wirtualizacji budowa OS
dedykowanych dla konkretnych typów przetwarzania jest znacznie
prostsza.
Przykład jednej z możliwych optymalizacji (takiej która dla normalnego
OS nie ma sensu), to choćby jednoprocesowość i jednoużytkownikowość
VE. W przypadku serwerowych aplikacji Java to jest dosyć typowe, że
poza JVM i uruchomionym w niej serwerem aplikacyjnym na danej
fizycznej maszynie nic innego już nie działa (przynajmniej dotyczy to
najbardziej popularnych dzisiaj w takich zastosowaniach maszynach typu
blade, najczęściej 1-2 procesorowych z 2-4GB RAM). Wielowątkowość i
security w serwerowych aplikacjach Java i tak dostajesz od JVM.
Powtarzam się, ale popatrz zresztą na konsole do gier (np. XBox) - i
zobacz jakie przyspieszenie daje zdjęcie wieloprocesowości i kontroli
security z OS. Wystarczy popatrzeć na grafikę konsol w porównaniu do
grafiki PC-tów i wziąć pod uwagę sprzęt obu. Mam nadzieję, że analogia
trafiona...Wieloprocesowość i wieloużytkownikowość grze na konsoli
jest mało potrzebna...
Inny przykład optymalizacji podałem wcześniej - możliwość
przekazywania pamięci (Java heap) pomiędzy JVM uruchomionymi w ramach
tej samej fizycznej maszyny. Czyli znany z wirtualizacji memory
balloning, tyle, że działający na poziomie Java heap (czyli struktury
pamięci, której klasyczny OS w ogóle nie odróżnia).
Takich optymalizacji jest jeszcze bardzo wiele (a nieodkrytych jeszcze
więcej).
> Po prostu nie widzę żadnej korzyści z tworzenia rozwiązania całkowicie
> innego, całkowicie inaczej administrowanego, a realizującego zadania, które
> są spokojnie do zrealizowania przy pomocy istniejących systemów
> operacyjnych.
> Może się mylę odnośnie tego, że całkowicie inaczej się nimi administruje...
Nie - w sumie dosyć podobnie. Większość narzędzi daje software do
wirtualizacji, pewne narzędzia daje sama warstwa VE, resztę narzędzia
do zarządzania JVM, serwera aplikacyjnego, itd. Z racji tego, że VE
jest znacznie mniejszy niż klasyczny OS (plus przyjęte powyżej
założenia - choćby co do security), to też trzeba nim znacznie mniej
zarządzać.
W przypadku wirtualizacji wszyscy zmierzają w kierunku appliance -
jedyne co trzeba z tym zrobić to wgrać, skonfigurować kilka parametrów
(typu konfiguracja sieci, hasła, itd), nacisnąć przycisk "Power On" i
już. Warto to porównać z godzinami spędzonymi na instalację,
patchowanie, konfigurowanie, tuning, itd wszystkich warstw (OS, JVM,
serwera aplikacyjnego, aplikacji, itd.)... Osobiście to wątpię, żeby
model dystrybucji oprogramowania polegający na dystrybucji instalek
utrzymał się jeszcze jakoś specjalnie długo. Dystrybuować będzie się
głównie pliki maszyn wirtualnych. Zajawki tego już widać.
> Jeśli jest to po prostu kolejna alternatywa w świecie UNIX-ów, to wtedy OK.
> Ale wątpię aby to było UNIX-o-podobne, bo nikt by się tu nie zachwycał tym,
> że niby pozbyto się systemu operacyjnego.
W pewnym stopniu jest to Unix-o-podobne, głównie z racji podobnego do
Linux'a Application Binary Interface (podkreślam, podobnego ABI).
Implementacja jest zupełnie nowa. Alternatywą do klasycznego OS jest
TYLKO w zakresie serwerowych aplikacji Java. W innych zakresach
oczywiście nie...
Jakiś czas temu na tej grupie temat wirtualizacji Java się już
pojawił. Po tym linkiem jest zapis rekordowo długiej dyskusji (z
perspektywy czasu mimo wszystko w dużej mierze merytorycznej):
http://groups.google.com/group/pl.comp.lang.java/browse_frm/thread/a18a3bac1189d1c4#
Pozdrawiam,
Waldek Kot
Waldek Kot
> > Na tym, że wmawia się użytkownikom, że jeśli zamiast systemu operacyjnego
> > użyjemy czegoś niewiele różniącego się od niego, a mającego inną nazwę, to
> > coś istotnego zyskamy.
>
> Dobrze - jeśli chodzi o definicje, to JRockit można nazwać systmem
> operacyjnym, który portafi uruchamiać aplikacje, które zostały
> skompilowane w javie. Jest to system specyficzny, którego twórcy nie
> chcą nazywać systemem operacyjnym, bo jego specyfika czyni go bardziej
> JVM niż systemem operacyjnym pod względem ilości kodu poświęconego na
> daną funkcjonalność.
Dodam tylko drobną uwagę, że stos wygląda tak:
Hardware -> hypervisor (Oracle VM) -> guest VM -> VE -> JVM -> serwer
aplikacyjny -> aplikacja
Czyli zamiast OS jest VE. JVM i wszystko co jest poniżej nie jest
zmodyfikowane. Podobnie to co jest poniżej VE, czyli hypervisor (tu:
Oracle VM) też jest "z półki".
Można odnaleźć podobne projekty - choćby dawny (1998/1999 chyba)
projektu IBM i Sun pt. JavaOS albo IBM Libra czy (ostatnio) Sun
JavaGuest (choćby tu: http://www.youtube.com/watch?v=iHIaH12f2Ek&hl=pl).
Są i podobieństwa, ale też i istotne różnice technologiczne. A co do
biznesowych, to NTG :-).
> Im większej egzotyki się używa, tym większe prawdopodobieństwo, że
> dzieciak, który się włamie na serwer nie będzie potrafił nic popsuć.
Co do security, to myślę, że wirtualizacja daje tu więcej niż tylko
"egzotyczne = bezpieczniejsze". Po pierwsze tak jak Piotrze napisałeś
- założenia VE czynią ją potencjalnie bardziej bezpieczną
("potencjalnie", bo w zagadnieniach dot. security innego podejścia
mieć nie wolno). Mam tu na myśli przede wszystkim założenie, że w
ramach VE działą tylko jeden użytkownik. Do tego jest możliwy tylko
jeden proces, więc należałoby złamać security JVM (a najczęściej
jeszcze security Java EE, bo zwykle w ramach JVM będzie działać serwer
aplikacyjny). Tak jak pisałem można odpalić wątek SSH, ale to też jest
pod pełną kontrolą (i maksymalnie może być jedna taka sesja). Do tego
dochodzi oczywiście całe security hypervisor'a i oprogramowania
zarządzającego wirtualizacją (tu: bazującego na Xen - OracleVM) -
czyli w zasadzie mamy nawet 2 sandbox'y: JVM i VM.
Nie ma też najmniejszego problemu, aby cała maszyna wirtualna była
read-only (tj. w postaci ISO - mniej więcej tak jak płyta CD w
zmount'owanym CDROM). Wszelkie dane (np. logi) nie muszą być
przechowywane w lokalnym systemie plików (wirtualnym dysku), tylko
mogą być przekazane do zewnętrznego storage'u i tam chronione (np.
poprzez NFS czy iSCSI). Jedyne co się utraci, to trochę wydajności
(choć też tylko wtedy, gdy wirtualny lokalny dysk jest zmapowany na
fizyczny lokalny dysk - jeśli zmapowanie jest na NFS, iSCSI, czy
cokolwiek innego, to w zasadzie wydajność będzie podobna, bo i tak
mamy zdalną komunikację).
To czyni z takiego podejścia raczej ekstremalnie bezpieczne
rozwiązanie...
Pozdrawiam,
Waldek Kot
Wojciech Jaczewski
>> Na tym, że wmawia się użytkownikom, że jeśli zamiast systemu operacyjnego
>> użyjemy czegoś niewiele różniącego się od niego, a mającego inną nazwę,
>> to coś istotnego zyskamy.
>
> Po pierwsze, to nikt nikomu nic nie wmawia. To jest grupa dyskusyjna i
> myślę, że póki co w miarę udaje się nam skupiać na technologii, a
> unikać sprzedawania, spamowania itd.
Nie twierdzę, że ktokolwiek na tej grupie ma finansowy interes we wmawianiu
czegoś pozostałym. Chodzi mi o samą firmę stojącą za danym produktem.
Wojciech Jaczewski
> Im większej egzotyki się używa, tym większe prawdopodobieństwo, że
> dzieciak, który się włamie na serwer nie będzie potrafił nic popsuć.
> Przykłady:
> Na Uniwersytecie Warszawskim serwery wirtualne na których prawie
> wszyscy instalują co chcą stały na Novelu. Nawet po włamaniu się i
> uzyskaniu dostępu do systemu większość dzieciaków wymiękała - inna
> struktura katalogów - nie ma dysku c:, nie ma /var/lib/log kompilator
> gcc jakiś dziwny... Nic wielkiego się nie działo. Kid-scripty trochę
> sobie nie dawały rady.
Gorzej, jeśli np. administrator takiego systemu postanowi się zwolnić i są
trudności, aby znaleźć drugiego, odpowiednio doświadczonego w tym temacie.
Żeby w razie różnych przypadków losowych, a nie celowych prób ataku, był w
stanie zdiagnozować i znaleźć rozwiązanie problemów.
Albo żeby przy okazji wrażania jakiejś nowej funkcjonalności nie poczynił
przez przypadek - z powodu braku wprawy - większej szkody, niż potencjalny
włamywacz.
Wojciech Jaczewski
> Różnice między VE a klasycznym OS są dosyć duże (choć wiele zależy od
> tego co uznamy za wymaganą funkcjonalność w OS). Dla przykładu:
> - VE jest jednoprocesowe i jednoużytkownikowe
> - jedynym procesem który może działać jest JVM
> - zarządzanie zasobami (pamięcią, CPU, I/O, itd) jest przykrojone do
> tego co potrzebuje specyficzna aplikacja (tu: JVM).
Z ciekawości: czy te VE mogą działać z wyłączonym sprzętowym mechanizmem
stronicowania pamięci? Gdyby tak, to by oznaczało, że rzeczywiście robią
coś inaczej niż typowy system operacyjny. Ale sądzę, że jednak nie...
>> Narzut samego kernela systemu operacyjnego (na przykładzie Linuksa, bo
>> akurat jego używam na codzień, do różnych zastosowań) jeśli chodzi o
>> wydajność, czy zajętość pamięci jest znikomy.
>
> Akurat w przypadku wirtualizacji narzut ten może być spory, gdy weźmie
> się pod uwagę, że nawet na jednym fizycznym serwerze możesz mieć SETKI
> jednocześnie działających maszyn wirtualnych, czyli ten narzut należy
> zmultiplikować przez liczbę maszyn wirtualnych. Ten narzut dotyczy nie
> tylko CPU, pamięci, czy sieci, ale także storage'u (rozmiar pliku
> maszyny wirtualnej).
A dlaczego ten plik wraz systemem miałby być jakoś znacząco większy w
przypadku wirtualizacji z pomocą systemu operacyjnego? Przykładowo, jądro
Linuksa to jakieś 2MB na dysku. Do tego initrd kilkaset kB. Do uruchomienia
jednego programu więcej nie potrzeba.
I te rozmiary, które podaje, to nie są jakieś wartości nadzwyczajne, tylko
typowe, łatwe do uzyskania.
> Stanowi to bardzo mały procent (gdy pod spodem jest hypervisor to może
> jest to 0.5% ?) funkcjonalności klasycznego OS
Nie aż taki mały.
Natomiast ta dodatkowa funkcjonalność systemu, w niczym nie przeszkadza,
można z niej nie korzystać.
> a w dodatku OS nie
> rozumie tego co dzieje się wewnątrz JVM (na przykład garbage
> collection) i wręcz czasem przeszkadza JVM (swapping pamięci
> wirtualnej podczas garbage collection ? nieoptymalny scheduling wątków
> czekających na blokadzie ? itd.).
Jest to nie do zrobienia zarówno w systemie, jak i hypervisorze, czy innych
rozwiązaniach, aby przewidywać co poszczególne programy mają zamiar zaraz
zrobić i dobierać na tę okoliczność jakąś reakcję.
I to niezależnie, czy będziemy mieć uruchomione wyłącznie JVM-y, czy też
różne programy.
>> I ten twór i tak musi spełnić te
>> zadania, które spełniał kernel standardowego systemu, więc musi
>> wprowadzić swój narzut; mały - mniej więcej taki sam, jak zwykły kernel.
>
> Nie, bo dzięki przyjętym powyżej założeniom taki kernel pozwala
> wprowadzić całkiem sporo optymalizacji, które nie mają sensu w kernelu
> normalnego OS.
Na razie w nie nie wierzę; poszukam w google konkretów. Jeśli znasz jakieś
konkretne odnośniki, gdzie opisane są te optymalizacje, najlepiej z
pomiarami, byłbym wdzięczny...
> Przykład jednej z możliwych optymalizacji (takiej która dla normalnego
> OS nie ma sensu), to choćby jednoprocesowość i jednoużytkownikowość
> VE.
Ciekawe, czy są gdzieś dostępne pomiary, co to miałoby dać, bo moim zdaniem
taka optymalizacja nie ma szans zbliżyć się do 0.1% zysku w wydajności.
> Powtarzam się, ale popatrz zresztą na konsole do gier (np. XBox) - i
> zobacz jakie przyspieszenie daje zdjęcie wieloprocesowości i kontroli
> security z OS.
A jest zdjęte?
> Inny przykład optymalizacji podałem wcześniej - możliwość
> przekazywania pamięci (Java heap) pomiędzy JVM uruchomionymi w ramach
> tej samej fizycznej maszyny. Czyli znany z wirtualizacji memory
> balloning, tyle, że działający na poziomie Java heap (czyli struktury
> pamięci, której klasyczny OS w ogóle nie odróżnia).
Skoro poszczególne JVM mają wchodzić ze sobą w różne interakcje, to po co w
ogóle było je wirtualizować? Uruchomić wszystkie na jednym systemie bez
wirtualizacji i niech się ze sobą dogadają...
> Nie - w sumie dosyć podobnie. Większość narzędzi daje software do
> wirtualizacji, pewne narzędzia daje sama warstwa VE, resztę narzędzia
> do zarządzania JVM, serwera aplikacyjnego, itd. Z racji tego, że VE
> jest znacznie mniejszy niż klasyczny OS
Jaki ma zwykle rozmiar?
> W przypadku wirtualizacji wszyscy zmierzają w kierunku appliance -
> jedyne co trzeba z tym zrobić to wgrać, skonfigurować kilka parametrów
> (typu konfiguracja sieci, hasła, itd), nacisnąć przycisk "Power On" i
> już.
Na temat systemu operacyjnego można napisać dokładnie to samo. Pozostaje
kwestia co kto rozumie przez skonfigurowanie "kilku parametrów".
Waldek Kot
> Z ciekawości: czy te VE mogą działać z wyłączonym sprzętowym mechanizmem
> stronicowania pamięci? Gdyby tak, to by oznaczało, że rzeczywiście robią
> coś inaczej niż typowy system operacyjny. Ale sądzę, że jednak nie...
Jak to często bywa w przypadku wirtualizacji, odpowiedź brzmi: i tak,
i nie. I "tak", bo hypervisor używa tego co mu daje CPU, czy chipset
(i to zarówno jeśli chodzi o wsparcie dla pamięci wirtualnej - MMU,
jak i wirtualnej wirtualnej - np. VT-x). Samo VE (podobnie jak i
zwirtualizowany klasyczny system operacyjny - guest OS) obydwu tych
poziomów wsparcia nie widzi - więc odpowiedź brzmiałaby "nie".
Jeśli pytasz, czy VE zawiera kod zarządzający pamięciami wirtualną i
fizyczną, to tak, chociaż jest on inny niż np. ten który można
zobaczyć w jądrze Linux-a. Konkretnie, to np. ma jeden poziom
mapowania mniej (Linux ma 3 lub 4 poziomy: [page global directory] ->
page directory -> page index -> offset). Dzięki temu ścieżka
odnajdywania adresu jest krótsza. Można było sobie na taką prostszą
strukturę pozwolić, właśnie dzięki przyjęciu założenia o
jednoprocesowości (przy tym założeniu liczba przełączeń kontekstu jest
znacznie mniejsza niż w klasycznym OS, który musi obsługiwać wiele
procesów). Drugą różnicą w VE jest to, że nie ma operacji swapping'u
stron z RAM do dysku (czy innego storage'u). VE nie wykonuje
swapping'u, tylko powiadamia hypervisor (via hypercall), który to
ewentualnie taki swapping przeprowadza.
> > Akurat w przypadku wirtualizacji narzut ten może być spory, gdy weźmie
> > się pod uwagę, że nawet na jednym fizycznym serwerze możesz mieć SETKI
> > jednocześnie działających maszyn wirtualnych, czyli ten narzut należy
> > zmultiplikować przez liczbę maszyn wirtualnych. Ten narzut dotyczy nie
> > tylko CPU, pamięci, czy sieci, ale także storage'u (rozmiar pliku
> > maszyny wirtualnej).
>
> A dlaczego ten plik wraz systemem miałby być jakoś znacząco większy w
> przypadku wirtualizacji z pomocą systemu operacyjnego? Przykładowo, jądro
> Linuksa to jakieś 2MB na dysku. Do tego initrd kilkaset kB. Do uruchomienia
> jednego programu więcej nie potrzeba.
> I te rozmiary, które podaje, to nie są jakieś wartości nadzwyczajne, tylko
> typowe, łatwe do uzyskania.
Owszem, technicznie jest to możliwe do takich małych rozmiarów zejść
(choć, na marginesie, wielkości które podajesz wydają mi się kilka
razy zaniżone - przynajmniej w typowych generycznych OS, w rodzaju
RHEL, czy SUSE). Ale w praktyce jakoś mało kto tak robi - zwykle
bierze się normalną dystrybucję OS, co powoduje, że rozmiar pliku
maszyny wirtualnej łatwo sięga 2-3 GB i zużywa minimum 1 GB RAM. Od
pewnego czasu pojawiają się JeOS (Just enough OS), przycięte do
rozmiaru ok. 100MB (i minimum RAM ok. 128 MB) - przycięcie głównie
wynikające z tego, że taki JeOS w praktyce nadaje się do uruchomienia
tylko jako guest OS działający w ramach hypervisor'a (hypervisor
wystawia bardzo standardowy sprzęt, stąd jest możliwość wycięcia 95%
sterowników z jądra, a sterowniki - jak wiadomo - to ponad połowa kodu
jądra). Technicznie przyciąć da się więcej, ale pojawia się problem z
aplikacjami (bazy danych, ERP, itd), których producenci zwykle nie
określają minimalnego zakresu jądra i plików danego OS wymaganych do
pracy z taką aplikacją. Nie ma też pewności, że kolejna wersja takiej
aplikacji nie będzie jednak wymagała dodatkowych funkcji. W przypadku
serwerowych aplikacji Java, to ryzyko jest znacznie mniejsze - śmiem
twierdzić, że niemal nie występuje, bo w przeważającej większości
przypadków, np. aplikacje J2EE/Java EE zakładają, że pod spodem muszą
być odpowiednie wersje Javy i serwera aplikacyjnego i już. Bardzo
rzadko takie aplikacje korzystają z kodu natywnego (tj. działającego
poza JVM).
Zwykły OS potrzebuje też określonej ilości RAM (min. 1GB w typowej
dystrybucji, 128-256MB w JeOS), znacznie większej niż tej wymaganej
przez VE (parę MB). Mnożąc przez setki maszyn wirtualnych otrzymuje
się konkretne oszczędności...
Podejście o którym piszesz też ma sens - określiłbym je jako top-down:
wychodząc od pełnego OS (np. dystrybucji w rodzaju RedHat EL) patrzymy
co możnaby wyrzucić, aby dało się uruchomić JVM. W JRockit podejście
było bottom-up: wychodząc od zera zróbmy tylko tyle, aby JVM działał.
Z tym, że to co zostaje w podejściu top-down, to wciąż generyczny OS
niezbyt pomyślany pod kątem wymagań JVM. W podejściu bottom-up, to
bardzo specjalizowana namiastka OS, za to od początku do końca
skonstruowana dla konkretnej JVM.
Przykładów podobnych podejść można też szukać w świecie hypervisorów -
Xen, a szczególnie VMware ESX to specjalizowane OS pomyślane wyłącznie
pod kątem uruchamiania maszyn wirtualnych. Nie nadają się do niczego
innego, ale w swoim zadaniu wszystko inne przewyższają... Ludzie
piszący VMware ESX stworzyli swoją namiastkę OS, zamiast poprzykrajać
jakąś dystrybucję Linux-a...
> > Stanowi to bardzo mały procent (gdy pod spodem jest hypervisor to może
> > jest to 0.5% ?) funkcjonalności klasycznego OS
>
> Nie aż taki mały.
> Natomiast ta dodatkowa funkcjonalność systemu, w niczym nie przeszkadza,
> można z niej nie korzystać.
Deweloperzy którzy JRockit VE napisali tak właśnie ten procent
wykorzystania OS przez JVM określają...
Owszem, ten narzut przeszkadza i ma wpływ na wydajność. Szczególnie
jest to widoczne w przypadku wirtualizacji, gdzie zachodzi zjawisko
potrójnej wirtualizacji: JVM -> guest VM -> hypervisor. Motywacja, aby
się tego zbędnego tłuszczu pozbyć, jest mniej więcej taka sama, jak
motywacja do parawirtualizowania systemów operacyjnych (guest OS)...
> > a w dodatku OS nie
> > rozumie tego co dzieje się wewnątrz JVM (na przykład garbage
> > collection) i wręcz czasem przeszkadza JVM (swapping pamięci
> > wirtualnej podczas garbage collection ? nieoptymalny scheduling wątków
> > czekających na blokadzie ? itd.).
>
> Jest to nie do zrobienia zarówno w systemie, jak i hypervisorze, czy innych
> rozwiązaniach, aby przewidywać co poszczególne programy mają zamiar zaraz
> zrobić i dobierać na tę okoliczność jakąś reakcję.
> I to niezależnie, czy będziemy mieć uruchomione wyłącznie JVM-y, czy też
> różne programy.
To co ja napisałem, to trochę inny przypadek od tego, który Ty
podałeś. Nie tyle chodzi o przewidywanie reakcji, co o taki dobór
parametrów scheduling'u, czy zarządzania pamięcią który uwzględnia to
co aktualnie dzieje się "poziom wyżej" (czyli w JVM) - albo i pomiędzy
JVM. Nie ma też specjalnego powodu, aby w tym co robi ta warstwa "a'la
OS" nie miała brać pod uwagę danych profiling'owych zbieranych przez
JVM. Nie wiem, czy robi to aktualnie JRockit VE, ale nie zdziwiłbym
się, gdyby za jakiś czas takie optymalizacje się pojawiły. Tak jak
napisałem wcześniej - tutaj ten niby-OS wie, że JEDYNYM rodzajem
aplikacji, który w nim będzie działać jest JVM, a zatem "wie" czego
się spodziewać. Taki OS może też w określonym stopniu wpływać na
sposób działania hypervisor'a...
> >> I ten twór i tak musi spełnić te
> >> zadania, które spełniał kernel standardowego systemu, więc musi
> >> wprowadzić swój narzut; mały - mniej więcej taki sam, jak zwykły kernel.
>
> > Nie, bo dzięki przyjętym powyżej założeniom taki kernel pozwala
> > wprowadzić całkiem sporo optymalizacji, które nie mają sensu w kernelu
> > normalnego OS.
>
> Na razie w nie nie wierzę; poszukam w google konkretów. Jeśli znasz jakieś
> konkretne odnośniki, gdzie opisane są te optymalizacje, najlepiej z
> pomiarami, byłbym wdzięczny...
Trochę takich informacji można odnaleźć w sieci - choć po zmianie
stron internetowych z BEA na Oracle trudniej to odnaleźć :-(. Poszukaj
w google hasła: WebLogic Virtual Edition.
Trochę wykraczamy poza technologię, ale już pierwsza, praktycznie
nieoptymalizowana pod kątem wydajności wersja VE dawała wydajność taką
samą, jak wirtualizowanego OS opartego o Linux. W większości testów
wewnętrznych niemal już regularnie wydajność jest lepsza od fizycznego
Linux-a (oczywiście chodzi o porównanie: JVM/VE vs. JVM/wirtualny-
Linux vs. JVM/fizyczny-Linux). Ale wszyscy tu głęboko wierzą w
pokazanie światu znacznie, znacznie lepszych wyników (choć jak
wyczytuję między liniami Twoich Wojtku wypowiedzi - już osiągnięcie
niegorszej wydajności niż klasyczny OS to będzie duża
niespodzianka ;-)...
> > Przykład jednej z możliwych optymalizacji (takiej która dla normalnego
> > OS nie ma sensu), to choćby jednoprocesowość i jednoużytkownikowość
> > VE.
>
> Ciekawe, czy są gdzieś dostępne pomiary, co to miałoby dać, bo moim zdaniem
> taka optymalizacja nie ma szans zbliżyć się do 0.1% zysku w wydajności.
Ciężko to udowodnić, ale szacunki są takie, że "odzyskiwane" jest ok.
30% czasu CPU. Opisany wcześniej model zarządzania pamięcią wirtualną
(wirtualną) też działa ok. 40% szybciej.
Z całą pewnością scheduler w jądrze Linux'a jest lepiej
zoptymalizowany dla maszyn z więcej niż 8 CPU lub rdzeniami. Z tym, że
technologie wirtualizacyjne dzisiaj jeszcze w takim miejscu nie są. W
większości dzisiejsze hypervisor'y pozwalają utworzyć maszyny
wirtualne z max 8 wirtualnymi CPU, więc jest jeszcze czas, aby takie
optymalizacje wprowadzić... A wątpię, aby świat szybko chciał tworzyć
maszyny wirtualne z 16 i więcej wirtualnymi CPU...
> > Powtarzam się, ale popatrz zresztą na konsole do gier (np. XBox) - i
> > zobacz jakie przyspieszenie daje zdjęcie wieloprocesowości i kontroli
> > security z OS.
>
> A jest zdjęte?
Owszem, jest zdjęte - nie ma informacji z MS, ale z tego co przekazują
hackerzy OS w XBox-ie, to jądro XBox OS pochodzi z czasów Windows
2000, z tym, że m.in. jest single-process, single-user. Wracając do
zysku z takiej wydajności, to inaczej nie da się wytłumaczyć różnicy w
jakości grafiki gier. Sprzęt w XBox jest dosyć PC-towy (mimo, że CPU
bazuje na PowerPC), tyle, że to PC sprzed 3 lat...
Zresztą, w Xbox, MS poszedł nawet dalej, bo gra działa w trybie
kernel'a (z tego co gdzieś czytałem, to jedynie XBox Dashboard działa
w trybie user). W Jrockit VE aż tak daleko nie poszli :-)
> > Inny przykład optymalizacji podałem wcześniej - możliwość
> > przekazywania pamięci (Java heap) pomiędzy JVM uruchomionymi w ramach
> > tej samej fizycznej maszyny. Czyli znany z wirtualizacji memory
> > balloning, tyle, że działający na poziomie Java heap (czyli struktury
> > pamięci, której klasyczny OS w ogóle nie odróżnia).
>
> Skoro poszczególne JVM mają wchodzić ze sobą w różne interakcje, to po co w
> ogóle było je wirtualizować? Uruchomić wszystkie na jednym systemie bez
> wirtualizacji i niech się ze sobą dogadają...
Jedno drugiemu nie przeszkadza. Powody dla których stosuje się
wirtualizację są powszechnie znane - chyba że je podważasz ?
W każdym razie w podanej optymalizacji chodzi o to, że mając większą
kontrolę nad całym stosem (JVM, VE, hypervisor) można zmniejszyć
konieczność swapping-u (coś w rodzaju: hypervisor mówi do JVM: "hej,
oddaj trochę Java heap albo Cię zeswapuję"). Swapping jak wiadomo jest
bolesny dla wydajności. Tak jak podałem wcześniej, ta optymalizacja
jest podobna do tej wykonywanej przez większość dzisiejszych
hypervisor'ów (zarówno VMware jak i Xen ją mają), czyli memory
ballooning, w której hypervisor może dynamicznie dobierać ilość
wirtualnego RAM przypisanego do guest VM w zależności od ich potrzeb i
obciążenia (najczęściej w ustalonych granicach). Przy maszynie z 16
CPU hex-core (96 core), w której bez większego problemu uruchomisz ze
200 guest OS-ów, taka optymalizacja ma duże znaczenie dla ich
wydajności. Opisana optymalizacja w JVM jest odpowiednikiem memory
ballooning, tyle, że dla struktury pamięci jaką jest Java heap (a przy
założeniu, że na takiej maszynie uruchomisz ze 300 albo i więcej VE,
co najmniej równie ważna). W każdym razie, jeśli uznajesz sens memory
ballooning w hypervisor'ach, to powinieneś też uznać jej sens przy
wirtualizacji Java.
> > Nie - w sumie dosyć podobnie. Większość narzędzi daje software do
> > wirtualizacji, pewne narzędzia daje sama warstwa VE, resztę narzędzia
> > do zarządzania JVM, serwera aplikacyjnego, itd. Z racji tego, że VE
> > jest znacznie mniejszy niż klasyczny OS
>
> Jaki ma zwykle rozmiar?
JVM razem z VE ma ok. 45 MB. Samo VE ma kilkaset KB (oprócz jądra jest
jeszcze parę dodatków, w rodzaju SSH, klienta NFS, syslogu, czy
lokalny filesystem)... To daje plik ISO zawierający jeszcze serwer
aplikacyjny WebLogic Server na jakieś 300 MB. Chciałbym zobaczyć tak
przykrojonego Linux'a dla WebLogic Server'a ...
> > W przypadku wirtualizacji wszyscy zmierzają w kierunku appliance -
> > jedyne co trzeba z tym zrobić to wgrać, skonfigurować kilka parametrów
> > (typu konfiguracja sieci, hasła, itd), nacisnąć przycisk "Power On" i
> > już.
>
> Na temat systemu operacyjnego można napisać dokładnie to samo. Pozostaje
> kwestia co kto rozumie przez skonfigurowanie "kilku parametrów".
Z tą różnicą, że w appliance znajdujący się w nim OS (jakkolwiek go
rozumieć) jest już wcześniej skonfigurowany pod kątem działającego w
nim software'u (np. bazy danych, czy ERP). Inaczej mówiąc, autor
appliance całą tę pracę instalacyjno-konfiguracyjno-optymalizacyjną
już wykonał...
Pozdrawiam,
Waldek Kot
Wojciech Jaczewski
> Je�li pytasz, czy VE zawiera kod zarz�dzaj�cy pami�ciami wirtualn� i
> fizyczn�, to tak, chocia� jest on inny ni� np. ten kt�ry mo�na
> zobaczy� w j�drze Linux-a. Konkretnie, to np. ma jeden poziom
> mapowania mniej (Linux ma 3 lub 4 poziomy: [page global directory] ->
> page directory -> page index -> offset).
Z tego co kojarz�, Linux obs�uguje (dla x86) zar�wno 4kB strony, jak i te
2MB, lub 4MB, czyli odpowiednio jeden indeks wi�cej, lub mniej.
> Dzi�ki temu �cie�ka
> odnajdywania adresu jest kr�tsza. Mo�na by�o sobie na tak� prostsz�
> struktur� pozwoli�, w�a�nie dzi�ki przyj�ciu za�o�enia o
> jednoprocesowo�ci (przy tym za�o�eniu liczba prze��cze� kontekstu jest
> znacznie mniejsza ni� w klasycznym OS, kt�ry musi obs�ugiwa� wiele
> proces�w).
Przecie� ilo�� proces�w nie jest �ci�le zwi�zana z mechanizmem zarz�dzania
pami�ci�. Nic nie stoi na przeszkodzie, aby procesy pobiera�y od systemu
pami�� tylko w blokach 4MB, a nigdy mniejszych.
By� mo�e sam kod programu i jego bibliotek podczas wczytywania jest
umieszczany w stronach 4kB. Czy zawsze - tego nie wiem. Spr�buj� jeszcze
poszuka�, czy te� mo�liwe jest (przy u�yciu niemodyfikowanego j�dra)
wymuszenie wczytania binarki do pami�ci podzielonej na 4MB strony.
> Drug� r�nic� w VE jest to, �e nie ma operacji swapping'u
> stron z RAM do dysku (czy innego storage'u). VE nie wykonuje
> swapping'u, tylko powiadamia hypervisor (via hypercall), kt�ry to
> ewentualnie taki swapping przeprowadza.
W systemie te� mo�na swappingu nie w��cza�. Za��my, �e mamy w komputerze
4GB RAM i uruchomimy 8 maszyn wirtualnych, po 1GB RAM i 0 swap ka�da. Wtedy
swappingiem b�dzie si� zajmowa� wy��cznie system-nadzorca. Nawet wydaje
si�, �e podejmie decyzje o swapowaniu mniej-wi�cej tych samych stron, kt�re
wyrzuci�by system uruchomiony w wirtualnej maszynie.
>> A dlaczego ten plik wraz systemem mia�by by� jako� znacz�co wi�kszy w
>> przypadku wirtualizacji z pomoc� systemu operacyjnego? Przyk�adowo, j�dro
>> Linuksa to jakieďż˝ 2MB na dysku. Do tego initrd kilkaset kB. Do
>> uruchomienia jednego programu wi�cej nie potrzeba.
>> I te rozmiary, kt�re podaje, to nie s� jakie� warto�ci nadzwyczajne,
>> tylko typowe, �atwe do uzyskania.
>
> Owszem, technicznie jest to mo�liwe do takich ma�ych rozmiar�w zej��
> (cho�, na marginesie, wielko�ci kt�re podajesz wydaj� mi si� kilka
> razy zani�one - przynajmniej w typowych generycznych OS, w rodzaju
> RHEL, czy SUSE).
Do uruchamiania jednego procesu wi�cej nie trzeba. W tej wielko�ci, kt�r� ja
podaj� jest te� kilka podstawowych konsolowych narz�dzi.
> Ale w praktyce jako� ma�o kto tak robi - zwykle
> bierze si� normaln� dystrybucj� OS, co powoduje, �e rozmiar pliku
> maszyny wirtualnej �atwo si�ga 2-3 GB i zu�ywa minimum 1 GB RAM.
Je�li kto� podj�� decyzj�, �e chce mie� rozbudowany system i do tego
wszystkie mo�liwe programy zawsze uruchomione - jego wyb�r...
Kiedy� robi�em pr�by z klasycznym OS (Debian), zainstalowa�em wszystkie
wymagane pakiety + sshd + rsync i kilka innych, kt�re by�y mi potrzebne, do
systemu, maj�cego spe�nia� jakie� tam zadania na PC-104. I uruchamia�em
system z odblokowan� tylko okre�lon� ilo�ci� pami�ci RAM. Przy 24MB
dzia�a�o sprawnie. Przy 16MB ci�gle dzia�a�o, ale po pod��czeniu si� przez
ssh by�o wyra�ne spowolnienie. Rozmiar obrazu dysku troch� ponad 150MB.
U�ywaj�c skompresowanej partycji by�o to oko�o 50MB. Przy czym nie
wyrzuca�em z tego nawet takich rzeczy, kt�re si� domy�lnie zainstalowa�y,
jak dokumenty man, czy t�umaczenia komunikat�w na ile� tam j�zyk�w.
> Od
> pewnego czasu pojawiaj� si� JeOS (Just enough OS), przyci�te do
> rozmiaru ok. 100MB (i minimum RAM ok. 128 MB) - przyci�cie g��wnie
> wynikaj�ce z tego, �e taki JeOS w praktyce nadaje si� do uruchomienia
> tylko jako guest OS dzia�aj�cy w ramach hypervisor'a (hypervisor
> wystawia bardzo standardowy sprz�t, st�d jest mo�liwo�� wyci�cia 95%
> sterownik�w z j�dra, a sterowniki - jak wiadomo - to ponad po�owa kodu
> j�dra).
Ale nieu�ywane sterowniki pami�ci RAM nie zajmuj�. Nie musz� te� zajmowa�
dysku, je�li si� ich tam nie umie�ci, wiedz�c �e s� zb�dne.
> Z tym, �e to co zostaje w podej�ciu top-down, to wci�� generyczny OS
> niezbyt pomy�lany pod k�tem wymaga� JVM. W podej�ciu bottom-up, to
> bardzo specjalizowana namiastka OS, za to od pocz�tku do ko�ca
> skonstruowana dla konkretnej JVM.
Tyle �e systemy unikso-podobne ewoluowa�y ju� wiele lat. W przypadku
nowo�ci, opartych na innych za�o�eniach, jeszcze d�ugo b�d� dokucza� braki
funkcjonalno�ci, o kt�rej akurat pocz�tkowo nie pomy�lano.
> Przyk�ad�w podobnych podej�� mo�na te� szuka� w �wiecie hypervisor�w -
> Xen, a szczeg�lnie VMware ESX to specjalizowane OS pomy�lane wy��cznie
> pod k�tem uruchamiania maszyn wirtualnych. Nie nadaj� si� do niczego
> innego, ale w swoim zadaniu wszystko inne przewy�szaj�... Ludzie
> pisz�cy VMware ESX stworzyli swoj� namiastk� OS, zamiast poprzykraja�
> jak�� dystrybucj� Linux-a...
Bo taki by� ich interes. Trudno oczekiwa� od firmy, �e zrobi co�
korzystniejszego dla og�u, za to mniej korzystnego dla nich...
>> > Stanowi to bardzo ma�y procent (gdy pod spodem jest hypervisor to mo�e
>> > jest to 0.5% ?) funkcjonalno�ci klasycznego OS
>>
>> Nie a� taki ma�y.
>> Natomiast ta dodatkowa funkcjonalno�� systemu, w niczym nie przeszkadza,
>> mo�na z niej nie korzysta�.
>
> Deweloperzy kt�rzy JRockit VE napisali tak w�a�nie ten procent
> wykorzystania OS przez JVM okre�laj�...
Jeszcze nie zapozna�em si� z ich argumentacj�. My�l�, �e wkr�tce jeszcze si�
na ten temat wypowiem.
> Trochďż˝ wykraczamy poza technologiďż˝, ale juďż˝ pierwsza, praktycznie
> nieoptymalizowana pod k�tem wydajno�ci wersja VE dawa�a wydajno�� tak�
> sam�, jak wirtualizowanego OS opartego o Linux. W wi�kszo�ci test�w
> wewn�trznych niemal ju� regularnie wydajno�� jest lepsza od fizycznego
> Linux-a (oczywi�cie chodzi o por�wnanie: JVM/VE vs. JVM/wirtualny-
> Linux vs. JVM/fizyczny-Linux). Ale wszyscy tu g��boko wierz� w
> pokazanie �wiatu znacznie, znacznie lepszych wynik�w (cho� jak
> wyczytuj� mi�dzy liniami Twoich Wojtku wypowiedzi - ju� osi�gni�cie
> niegorszej wydajno�ci ni� klasyczny OS to b�dzie du�a
> niespodzianka ;-)...
W niegorsze wierz�. Tyle �e spodziewam si� mniej-wi�cej takich samych
rezultat�w, natomiast mniejszej wygody u�ywania, mniejszej r�norodno�ci
obs�ugiwanych urz�dze� itp.
> Ci�ko to udowodni�, ale szacunki s� takie, �e "odzyskiwane" jest ok.
> 30% czasu CPU. Opisany wcze�niej model zarz�dzania pami�ci� wirtualn�
> (wirtualn�) te� dzia�a ok. 40% szybciej.
Prawdopodobnie w jakich� szczeg�lnych przypadkach.
Z reszt�, nawet je�li przyspieszymy zarz�dzanie pami�ci�, kt�re b�dzie
zajmowa� - przyk�adowo - 0.1% czasu procesora, to przyrost wydajno�ci
b�dzie trudny do zauwa�enia.
>> > Powtarzam siďż˝, ale popatrz zresztďż˝ na konsole do gier (np. XBox) - i
>> > zobacz jakie przyspieszenie daje zdj�cie wieloprocesowo�ci i kontroli
>> > security z OS.
>>
>> A jest zdj�te?
>
> Owszem, jest zdj�te - nie ma informacji z MS, ale z tego co przekazuj�
> hackerzy OS w XBox-ie, to j�dro XBox OS pochodzi z czas�w Windows
> 2000, z tym, �e m.in. jest single-process, single-user. Wracaj�c do
> zysku z takiej wydajno�ci, to inaczej nie da si� wyt�umaczy� r�nicy w
> jako�ci grafiki gier. Sprz�t w XBox jest dosy� PC-towy (mimo, �e CPU
> bazuje na PowerPC), tyle, �e to PC sprzed 3 lat...
Z grafik� to w og�le jest troch� trudno�ci, zupe�nie innych ni� w programach
serwerowych. Np. zlecenie czegoďż˝ GPU i zareagowanie na przerwanie, gdy GPU
zako�czy; albo wykorzystanie DMA.
Raczej tu bym si� dopatrywa� trudno�ci w zrobieniu optymalnego programu w
userspace.
Waldek Kot
> > Jeśli pytasz, czy VE zawiera kod zarządzający pamięciami wirtualną i
> > fizyczną, to tak, chociaż jest on inny niż np. ten który można
> > mapowania mniej (Linux ma 3 lub 4 poziomy: [page global directory] ->
> > page directory -> page index -> offset).
>
> 2MB, lub 4MB, czyli odpowiednio jeden indeks więcej, lub mniej.
Masz oczywiście rację, co do możliwości obsługi stron większych niż
4KB przez Linux, z tym, że mi chodziło o coś trochę innego (chociaż w
sumie będzie to dosyć dobry przykład różnic/optymalizacji które były
możliwe do wykonania dzięki przyjęciu opisanych wcześniej założeń w
JRockitVE w stosunku do klasycznego OS).
Jak wiadomo ze szkoły, ten podział na 3 lub 4 poziomy przy
stronicowaniu wynika z potrzeby efektywnego przechowywania dla danego
procesu mapowania adresów wirtualnych na adresy fizyczne. Przyjęcie 3
lub 4 poziomów mapowania (obydwa mają sens zarówno dla 4KB, jak i dla
2MB i 4MB stron) daje dobry kompromis odnośnie ilości RAM wymaganej do
przechowywania tej struktury mapowań - dobry kompromis W KLASYCZNYCH
OS, w których jednocześnie mogą być uruchomione setki, czy tysiące
procesów (a te tablice mapowań adresów są PER PROCES). Przy 4KB
stronach pamięci i 32-bitach, gdyby przyjąć tylko 2 poziomy, to na
tablicę mapowań trzebaby przyjąć aż 4MB PER PROCES (czyli 1000
procesów i już nie ma fizycznego RAM do czegokolwiek innego).
Z tym, że w JRockitVE działa ZAWSZE tylko JEDEN proces (!) - a zatem
można sobie pozwolić, aby tę strukturę mapującą nieco uprościć (o
jeden poziom w stosunku do tego jaki jest w klasycznych OS, czyli
jeśli w klasycznym OS było to 3, to w JRockitVE może być 2, a jeśli 4
- czyli głównie dla 64-bitów - to w JRockitVE jest 3). Czyli przyjąć
2 poziomy i liniowe adresowanie. OK, to oznacza, że struktura mapowań
ma w skrajnym przypadku (całkowitego wykorzystania pamięci przez
proces) aż 4 MB, ale nie jest to problem, bo będzie tylko jedna taka
struktura (w dodatku, można tu wykorzystać ciągłość tego obszaru, co
pozwala szybciej obsługiwać pamięć, prealokacja, brak potrzeby
kompaktowania/defragmentacji, itd)...
Użycie stron o wielkości 4MB w JRockitVE też jest stosowane (2MB
wydają się być specyficznym pomysłem dla PAE), ale ma tutaj raczej
aspekt wydajnościowy:
- możliwość adresowania struktury danych o wielkości do 4MB w sposób
bezpośredni, czyli bez potrzeby odwoływania się do tablicy mapowań (i
oszczędzenia TLB, cache procesora, memory manager'a, itd)
- możliwość przechowywania struktury danych w sposób ciągły (dobry dla
cache CPU - wysoki poziom locality of data)
Dodatkową różnicą w przypadku "OS-a rozumiejącego JVM" jest to, że
pozwala on na dobór wielkości strony (4KB, 4MB) W ZALEŻNOŚCI od
konkretnej sytuacji - czytaj: programu Java w którym następuje
alokacja struktur Java - OBIEKTÓW Java ! Zresztą nie tylko obiektów
języka Java, ale też obiektów jakiegokolwiek języka, który działa na
JVM - Groovy, JRuby (Ruby na JVM), Scala, Jython (Python na JVM),
itd.
Klasyczny system operacyjny na to nie pozwala - on W OGÓLE nie rozumie
JVM i jego krytycznych struktur danych (np. Java heap)...
> > Dzięki temu ścieżka
> > odnajdywania adresu jest krótsza. Można było sobie na taką prostszą
> > strukturę pozwolić, właśnie dzięki przyjęciu założenia o
> > jednoprocesowości (przy tym założeniu liczba przełączeń kontekstu jest
> > znacznie mniejsza niż w klasycznym OS, który musi obsługiwać wiele
> > procesów).
>
> Przecież ilość procesów nie jest ściśle związana z mechanizmem zarządzania
> pamięcią.
Nie wiem czy dobrze Cię zrozumiałem, ale myślę, że jest. Pomysł z
tablicami stron głównie wynika z tego, aby mieć pamięć wirtualną dla
procesów przy stosunkowo niskim zużyciu pamięci...
> Nic nie stoi na przeszkodzie, aby procesy pobierały od systemu
> pamięć tylko w blokach 4MB, a nigdy mniejszych.
To też chyba trochę odbiega od tematu dyskusji, ale myślę, że owszem,
stoi na przeszkodzie - wydajność. Stałe przepychanie 4MB przy obecnych
rozmiarach magistral, szybkości FSB i ciągłego "oddalania" się pamięci
od CPU zabiłoby wydajność. 4MB per proces załamałoby też wszystkie
cache (przynajmniej obecne L1 i L2). Zgodziłbym się może że dałoby się
wszystkie te aspekty praktycznie zrobić np. na Itanium (i
inteligentnie sterować prefetch-em i spekulatywnym wykonywaniem kodu),
ale na x86 nie ma takich możliwości. Na Itanium też zresztą wymagałoby
to stosownych re-kompilacji...
Pozdrawiam,
Waldek Kot
Waldek Kot
> > Drugą różnicą w VE jest to, że nie ma operacji swapping'u
> > stron z RAM do dysku (czy innego storage'u). VE nie wykonuje
> > ewentualnie taki swapping przeprowadza.
>
> W systemie też można swappingu nie włączać. Załóżmy, że mamy w komputerze
> 4GB RAM i uruchomimy 8 maszyn wirtualnych, po 1GB RAM i 0 swap każda. Wtedy
> swappingiem będzie się zajmował wyłącznie system-nadzorca. Nawet wydaje
> się, że podejmie decyzje o swapowaniu mniej-więcej tych samych stron, które
> wyrzuciłby system uruchomiony w wirtualnej maszynie.
Owszem, można w OS wyłączyć swap, choć nawet na systemie z bardzo dużą
ilością RAM nie jest to rekomendowane (dotyczy to także Linux'a, mimo,
że swap nie jest w nim aż tak często używany jak np. w Windows-ie).
Nie jest rekomendowane, bo jeśli nie ma swap'u, to nie ma też
wyrzucania rzadko używanych stron pamięci i te strony pamięci nie będą
mogły być używane do znacznie sensowniejszego celu, czyli buforowania
(szczególnie buforowania I/O). Martotrawstwo, szczególnie bolesne przy
serwerowych zastosowaniach, gdzie pamięć to bardzo cenny zasób...
Czy VMM hypervisor'a podejmie decyzję o wyrzucaniu tych samych stron ?
W specyficznych przypadkach, ale warto pamiętać, że VMM hypervisor'a
podejmuje taką decyzję o swapowaniu tylko w sytuacjach awaryjnych
(brak RAM dla konkretnej maszyny wirtualnej). VMM guest OS'a decyzje o
tym które strony pamięci warto wyrzucić podejmuje cały czas, nawet
jeśli nie ma emergency i wolny RAM jest. VMM serwerowych systemów woli
dać tę pamięć buforom I/O, czy innym... Możnaby oczywiście wprawić
hypervisor w taki stan permanentego emergency, ale skutek dla
wydajności byłby raczej opłakany...
To co napisałem o optymalizacji w JRockitVE dotyczyło zresztą jeszcze
czegoś innego. Otóż, dzięki tej optymalizacji JVM działające w ramach
danego hypervisor'a mogą przeprowadzić proces garbage collection
jeszcze ZANIM zajdzie konieczność swapowania przez hypervisor.
Operacja GC w porównaniu do operacji swapowania jest znacznie mniej
kosztowna. Bo Garbage Collection w Java heap NIE obejmuje bowiem
zrzucania stron na dysk, tylko porządkowania pamięci (=heap):
wyrzucania (usuwania z pamięci) tego co jest nieużywalne (śmieci),
kompaktowania (likwidacji dziur), itd.
W dodatku, tutaj nie dotyczy to tylko jednej JVM (jednego heap'a), ale
wielu - proces odzyskiwanie pamięci można więc przeproweadzić jeszcze
bardziej "inteligentnie". Dla przykładu: "zainicjuj proces GC w tej
JVM, w której GC był najdawniej wykonywany" (bo zwykle efekt działania
GC, czyli odzyskanie pamięci powinien być tu najlepszy. Wykonanie GC w
JVM w którym akurat przed chwilą GC się zakończył, zwykle da mały
zysk).
Wybór JVM może zresztą brać pod uwagę inne czynniki - GC w JVM która
wykonuje APLIKACJĘ mającą działać deterministycznie (real-time),
będzie bardziej bolesny niż w JVM, w której działa aplikacja serwująca
strony webowe (bo www jest rodzajem przetwarzania w którym raczej
chodzi o zwiększanie przepustowości - np. liczby obsługiwanych
reqestów na sekundę - niż minimalizowania czasu odpowiedzi - jak
strona www zamiast 2 sekund wygeneruje się w 2.1 sekundy, to zwykle
nikt płakać nie będzie :-).
Czasem nawet nie trzeba zmuszać JVM do wykonania garbage collection -
jedna JVM może "oddać" pamięć innej JVM poprzez zmniejszenie wielkości
swojego Java heap (coś jakby ustawienia -Xms i -Xmx w Java dotyczące
odpowiednio początkowego i maksymalnego rozmiaru Java heap były
dynamiczne i zmieniały się w zależności od potrzeb)...
Zwrócę też uwagę, że klasyczny OS nie rozumie struktury danych jaką
jest Java heap. Dla niego jest to ciąg bajtów jak każdy inny w ramach
tego procesu JVM. Implementacje Java heap i algorytmy zarządzające tą
strukturą są dzisiaj bardzo, bardzo skomplikowane i mają decydujący
wpływ na wydajność. Znowu - jest to szczególnie widoczne w serwerowych
aplikacjach (np. webowych), gdzie efektywność zarządzania pamięcią (a
także synchronizacja wątków) z której aplikacja korzysta ma znacznie
większe znaczenie (dla wydajności, szczególnie przepustowości) niż
optymalizacje kodu (notabene, tego rodzaju JVM jak JRockit nigdy nie
interpretują bytekodu i ZAWSZE wykonują kod maszynowy dopasowany do
danego sprzętu - "optymalność" tego kodu jest conajmniej taka sama jak
DOBREGO kodu w C, o ile nie lepsza).
Czyli, konkludując: OS który rozumie taką strukturę jak Java heap DLA
APLIKACJI JAVA bardziej efektywny niż taki, który nie rozumie...
Pozdrawiam,
Waldek Kot
Waldek Kot
> > bardzo specjalizowana namiastka OS, za to od początku do końca
> > skonstruowana dla konkretnej JVM.
>
> Tyle że systemy unikso-podobne ewoluowały już wiele lat. W przypadku
> nowości, opartych na innych założeniach, jeszcze długo będą dokuczać braki
> funkcjonalności, o której akurat początkowo nie pomyślano.
Hmm... Taki "OS" jak JRockitVE NIE jest jakąś egzotyką (tak
zrozumiałem użyte przez Ciebie określenie "nowość"). Osoby zajmujące
się teorią systemów operacyjnych zaklasyfikowałyby go do tej samej
grupy co klasyczne OS w rodzaju Linux, Solaris czy AIX. Odnajdzie się
tu podobne komponenty co i w innych systemach. W tym sensie JRockitVE
korzysta z tych samych doświadczeń co rozwijający jądro Linux'a czy
BSD. Czyli jest też oparty na podobnych założeniach co one, choć wiele
rzeczy trochę inaczej implementuje (podobnie jak i BSD implementuje
pewne rzeczy inaczej niż Linux).
Tyle tylko, że poczynione w JRockitVE założenia (opisane we
wcześniejszych postach) pozwalają ten "OS" z jednej strony UPROŚCIĆ, z
drugiej strony uczynić bardziej inteligentnym (ZOPTYMALIZOWANYM ?) pod
kątem serwerowych aplikacji JAVA.
W upraszczaniu wielką zasługę ma fakt, że JRockitVE jest przeznaczony
do działania wewnątrz maszyny wirtualnej udostępnionej przez
hypervisor (tu: jest OracleVM bazujący na Xen). Poprę tę tezę bardziej
praktycznie. Niedawno (7.maja 2009) robiłem prezentację na notabene
świetnej konferencji GeeCon 2009 w Krakowie i moje pierwsze demo
polegało na... zbudowaniu w pełni działającego jądra systemu
operacyjnego (ultra małego, ale jednak działającego jądra). Chodziło o
pokazanie jak wiele "spraw" jest w tym zadaniu budowy systemu
operacyjnego upraszczane przez hypervisor. Ten ultra mały OS
działający pod hypervisorem OracleVM miał efektywnie (czyli bez
komentarzy, itd) ok. 10 linii kodu w C i asemblerze x86 (tak, słownie:
"około DZIESIĘĆ linii kodu"). Coś takiego jak:
//----- plik: kernel.c -------
#include <stdint.h>
#include <xen.h>
#include "debug.h"
/* Some static space for the stack */
char stack[8192];
/* Main kernel entry point, called by trampoline */
void start_kernel(start_info_t * start_info)
{
HYPERVISOR_console_io(CONSOLEIO_write,12,"Hello World\n");
while(1);
}
//------ plik: debug.h -------
#include <stdint.h>
#include <xen.h>
#define __STR(x) #x
#define STR(x) __STR(x)
#define _hypercall3(type, name, a1, a2, a3) \
({ \
long __res, __ign1, __ign2, __ign3; \
__asm volatile ( \
"call hypercall_page + ("STR(__HYPERVISOR_##name)" * 32)"\
: "=a" (__res), "=b" (__ign1), "=c" (__ign2), \
"=d" (__ign3) \
: "1" ((long)(a1)), "2" ((long)(a2)), \
"3" ((long)(a3)) \
: "memory" ); \
(type)__res; \
})
static inline int
HYPERVISOR_console_io(
int cmd, int count, char *str)
{
return _hypercall3(int, console_io, cmd, count, str);
}
Demo obejmowało skompilowanie tego ultra-małego jądra OS i
uruchomienie nowej instancji (domeny) OracleVM. Mimo, że napis "Hello
World" się nie wyświetla (bo trzeba dopisać 20-30 linii kodu do
obsługi konsoli tekstowej, co zresztą też pokazałem w drugiej części
tego demo), to jest to w pełni działający "OS" (to powinien być duuuży
cudzysłów wokół tego OS ;-).
Kod, który pokazałem nie jest mój - pochodzi ze świetnej książki
David'a Chisnall's "The Definitive Guide to the Xen
Hypervisor" (Prentice Hall). Ja w każdym razie odpadłem czytając tę
książkę, gdy zobaczyłem te przykłady... Są do ściągnięcia,
samodzielnego skompilowania i uruchomienia z:
http://www.informit.com/store/product.aspx?isbn=9780132349710.
Upowszechnienie się wirtualizacji i hypervisorów bardzo ułatwia
pisanie "specjalizowanych" OS...
Zmierzam do tego, że owszem JRockitVE ma inną implementację niż Linux/
BSD, ale nie jest egzotycznym OS. Nie jest ambicją deweloperów
JRockitVE odróżniać się od Linux-a :-).
Jeśli innowacja w świecie OS-ów będzie miała sens w JRockitVE, to
będzie użyta...
Zobaczymy jak będzie, ale specjalnych braków pomiędzy zwirtualizowanym
OS-em (np. Linux'em na Xen) a JRockitVE nie widać...
Pozdrawiam,
Waldek Kot
PS
Postaram się za jakiś czas pokrótce opisać na moim blogu (http://
jdn.pl/blog/88) przykłady które pokazywałem. M.in. ten z książki
Chisnall'a z uruchomieniem tego ultra małego "jądra OS"
wyświetlającego "Hello World" na OracleVM...
Waldek Kot
> > Przykładów podobnych podejść można też szukać w świecie hypervisorów -
> > Xen, a szczególnie VMware ESX to specjalizowane OS pomyślane wyłącznie
> > pod kątem uruchamiania maszyn wirtualnych. Nie nadają się do niczego
> > innego, ale w swoim zadaniu wszystko inne przewyższają... Ludzie
> > piszący VMware ESX stworzyli swoją namiastkę OS, zamiast poprzykrajać
> > jakąś dystrybucję Linux-a...
>
> korzystniejszego dla ogółu, za to mniej korzystnego dla nich...
Eee - Twoja wypowiedź trochę brzmi jak spiskowa teoria korporacji...
Nie znam szczegółów wyboru inżynierów VMware (notabene założyciele
VMware, choć już tam niepracujący, to naukowcy ze Stanford), ale
myślę, że powód był jednak techniczny i taki jak podałem - zadania
które ma wykonywać taki "OS" jakim jest hypervisor typu VMware ESX, są
na tyle inne, że warto było zrobić specjalizowaną wersję zamiast
naginać do tego celu choćby i Linux'a (zresztą - oparcie się o już
istniejący i porządny kawał softu, jakim jest Linux, byłoby dla nich
tańsze, a NIE zrobili tego).
Zamiast VMware, podam zresztą inny, mniej "firmowy", przykład
hypervisor'a typu bare metal, który jest specjalizowanym "OS-em": Xen
(http://xen.org/). Poza sterownikami, Xen z jądrem Linux'a ma niewiele
wspólnego (i podkreślam, że to w żaden sposób NIE dyskredytuje jądra
Linux'a). Inne zarządzanie pamięcią, inny scheduler, itd.
Pozdrawiam,
Waldek Kot
Waldek Kot
> > Trochę wykraczamy poza technologię, ale już pierwsza, praktycznie
> > nieoptymalizowana pod kątem wydajności wersja VE dawała wydajność taką
> > samą, jak wirtualizowanego OS opartego o Linux. W większości testów
> > wewnętrznych niemal już regularnie wydajność jest lepsza od fizycznego
> > Linux-a (oczywiście chodzi o porównanie: JVM/VE vs. JVM/wirtualny-
> > Linux vs. JVM/fizyczny-Linux). Ale wszyscy tu głęboko wierzą w
> > pokazanie światu znacznie, znacznie lepszych wyników (choć jak
> > wyczytuję między liniami Twoich Wojtku wypowiedzi - już osiągnięcie
> > niegorszej wydajności niż klasyczny OS to będzie duża
> > niespodzianka ;-)...
>
> rezultatów, natomiast mniejszej wygody używania, mniejszej różnorodności
> obsługiwanych urządzeń itp.
Liczę tylko, że dostrzegłeś w mojej wypowiedzi, że pisząc "niegorsza
wydajność" odnosiłem się do FIZYCZNEGO Linux'a czyli zainstalowanego
"bare metal", BEZ hypervisora (zresztą, czy to był Linux, Solaris, czy
HPUX, to większego znaczenia nie ma - chodzi o to, że bez większych
trudów udało się zniwelować narzut wynikający z samej wirtualizacji).
Narzut, który zresztą też zanika, bo coraz więcej jest wsparcia dla
wirtualizacji w sprzęcie (CPU, chipset'ach, czy I/O), np. VT-x, czy VT-
d...
> > Ciężko to udowodnić, ale szacunki są takie, że "odzyskiwane" jest ok.
> > 30% czasu CPU. Opisany wcześniej model zarządzania pamięcią wirtualną
> > (wirtualną) też działa ok. 40% szybciej.
>
> Prawdopodobnie w jakichś szczególnych przypadkach.
> Z resztą, nawet jeśli przyspieszymy zarządzanie pamięcią, które będzie
> zajmować - przykładowo - 0.1% czasu procesora, to przyrost wydajności
> będzie trudny do zauważenia.
Nie, to było normalne działanie tych funkcji. Wydajność zarządzania
pamięcią czy scheduling wątków to są dosyć krytyczne sprawy dla
ogólnej wydajności...
Z tą częścią Twojej wypowiedzi która dotyczy "teorii optymalizacji"
oczywiście się zgadzam - ten Amdahl to miał jednak rację z tym swoim
prawem ;-)
Pozdrawiam,
Waldek Kot
Waldek Kot
> >> > Powtarzam się, ale popatrz zresztą na konsole do gier (np. XBox) - i
> >> > zobacz jakie przyspieszenie daje zdjęcie wieloprocesowości i kontroli
> >> > security z OS.
>
> >> A jest zdjęte?
>
> > Owszem, jest zdjęte - nie ma informacji z MS, ale z tego co przekazują
> > hackerzy OS w XBox-ie, to jądro XBox OS pochodzi z czasów Windows
> > 2000, z tym, że m.in. jest single-process, single-user. Wracając do
> > zysku z takiej wydajności, to inaczej nie da się wytłumaczyć różnicy w
> > bazuje na PowerPC), tyle, że to PC sprzed 3 lat...
>
> Z grafiką to w ogóle jest trochę trudności, zupełnie innych niż w programach
> serwerowych. Np. zlecenie czegoś GPU i zareagowanie na przerwanie, gdy GPU
> zakończy; albo wykorzystanie DMA.
> Raczej tu bym się dopatrywał trudności w zrobieniu optymalnego programu w
> userspace.
OK, chyba trochę źle się wyraziłem - mówiąc o "grafice" miałem raczej
na myśli niesubiektywny "wygląd" gier na XBox (jakość grafiki,
rozdzielczość, framerate, itd) w stosunku do tych samych gier na PC-
tach o porównywalnym do XBox sprzęcie. Jednym z czynników dzięki
którym ten sam sprzęt jest w stanie "wyrabiać" się lepiej na XBox jest
to, że OS w XBox-ie jest single-process, single-user - i w dodatku
jeszcze wszystko, czyli aplikacja (tu: gra) i OS działa w trybie
kernel. Dzięki temu wyeliminowali konieczność wykonywania kosztownych
przejść między trybami user- i kernel- space systemu operacyjnego. Te
przejścia są niezbędne w OS-ie dla normalnych celów, ale w OS-ie w
konsoli dla gier są zbędne, bo:
- jedyną aplikacją która działa jest gra
- wywalenie się gry (np. z powodu bug'u) spowoduje crash całej konsoli
(co tu nie jest specjalnie bolesne - konsola się zrestartuje w 5
sekund i już... - w OS-ie dla normalnych celów, wiadomo - nikt już
chyba nie chce wracać do czasów Windows 3.1/95 :-)
Podobnie jest z brakiem obsługi wielu użytkowników w XBox OS - od
konsoli nikt tego nie oczekuje.
JRockitVE z podobnych powodów jest single-user, single process.
Większość spraw security obsługuje JVM (i uruchomione w niej
oprogramowanie - dla serwerowych aplikacji Java będzie to zwłaszcza
serwer aplikacyjny - te warstwy security są bardzo mocne i ne ma sensu
ich duplikować).
Single-process, bo JEDYNĄ aplikacją (procesem) który JRockitVE
obsługuje jest JVM. Dzięki temu można uniknąć (lub drastycznie
zredukować) liczbę przełączeń między trybem kernel-user (tu są to
tryby wirtualnej maszyny udostępnianej przez hypervisor - virtual
guest kernel/user space). A wiadomo, że - mimo wsparcia tego
przełączania przez współczesne procesory - jest to dosyć kosztowna
operacja - nawet na najnowszych CPU kosztuje setki cykli procesora i
jest 30-50 razy wolniejsza niż zwykłe wywołanie... A takich przełączeń
na systemie wielo-procesowym jest bardzo wiele... Skoro i tak ZAWSZE
będzie działać tylko jedna aplikacja (=JVM), to warto ten zbędny
balast zdjąć ("zbędny balast" TUTAJ =DLA APLIKACJI JAVA, nie mylić ze:
"zbędny balast" w ogóle).
Inaczej jednak niż w przypadku XBox, JRockitVE działa w userspace,
czyli ma znacznie mniejsze uprawnienia wewnątrz wirtualnej maszyny
(=guest'a) - dotyczy to zarówno aplikacji (tu: JVM), jak i samego
"OS" (tu: JRockitVE). Czyli wciąż to co daje hypervisor (czyli obsługę
maszyn wirtualnych) w zakresie ochrony i poziomu uprawnień jest
zachowywane (i na poziomie JVM, i - w stosunku do XBOX - dodatkowo na
poziomie "OS").
Pozdrawiam,
Waldek Kot
Michal Kleczek
[ciach]
>
Ta dyskusja juz sie na tej grupie odbyla, ale mozna w sumie bez konca...
> JRockitVE z podobnych powodów jest single-user, single process.
> Większość spraw security obsługuje JVM (i uruchomione w niej
> oprogramowanie - dla serwerowych aplikacji Java będzie to zwłaszcza
> serwer aplikacyjny - te warstwy security są bardzo mocne i ne ma sensu
> ich duplikować).
> Single-process, bo JEDYNĄ aplikacją (procesem) który JRockitVE
> obsługuje jest JVM. Dzięki temu można uniknąć (lub drastycznie
> zredukować) liczbę przełączeń między trybem kernel-user (tu są to
> tryby wirtualnej maszyny udostępnianej przez hypervisor - virtual
> guest kernel/user space). A wiadomo, że - mimo wsparcia tego
> przełączania przez współczesne procesory - jest to dosyć kosztowna
> operacja - nawet na najnowszych CPU kosztuje setki cykli procesora i
> jest 30-50 razy wolniejsza niż zwykłe wywołanie... A takich przełączeń
> na systemie wielo-procesowym jest bardzo wiele... Skoro i tak ZAWSZE
> będzie działać tylko jedna aplikacja (=JVM), to warto ten zbędny
> balast zdjąć ("zbędny balast" TUTAJ =DLA APLIKACJI JAVA, nie mylić ze:
> "zbędny balast" w ogóle).
Sek w tym, ze stwierdzenie, ze JRockitVE jest "single-user, single process"
jest naduzyciem, bo VM oczywiscie obsluguje wielu uzytkownikow i jest
wielozadaniowa - czyli spelnia (w tym wzgledzie) funkcje systemu
operacyjnego. Tyle tylko, ze znacznie gorzej niz przecietny Unix lub
Windows bo nie pozwala uruchamiac wielu niezaleznych aplikacji - na
przyklad nie jest w stanie obsluzyc dwoch serwerow aplikacyjnych na raz. Co
gorsza - nie jest nawet w stanie dobrze obsluzyc dwoch niezaleznych
aplikacji J2EE w ramach jednego serwera aplikacyjnego (dobrze to
przynajmniej tak, ze jak np. jedna aplikacja sie zawiesi to mozna ja
przerwac bez wplywu na druga aplikacje). Czyli defacto to, co uzyskujemy to
mozliwosc uruchomienia JEDNEJ aplikacji Java (w domysle J2EE). Tylko po co
to komu? A gdzie RDBMS, gdzie serwer SMTP, gdzie - dajmy nato - LDAP, juz
nie mowiac o takich tam pierdolach jak serwery ftp, ssh itd. Czyzbysmy
musieli uruchamiac tyle maszyn wirtualnych (w sensie wirtualizacji) ile
mamy aplikacji do uruchomienia? WTF?
--
Michal
Waldek Kot
> Ta dyskusja juz sie na tej grupie odbyla, ale mozna w sumie bez konca...
Tak, zdecydowana większość z nas przychodzi tu po to, aby pogawędzić o
Javie i różnych jej aspektach. Bo lubimy.
> Sek w tym, ze stwierdzenie, ze JRockitVE jest "single-user, single process"
> jest naduzyciem, bo VM oczywiscie obsluguje wielu uzytkownikow i jest
> wielozadaniowa - czyli spelnia (w tym wzgledzie) funkcje systemu
> operacyjnego.
"Jest nadużyciem" ??? Hmm....
W każdym razie, jest to precyzyjne sformułowanie. W ramach tego "a'la
OS" działa zawsze tylko jeden proces systemu operacyjnego (czyli JVM),
więc jest "single proces". Podobnie, w tym "OS-ie" jest zdefiniowany
tylko jeden użytkownik (i inni być nie mogą), więc jest "single-user".
Nadużycia nie ma.
A to, że warstwa powyżej (czyli JVM) może korzystać z wielu
(wirtualnych) procesorów, uruchamiać wiele wątków i w ten sposób
realizować wielozadaniowość tylko potwierdza, że dla serwerowych
aplikacji Java klasyczny system operacyjny jest zbędny. Podobnie z
obsługą wielu użytkowników, grup, ról i całym podsystemem security.
JVM (zwykle wraz z serwerem aplikacyjnym) dają w tym zakresie wszystko
to czego aplikacje Java potrzebują. Bez klasycznego OS-a.
> Tyle tylko, ze znacznie gorzej niz przecietny Unix lub
> Windows bo nie pozwala uruchamiac wielu niezaleznych aplikacji - na
> przyklad nie jest w stanie obsluzyc dwoch serwerow aplikacyjnych na raz.
Tak, JRockitVE robi to gorzej dla wszystkich pozostałych przypadków
poza jednym - gdy chodzi o obsługę serwerowych aplikacji JAVA, np.
serwera aplikacyjnego Java EE i znajdujących się w nim aplikacji.
Przypadek który opisujesz, czyli obsługi dwóch serwerów aplikacyjnych
na raz nie robi żadna znana mi JVM (i na tym poziomie - czyli JVM -
jest to ograniczenie). A przynajmniej żadna JVM stosowana w praktyce
(choć wiadomo, że takie próby podejmowano, np. w JVM SAP. Jest też w
tym zakresie trochę bardzo ciekawych prac naukowych, m.in. Grzegorza
Czajkowskiego, także nt. Java Application Isolation, np. JSR-121. Ale
póki co pomysł się raczej nie przyjął, przynajmniej dla
mainstream'owej Java, np. aplikacji webowych).
Ten przytoczony przez Ciebie brak nie jest zresztą jakoś szczególnie
bolesny, bo warto zauważyć, że mówimy o WIRTUALIZACJI, czyli w ramach
fizycznego serwera można uruchamiać dodatkowe maszyny wirtualne. Z
tym, że zamiast w każdej z tych maszyn wirtualnych uruchamiać pełny,
zajmujący sporo zasobów, klasyczny system operacyjny, a wnim znowu JVM
(+ ewentualnie middleware) + aplikacje, to bardziej efektywnie jest w
takiej maszynie wirtualnej uruchomić znacznie odchudzony stos:
JRockitVE (= "a'la OS") + JVM (+ ew. middleware) + aplikacje.
> Co gorsza - nie jest nawet w stanie dobrze obsluzyc dwoch niezaleznych
> aplikacji J2EE w ramach jednego serwera aplikacyjnego (dobrze to
> przynajmniej tak, ze jak np. jedna aplikacja sie zawiesi to mozna ja
> przerwac bez wplywu na druga aplikacje).
Daj spokój - serwery aplikacyjne dosyć dobrze izolują uruchomione
wewnątrz nich aplikacje. Przynajmniej na tyle, że działa na nich
dziesiątki tysięcy produkcyjnych aplikacji od paru ładny lat. Raczej
trzeba się mocno postarać, żeby do takiej sytuacji jak ta, którą
opisałeś doprowadzić. Stosując się do ogólnych zaleceń Java i Java EE
łatwo tego uniknąć. Mimo tego, że technicznie, to oczywiście serwer
aplikacyjny, czyli z punktu widzenia systemu operacyjnego - proces,
obsługuje aplikacje z użyciem wątków, których poziom izolacji JEST
mniejszy niż między procesami. Taki przyjęto (powszechnie !)
kompromis, bo inaczej nie udałoby się osiągnąć takiego poziomu
wydajności, a przede wszystkim skalowalności...
Jeśli potrzeba większej izolacji, to znowu - masz możliwość
uruchomienia poszczególnych aplikacji w oddzielnych maszynach
wirtualnych. Tu, poziom izolacji, w chyba każdej dzisiaj stosowanej
implementacji hypervisora, jest większy niż ten pomiędzy procesami w
ramach jednego systemu operacyjnego.
> Czyli defacto to, co uzyskujemy to
> mozliwosc uruchomienia JEDNEJ aplikacji Java (w domysle J2EE).
??? Rozumiem, że podważasz sens używania serwerów aplikacyjnych. No
comments...
> Tylko po co to komu? A gdzie RDBMS, gdzie serwer SMTP, gdzie - dajmy nato - LDAP, juz
> nie mowiac o takich tam pierdolach jak serwery ftp, ssh itd.
Nic nie stoi na przeszkodzie, aby wciąż ich używał. Tyle, że nie na
JEDNYM systemie operacyjnym, tylko na oddzielnych (a przynajmniej
korzystające z nich aplikacje Java na oddzielnej niż one maszynie -
wirtualnej bądź fizycznej). Sytuacja w której oddziela się RDBMS,
LDAP, serwer poczty, itd. od aplikacji jest REGUŁĄ w PRODUKCYJNYCH
systemach serwerowych (w tym opartych o Java EE). W przypadku
wirtualizacji, koszt tego jest nawet niższy, bo maszyna wirtualna
zawierająca np. RDBMS może (choć nie musi) działać na tym samym
fizycznym serwerze....
Jeśli pytasz o FTP i SSH, czyli uogólniając o to, czy z takim "a'la"
OS jak JRockitVE można się skomunikować "z zewnątrz", to oczywiście
tak, jest taka możliwość. Można w nim uruchomić wątek SSH, można
dostać się do jego filesystemu z zewnątrz, itd. Zarówno w trybie
online (czyli gdy maszyna wirtualna działa), jak i w trybie offline
(czyli manipulować zawartością pliku-obrazu maszyny wirtualnej).
> Czyzbysmy
> musieli uruchamiac tyle maszyn wirtualnych (w sensie wirtualizacji) ile
> mamy aplikacji do uruchomienia?
Jeśli pisząc "aplikacje" masz na myśli "serwer aplikacyjny, RDBMS,
LDAP, itd." to tak (nawet pomijając, że tak jak napisałem jest regułą
w produkcyjnych systemach oddzielać od siebie poszczególne komponenty
systemu, np. RDBMS, czy LDAP od aplikacji). Jeśli natomiast przez
"aplikacje" rozumiesz "aplikacje Java / Java EE", to niekoniecznie -
masz wybór (taki sam jak dzisiaj) co do topologii systemu Java EE.
Możesz mieć skrajności:
- jedną maszynę (guest), w której jest JVM, serwer aplikacyjny i JEDNA
aplikacja Java EE
- jedną maszynę (guest), w której jest JVM, serwer aplikacyjny i WIELE
aplikacji Java EE
oraz wszystkie warianty pośrednie.
Czyli TAK SAMO jak dzisiaj, z tym, że ZAMIAST maszyn fizycznych są
wirtualne.
Taki jest sens wirtualizacji i nie jest to w jej kontekście nic
szczególnego. Taki jest też główny sens JRockitVE, żeby ustanowienie
maszyny wirtualnej zawierającej JVM z aplikacjami serwerowymi Java
było jak najbardziej efektywne (czytaj: maszyna wirtualna była jak
"najchudsza", pozbawiona zbędnego tu balastu, czyli m.in. klasycznego
OS).
> WTF?
Yes, if you meant: _W_łaśnie ! _T_o _F_antastycznie !
;-)
Pozdrawiam,
Waldek Kot
Michal Kleczek
> On May 11, 9:11 pm, Michal Kleczek <klek...@gmail.com> wrote:
>> Ta dyskusja juz sie na tej grupie odbyla, ale mozna w sumie bez konca...
>
> Tak, zdecydowana większość z nas przychodzi tu po to, aby pogawędzić o
> Javie i różnych jej aspektach. Bo lubimy.
>
>
>> Sek w tym, ze stwierdzenie, ze JRockitVE jest "single-user, single
>> process" jest naduzyciem, bo VM oczywiscie obsluguje wielu uzytkownikow i
>> jest wielozadaniowa - czyli spelnia (w tym wzgledzie) funkcje systemu
>> operacyjnego.
>
> "Jest nadużyciem" ??? Hmm....
>
> W każdym razie, jest to precyzyjne sformułowanie. W ramach tego "a'la
> OS" działa zawsze tylko jeden proces systemu operacyjnego (czyli JVM),
> więc jest "single proces". Podobnie, w tym "OS-ie" jest zdefiniowany
> tylko jeden użytkownik (i inni być nie mogą), więc jest "single-user".
> Nadużycia nie ma.
> A to, że warstwa powyżej (czyli JVM) może korzystać z wielu
> (wirtualnych) procesorów, uruchamiać wiele wątków i w ten sposób
> realizować wielozadaniowość tylko potwierdza, że dla serwerowych
> aplikacji Java klasyczny system operacyjny jest zbędny. Podobnie z
> obsługą wielu użytkowników, grup, ról i całym podsystemem security.
> JVM (zwykle wraz z serwerem aplikacyjnym) dają w tym zakresie wszystko
> to czego aplikacje Java potrzebują. Bez klasycznego OS-a.
Prosze - zdefiniuj "klasyczny OS". Dla mnie JRockitVE to _JEST_ klasyczny
OS - tyle ze badziewny, bo:
1. pozwala uruchamiac tylko aplikacje Java
2. nie zapewnia wystarczajacej izolacji uruchamianych w nim aplikacji
>
>> Tyle tylko, ze znacznie gorzej niz przecietny Unix lub
>> Windows bo nie pozwala uruchamiac wielu niezaleznych aplikacji - na
>> przyklad nie jest w stanie obsluzyc dwoch serwerow aplikacyjnych na raz.
>
> Tak, JRockitVE robi to gorzej dla wszystkich pozostałych przypadków
> poza jednym - gdy chodzi o obsługę serwerowych aplikacji JAVA, np.
> serwera aplikacyjnego Java EE i znajdujących się w nim aplikacji.
>
> Przypadek który opisujesz, czyli obsługi dwóch serwerów aplikacyjnych
> na raz nie robi żadna znana mi JVM (i na tym poziomie - czyli JVM -
> jest to ograniczenie). A przynajmniej żadna JVM stosowana w praktyce
> (choć wiadomo, że takie próby podejmowano, np. w JVM SAP. Jest też w
> tym zakresie trochę bardzo ciekawych prac naukowych, m.in. Grzegorza
> Czajkowskiego, także nt. Java Application Isolation, np. JSR-121. Ale
> póki co pomysł się raczej nie przyjął, przynajmniej dla
> mainstream'owej Java, np. aplikacji webowych).
> Ten przytoczony przez Ciebie brak nie jest zresztą jakoś szczególnie
> bolesny, bo warto zauważyć, że mówimy o WIRTUALIZACJI, czyli w ramach
> fizycznego serwera można uruchamiać dodatkowe maszyny wirtualne. Z
> tym, że zamiast w każdej z tych maszyn wirtualnych uruchamiać pełny,
> zajmujący sporo zasobów, klasyczny system operacyjny, a wnim znowu JVM
> (+ ewentualnie middleware) + aplikacje, to bardziej efektywnie jest w
> takiej maszynie wirtualnej uruchomić znacznie odchudzony stos:
> JRockitVE (= "a'la OS") + JVM (+ ew. middleware) + aplikacje.
Znacznie bardziej efektywnie jest na jednym fizycznym serwerze zainstalowac
dobry "klasyczny OS" i uruchamiac na nim cokolwiek dusza zapragnie. Po to
wlasnie wymyslono OS.
>
>> Co gorsza - nie jest nawet w stanie dobrze obsluzyc dwoch niezaleznych
>> aplikacji J2EE w ramach jednego serwera aplikacyjnego (dobrze to
>> przynajmniej tak, ze jak np. jedna aplikacja sie zawiesi to mozna ja
>> przerwac bez wplywu na druga aplikacje).
>
> Daj spokój - serwery aplikacyjne dosyć dobrze izolują uruchomione
> wewnątrz nich aplikacje. Przynajmniej na tyle, że działa na nich
> dziesiątki tysięcy produkcyjnych aplikacji od paru ładny lat. Raczej
> trzeba się mocno postarać, żeby do takiej sytuacji jak ta, którą
> opisałeś doprowadzić. Stosując się do ogólnych zaleceń Java i Java EE
> łatwo tego uniknąć.
Nie sadze, zeby w niebananlnych systemach latwo bylo uniknac nieskonczonych
petli i memory leakow. To pierwsze jest niemozliwe nawet teoretycznie.
> Mimo tego, że technicznie, to oczywiście serwer
> aplikacyjny, czyli z punktu widzenia systemu operacyjnego - proces,
Po pierwsze - niekoniecznie proces bo moze byc uruchomiony na OS w ktorym
nie istnieje pojecie procesu.
Po drugie - znam przynajmniej jeden serwer J2EE, ktory uruchamia wiele
procesow OS.
> obsługuje aplikacje z użyciem wątków, których poziom izolacji JEST
> mniejszy niż między procesami. Taki przyjęto (powszechnie !)
> kompromis, bo inaczej nie udałoby się osiągnąć takiego poziomu
> wydajności, a przede wszystkim skalowalności...
Bzdura. Jest wiele monitorow transakcyjnych zapewniajacych wysoki poziom
wydajnosci i skalowalnosci pomimo tego, ze poszczegolne aplikacje
dzialajace pod jego kontrola sa uruchamiane w oddzielnych procesach. Zeby
daleko nie szukac to chociazby Ms Transaction Server lub Tuxedo.
>
> Jeśli potrzeba większej izolacji, to znowu - masz możliwość
> uruchomienia poszczególnych aplikacji w oddzielnych maszynach
> wirtualnych. Tu, poziom izolacji, w chyba każdej dzisiaj stosowanej
> implementacji hypervisora, jest większy niż ten pomiędzy procesami w
> ramach jednego systemu operacyjnego.
A ile takich maszyn wirtualnych mozna odpalic na jednym fizycznym serwerze i
jak ta liczba ma sie do mozliwej ilosci uruchomionych programow w ramach
systemu operacyjnego dzialajacego na tym samym sprzecie?
>
>> Czyli defacto to, co uzyskujemy to
>> mozliwosc uruchomienia JEDNEJ aplikacji Java (w domysle J2EE).
>
> ??? Rozumiem, że podważasz sens używania serwerów aplikacyjnych. No
> comments...
Alez skad. Podwazam tylko sens stosowania serwerow aplikacyjnych w
zastepstwie systemow operacyjnych.
>
>> Tylko po co to komu? A gdzie RDBMS, gdzie serwer SMTP, gdzie - dajmy nato
>> - LDAP, juz nie mowiac o takich tam pierdolach jak serwery ftp, ssh itd.
>
> Nic nie stoi na przeszkodzie, aby wciąż ich używał. Tyle, że nie na
> JEDNYM systemie operacyjnym, tylko na oddzielnych (a przynajmniej
> korzystające z nich aplikacje Java na oddzielnej niż one maszynie -
> wirtualnej bądź fizycznej). Sytuacja w której oddziela się RDBMS,
> LDAP, serwer poczty, itd. od aplikacji jest REGUŁĄ w PRODUKCYJNYCH
> systemach serwerowych (w tym opartych o Java EE).
Jest bardzo roznie - czasem jest lepiej miec poszczegolne komponenty
odizolowane, czasem nie. Szczegolnie, ze w mocno obciazanych systemach
czesto stosuje sie zasade dokladnie odwrotna: przetwarzanie danych blisko
danych. Innymi slowy np. program (lub jego fragment) przetwarzajacy dane z
RDBMS uruchamia sie na tym samym komputerze, co RDBMS. Zas skalowalnosc
osiaga sie poprzez partycjonowanie danych - znowu zeby daleko nie szukac -
patrz GigaSpaces lub map-reduce Google'a.
> W przypadku
> wirtualizacji, koszt tego jest nawet niższy, bo maszyna wirtualna
> zawierająca np. RDBMS może (choć nie musi) działać na tym samym
> fizycznym serwerze....
Tyle tylko, ze izolacja _aplikacji_ przy pomocy hypervisora i przy
pomocy "klasycznego OS" specjalnie sie nie rozni. Prawdziwa izolacja to
izolacja _fizyczna_ a nie wirtualna.
>
> Jeśli pytasz o FTP i SSH, czyli uogólniając o to, czy z takim "a'la"
> OS jak JRockitVE można się skomunikować "z zewnątrz", to oczywiście
> tak, jest taka możliwość. Można w nim uruchomić wątek SSH, można
> dostać się do jego filesystemu z zewnątrz, itd. Zarówno w trybie
> online (czyli gdy maszyna wirtualna działa), jak i w trybie offline
> (czyli manipulować zawartością pliku-obrazu maszyny wirtualnej).
?? jak mozna sie komunikowac z programem ktory nie dziala. Rozumiem, ze to
skrot myslowy i komunikujesz sie z _innym_ programem.
>
>> Czyzbysmy
>> musieli uruchamiac tyle maszyn wirtualnych (w sensie wirtualizacji) ile
>> mamy aplikacji do uruchomienia?
>
> Jeśli pisząc "aplikacje" masz na myśli "serwer aplikacyjny, RDBMS,
> LDAP, itd." to tak (nawet pomijając, że tak jak napisałem jest regułą
> w produkcyjnych systemach oddzielać od siebie poszczególne komponenty
> systemu, np. RDBMS, czy LDAP od aplikacji). Jeśli natomiast przez
> "aplikacje" rozumiesz "aplikacje Java / Java EE", to niekoniecznie -
> masz wybór (taki sam jak dzisiaj) co do topologii systemu Java EE.
> Możesz mieć skrajności:
> - jedną maszynę (guest), w której jest JVM, serwer aplikacyjny i JEDNA
> aplikacja Java EE
> - jedną maszynę (guest), w której jest JVM, serwer aplikacyjny i WIELE
> aplikacji Java EE
Niestety JVM tylko teoretycznie to umozliwia. W praktyce - nie. Juz zbyt
wiele razy spotkalem sie z potrzeba restartu JVM z WLSem, zeby wierzyc, ze
to dziala.
> oraz wszystkie warianty pośrednie.
>
> Czyli TAK SAMO jak dzisiaj, z tym, że ZAMIAST maszyn fizycznych są
> wirtualne.
Nie tak samo. Wyobraz sobie, ze na swiecie bardzo duzo ludzi nadal stosuje
prosta zasade - jeden mocny komputer + dobry OS + tyle aplikacji ile jest w
danej chwili wymagane. Jezeli jest potrzebna izolacja poszczegolnych czesci
systemu ze wzgledu na bezpieczenstwo, to stawia sie wiele _fizycznych_
maszyn (izolacja przy pomocy jakiegos oprogramowania do wirtualizacji nie
przejdzie pierwszego lepszego audytu bezpieki - chyba, ze to oprogramowanie
ma certyfikaty odpowiedniego poziomu - ja do tej pory spotkalem sie z
jednym takim przypadkiem - produktem HP posiadajacym certyfikat bodajze A2)
I to jest najczesciej _najtansze_ rozwiazanie.
>
> Taki jest sens wirtualizacji i nie jest to w jej kontekście nic
> szczególnego. Taki jest też główny sens JRockitVE, żeby ustanowienie
> maszyny wirtualnej zawierającej JVM z aplikacjami serwerowymi Java
> było jak najbardziej efektywne (czytaj: maszyna wirtualna była jak
> "najchudsza", pozbawiona zbędnego tu balastu, czyli m.in. klasycznego
> OS).
Tyle, ze bez tego tzw. "balastu" JVM jest bezuzyteczna :-) - gdzies w koncu
ta reszta (RDBMS, LDAP, filesystem itd itp) musi dzialac.
--
Michal
Filip Sielimowicz
Użytkownik "Michal Kleczek" <kle...@gmail.com> napisał w wiadomości
news:gubegq$hf9$1...@mx1.internetia.pl...
> Nie sadze, zeby w niebananlnych systemach latwo bylo uniknac
> nieskonczonych
> petli i memory leakow. To pierwsze jest niemozliwe nawet teoretycznie.
Mam wrażenie, że się zaczynamy ostro rozbiegać w tematach i porównaniach
;)))
O co biega z tą teoretyczną niemożliwoscią unikania nieskończonych pętli ?
:)))
Że za czym to ma przemawiać, argumentować ? :)))
Michal Kleczek
O to, ze w normalnym OSie jakis program wpadnie w nieskonczona petle, to go
ubijasz. Innych programow to nie obchodzi.
W serwerze J2EE (dzialajacym w ramach jednej JVM) jak masz dwie aplikacje
J2EE i jedna z nich zwisnie, to lezysz i kwiczysz, bo musisz zrobic restart
calego serwera.
--
Michal
Waldek Kot
> Prosze - zdefiniuj "klasyczny OS". Dla mnie JRockitVE to _JEST_ klasyczny
> OS - tyle ze badziewny, bo:
> 1. pozwala uruchamiac tylko aplikacje Java
> 2. nie zapewnia wystarczajacej izolacji uruchamianych w nim aplikacji
No proszę... A napisałeś, że dyskusja się już na ten temat odbyła...
"Klasyczny OS" czyli generyczny, tj. taki, w którym można uruchamiać
dowolne aplikacje. Przykłady: Windows, popularne dystrybucje linuksowe
(np. RedHat Linux), Solaris, AIX, itd.
Tak jak napisałem, pomysł z takim "OS-em" (ciągle podkreślam ten
cudzysłów wokół OS) jak JRockitVE polega na tym, że jest
specjalizowany, od początku do końca pomyślany z myślą o uruchamianiu
serwerowych aplikacji Java w środowisku wirtualnym (maszynie
wirtualnej udostępnionej przez hypervisor). I tu zgoda - do NICZEGO
innego się nie nada. Bazy danych na tym się nie postawi (no, chyba, że
bazy danych napisanej w Java), na desktop-ie do pisania maili i gier
też nie... To, że tylko Java, to z jednej strony słabość, z drugiej
siła - każda specjalizacja ma taką charakterystykę...
Co do izolacji, to się nie zgodzę. Izolacja (aplikacji Java) w
JRockitVE jest w najgorszym razie taka sama jak w dzisiejszych JVM
(podkreślałem już też, że JVM działający na JRockitVE jest
niemodyfikowany, tj. identyczny z tym, który można uruchomić na
klasycznym OS). Biorąc też pod uwagę, że wirtualizacja oferuje lepszy
poziom izolacyjności niż to co oferują systemy operacyjne i JRockitVE
działa w środowisku zwirtualizowanym, to może być lepsza niż w
klasycznym OS...
> Znacznie bardziej efektywnie jest na jednym fizycznym serwerze zainstalowac
> dobry "klasyczny OS" i uruchamiac na nim cokolwiek dusza zapragnie. Po to
> wlasnie wymyslono OS.
OK, czyli tym razem chcesz zanegować sens wirtualizowania i
przydatności hypervisor'ów... Zalety i wady wirtualizacji są
powszechnie znane. Trend ku wirtualizacji jest jednak dosyć wyraźny i
raczej nie widać, aby cokolwiek miało się tu zmienić. Za chwilę będzie
trudno zobaczyć komputer (czy komórkę) bez wirtualizacji... Każdy
serwerowy system operacyjny dzisiaj w większym, bądź mniejszym stopniu
ma wsparcie dla wirtualizacji. Jądra Linux'a nawet mają wsparcie
(parawirtualizację) dla kilku hypervisor'ów (Xen, KVM)...
> > Daj spokój - serwery aplikacyjne dosyć dobrze izolują uruchomione
> > wewnątrz nich aplikacje. Przynajmniej na tyle, że działa na nich
> > dziesiątki tysięcy produkcyjnych aplikacji od paru ładny lat. Raczej
> > trzeba się mocno postarać, żeby do takiej sytuacji jak ta, którą
> > opisałeś doprowadzić. Stosując się do ogólnych zaleceń Java i Java EE
> > łatwo tego uniknąć.
>
> Nie sadze, zeby w niebananlnych systemach latwo bylo uniknac nieskonczonych
> petli i memory leakow. To pierwsze jest niemozliwe nawet teoretycznie.
Można uniknąć. Pomijam hackerskie sztuczki i wykorzystanie bug'ów (bug
to bug) - notabene od których żaden OS też nie jest wolny - to
trzymając się rekomendacji Java/JavaEE w serwerze aplikacyjnym Java EE
bardzo trudno jest zrobić to o czym piszesz. Jak napiszesz servlet,
czy EJB które ma nieskończoną pętlę, to serwer aplikacyjny wątek
obsługujący ten servlet czy EJB w końcu ubije. Jeśli serwer
aplikacyjny ma wbudowane mechanizmy Quality of Service, to możesz
skonfigurować, żeby taki servlet/wątek (o ile nie jest zawieszony) nie
dostał więcej niż określony kwant czasu procesora (lub odpowiedni
priorytet) - o to dba scheduler serwera aplikacyjnego. Daj spokój
Michał - nie muszę chyba Ci tłumaczyć, że GŁÓWNĄ rolą serwera
aplikacyjnego jest zarządzanie zasobami (CPU, pamięć, połączenia do
baz danych, itd). Mało się to różni od podobnego zadania, które robi
OS.
> > Mimo tego, że technicznie, to oczywiście serwer
> > aplikacyjny, czyli z punktu widzenia systemu operacyjnego - proces,
>
> Po pierwsze - niekoniecznie proces bo moze byc uruchomiony na OS w ktorym
> nie istnieje pojecie procesu.
A jaki to OS (i serwer aplikacyjny) ? Chyba jakiś bardzo
specjalizowany. No cóż, a przed chwilą "badziewiem" nazwałeś
JRockitVE, który jest hmm... specjalizowanym "OS-em" ???
> Po drugie - znam przynajmniej jeden serwer J2EE, ktory uruchamia wiele
> procesow OS.
A to ciekawe ? Co to za serwer aplikacyjny Java EE ? I czy mówimy o
tym samym ? Dla przykładu WebSphere przed wersją 5 też odpalał procesy
systemu operacyjnego do obsługi JMS (bo był używany kod MQSeries,
który nie działa na JVM), czym każdego rozsądnego inżyniera
doprowadzał do śmiechu. Od wersji 5 IBM poprawił architekturę i takich
"cudów" już nie robią. Ale obsługa żądań do aplikacji webowych, RMI,
itd. odbywa się z wykorzystaniem wątków. Technicznie więc (pomijając
to cudo z procesami MQ w WAS starszych niż wersja 5), to wciąż: 1 WAS,
to 1 proces.
> > obsługuje aplikacje z użyciem wątków, których poziom izolacji JEST
> > mniejszy niż między procesami. Taki przyjęto (powszechnie !)
> > kompromis, bo inaczej nie udałoby się osiągnąć takiego poziomu
> > wydajności, a przede wszystkim skalowalności...
>
> Bzdura. Jest wiele monitorow transakcyjnych zapewniajacych wysoki poziom
> wydajnosci i skalowalnosci pomimo tego, ze poszczegolne aplikacje
> dzialajace pod jego kontrola sa uruchamiane w oddzielnych procesach. Zeby
> daleko nie szukac to chociazby Ms Transaction Server lub Tuxedo.
Co do Tuxedo, to akurat wiesz, w budowie WebLogic Server'a
uczestniczyli Ci sami ludzie, którzy rozwijali Tuxedo przez
wcześniejsze 13 lat (i wciąż uczestniczą, Tux to już w sumie 23
lata).
Wiele koncepcji jest tu dosyć podobnych. Model skalowania w dużym
stopniu też. Jak popatrzysz na podsystem CORBA w Tuxedo, to jest on
BLIŹNIACZY w stosunku do tego co ma WLS (pewnie odwrotnie, bo
historycznie podsystem CORBA w Tuxedo, czyli dawny serwer M3, jest
starszy niż WebLogic Server). Nawet drugi model aplikacyjny w Tuxedo,
czyli ATMI, korzysta z wielowątkowości (i to bardzo mocno) i - na
pewno - nikt rozsądny nie zarekomenduje skalowania aplikacji Tuxedo
poprzez odpalanie bez opamiętania coraz to kolejnych procesów.
Obowiązują tu TE SAME limity zasobów systemu operacyjnego. Tak samo
jest z serwerami aplikacyjnymi Java EE. Na jednej maszynie możesz
odpalić kilka ich instancji (procesów systemu operacyjnego, w którym
działa JVM z serwerem aplikacyjnym). Nawet sklastrować te instancje.
Ale żeby skalować w ten sposób, to raczej nie - CGI reloaded ???
Wracając do izolacyjności - mam ogromny szacunek do Tuxedo (jakżeby
inaczej) - ale obowiązują tutaj te same reguły, czyli źle napisana
aplikacja uruchomiona w tej samej instancji Tuxedo może zakłócić
działanie innych. Nawet łatwiej tu o to, bo aplikacje w Tuxedo to
aplikacje systemowe (w C, czy COBOL-u) i mają większy poziom dostępu
do sprzętu.
Myślę, że zły przykład podałeś do swojej tezy...
> A ile takich maszyn wirtualnych mozna odpalic na jednym fizycznym serwerze i
> jak ta liczba ma sie do mozliwej ilosci uruchomionych programow w ramach
> systemu operacyjnego dzialajacego na tym samym sprzecie?
Najkrócej: to po prostu złe porównanie (przysłowiowych jabłek do
pomarańczy).
> > ??? Rozumiem, że podważasz sens używania serwerów aplikacyjnych. No
> > comments...
>
> Alez skad. Podwazam tylko sens stosowania serwerow aplikacyjnych w
> zastepstwie systemow operacyjnych.
Tak daleko żeby zastępować OS serwerem aplikacji, to nikt się nie
posunął. Ale z drugiej strony, 99.5% typowego systemu operacyjnego
jest w <<zwirtualizowanych serwerowych aplikacjach Java>> zbędne i
można się tego pozbyć. Czyli, dzięki hypervisor'om bardzo łatwo
zbudować specjalizowany OS, który lepiej będzie takie aplikacje
obsługiwał. Wsparcie tej tezy podałem we wcześniejszym poście,
prezentując przykład z książki Chisnall'a o Xen - działający "kernel"
OS który ma 10 linii kodu.
> >> Tylko po co to komu? A gdzie RDBMS, gdzie serwer SMTP, gdzie - dajmy nato
> >> - LDAP, juz nie mowiac o takich tam pierdolach jak serwery ftp, ssh itd.
>
> > Nic nie stoi na przeszkodzie, aby wciąż ich używał. Tyle, że nie na
> > JEDNYM systemie operacyjnym, tylko na oddzielnych (a przynajmniej
> > korzystające z nich aplikacje Java na oddzielnej niż one maszynie -
> > wirtualnej bądź fizycznej). Sytuacja w której oddziela się RDBMS,
> > LDAP, serwer poczty, itd. od aplikacji jest REGUŁĄ w PRODUKCYJNYCH
> > systemach serwerowych (w tym opartych o Java EE).
>
> Jest bardzo roznie - czasem jest lepiej miec poszczegolne komponenty
> odizolowane, czasem nie. Szczegolnie, ze w mocno obciazanych systemach
> czesto stosuje sie zasade dokladnie odwrotna: przetwarzanie danych blisko
> danych. Innymi slowy np. program (lub jego fragment) przetwarzajacy dane z
> RDBMS uruchamia sie na tym samym komputerze, co RDBMS. Zas skalowalnosc
> osiaga sie poprzez partycjonowanie danych - znowu zeby daleko nie szukac -
> patrz GigaSpaces lub map-reduce Google'a.
Słowo klucz tutaj to "czasem". Czasem lepiej przetransportować dane do
kodu, czasem kod rozdystybuować do źródeł/partycji danych.
W kontekście zwirtualizowanej Java, to niewiele zmienia, choć
wirtualizacja wnosi bardzo dużo elastyczności - bo oddziela od
fizycznego sprzętu. Łatwiej więc zarówno rozpraszać, jak i scalać -
można to robić nawet w trakcie pracy, na przykład dynamicznie migrować
wirtualne maszyny pomiędzy fizycznymi - nie ma problemu aby odbywało
się to w sposób niezauważalny dla użytkowniak takiej maszyny, a także
w sposób, który uwzględni aktualne obciążenie. Pewnie doczekamy się
już niedługo wirtualizacji (a nawet zaliczyłbym do tego co lepsze
dzisiejsze rozwiązania gridowe), która takie decyzje będzie podejmować
automatycznie (taki profiling z optymalizowaniem, tyle, że na poziomie
wirtualnych komputerów).
Wracając do JRockitVE - jej specjalizacja (pod kątem aplikacji Java i
"rozumienia" tego co się dzieje wewnątrz JVM) daje tu nieporównanie
większe szanse na lepszą inteligencję takich optymalizacji niż
klasyczny OS, który cóż... traktuje proces JVM tak samo jak proces
Solitaire.
> Tyle tylko, ze izolacja _aplikacji_ przy pomocy hypervisora i przy
> pomocy "klasycznego OS" specjalnie sie nie rozni. Prawdziwa izolacja to
> izolacja _fizyczna_ a nie wirtualna.
W każdym razie, izolacja którą daje wirtualizacja (przynajmniej w
wykonaniu hypervisorów o takiej konstrukcji jak VMware ESX czy Xen/
OracleVM) jest lepsza niż ta, którą daje typowy OS. Bo wewnątrz maszyn
wirtualnych udostępnianych przez hypervisor działa jeszcze guest OS
(klasyczny, np. Red Hat Linux/Solaris albo specjalizowany, np.
JRockitVE). Izolacja fizyczna (?) tak samo rozumiem dotyczy takiego OS
jak Linux na fizycznym sprzęcie, jak i takiego "OS", jak hypervisor na
fizycznym sprzęcie. Tyle, że w wirtualizacji wciąż jeszcze dochodzi
guest OS.
> ?? jak mozna sie komunikowac z programem ktory nie dziala. Rozumiem, ze to
> skrot myslowy i komunikujesz sie z _innym_ programem.
A no widzisz. Witaj w świecie wirtualizacji (chciałoby się
sparafrazować Morpheus'a i powiedzieć: welcome to the virtual
world ;-))
Tu chodziło o to, że taka wirtualna maszyna jest zapisana w postaci
pliku. Zawartością tego pliku i znajdujących się w nim:
- definicji wirtualnego sprzętu (tu: wystawianego przez OracleVM)
- guest OS (tu: JRockitVE)
- aplikacji (tu: JVM, opcjonalnie middleware i aplikacje Java)
- wirtualnego filesystemu (o ile został utworzony)
można manipulować "z zewnątrz" (np. chciałbyś utworzyć folder w
wirtualnym systemie plików i wgrać tam JARa z aplikacją). Możesz to
robić także wtedy, gdy taka maszyna wirtualna nie działa (czyli tak
samo, jakbyś chciał zmieniać zawartość pliku .ISO z Twoim ulubionym
systemem operacyjnym). Osoby, które były na konferencji GeeCon 2009 w
Krakowie mogły to zobaczyć "na żywo".
> > Jeśli pisząc "aplikacje" masz na myśli "serwer aplikacyjny, RDBMS,
> > LDAP, itd." to tak (nawet pomijając, że tak jak napisałem jest regułą
> > w produkcyjnych systemach oddzielać od siebie poszczególne komponenty
> > systemu, np. RDBMS, czy LDAP od aplikacji). Jeśli natomiast przez
> > "aplikacje" rozumiesz "aplikacje Java / Java EE", to niekoniecznie -
> > masz wybór (taki sam jak dzisiaj) co do topologii systemu Java EE.
> > Możesz mieć skrajności:
> > - jedną maszynę (guest), w której jest JVM, serwer aplikacyjny i JEDNA
> > aplikacja Java EE
> > - jedną maszynę (guest), w której jest JVM, serwer aplikacyjny i WIELE
> > aplikacji Java EE
>
> Niestety JVM tylko teoretycznie to umozliwia. W praktyce - nie. Juz zbyt
> wiele razy spotkalem sie z potrzeba restartu JVM z WLSem, zeby wierzyc, ze
> to dziala.
Uważasz, że memory leak jest specyficznym zjawiskiem dla Java ??? W
99% przypadków z którymi się stykam memory leak powstają jednak na
poziomie kodu aplikacyjnego.
Zresztą co ma restartowanie do tego jak poszczególne komponenty będą
rozmieszczone...
Co do WLS, to powiem Ci, że ja też widziałem systemy, w których WLS
jest restartowany raz na rok. Dla higieny. A czasem też dla higieny OS
na którym ten WLS działa ;-).
> > Czyli TAK SAMO jak dzisiaj, z tym, że ZAMIAST maszyn fizycznych są
> > wirtualne.
>
> Nie tak samo. Wyobraz sobie, ze na swiecie bardzo duzo ludzi nadal stosuje
> prosta zasade - jeden mocny komputer + dobry OS + tyle aplikacji ile jest w
> danej chwili wymagane. Jezeli jest potrzebna izolacja poszczegolnych czesci
> systemu ze wzgledu na bezpieczenstwo, to stawia sie wiele _fizycznych_
> maszyn (izolacja przy pomocy jakiegos oprogramowania do wirtualizacji nie
> przejdzie pierwszego lepszego audytu bezpieki - chyba, ze to oprogramowanie
> ma certyfikaty odpowiedniego poziomu - ja do tej pory spotkalem sie z
> jednym takim przypadkiem - produktem HP posiadajacym certyfikat bodajze A2)
>
> I to jest najczesciej _najtansze_ rozwiazanie.
Sorry Michał, ale przejdź się do jakiejkolwiek większej firmy i
zobaczyć jak wielki procent ich data center jest już zwirtualizowane.
Nawet w Polsce (w której wciąż niestety trudno o skalę), są firmy
które świadomie pozbyły się setek takich maszyn o których napisałem i
zastąpiły je kilkunastoma większymi wraz z wirtualizacją. Może się
zdziwisz, ale nie chcą już wracać do tego co było. Co jeszcze
ciekawsze, a propos kosztów - często taki projekt jest w stanie się
spłacić już po roku albo i krócej (to co piszę opieram na prezentacji,
którą pokazywał szef informatyki jednego z dużych polskich
operatorów). Tak - już po jednym roku. A przy tym ich wskaźniki SLA
typu dostępność aplikacji (czy usługi) wzrosły.
Nie twierdzę przy tym, że każdą aplikację warto od razu
zwirtualizować. Jeśli aplikacja nie wyrabia się na fizycznym sprzęcie
(albo mocno go obciąża), to wirtualizacja jej nie pomoże (przynajmiej
jeśli chodzi o wydajność). Wciąż też, wielkie bazy danych (np.
hurtownie) raczej mało z wirtualizacji skorzystają (pomijając to że są
to przeważnie bardzo obciążone systemy, to na dzisiaj wirtualizacja
zwykle obniża wydajność I/O - w przypadku baz danych kluczowego
czynnika ich wydajności).
Nie zmienia to jednak FAKTU, że zaczyna się takie przypadki traktować
jak wyjątki - całą resztę wirtualizuje się.
Co do security, to chyba w jeszcze większym stopniu się mylisz (czy Ty
w ogóle miałeś jaką styczność z wirtualizacją w praktyce ?). Po
pierwsze - to akurat mniej ważne - do przeważającej części systemów w
większości organizacji certyfikatów tego rodzaju nikt nie oczekuje. Co
ważniejsze - wirtualizacja wnosi DODATKOWĄ warstwę security - coś w
rodzaju sandbox'a w Java. Dla tej warstwy producenci oprogramowania
wirtualizacyjnego zdobywają certyfikaty, takie same jak i dla OS, czy
innych komponentów. Większość ludzi w wirtualizacji postrzega też
szansę, aby ulepszyć security desktop'ów czy komórek (np. proces
przeglądarki internetowej startujący w maszynie wirtualnej, w której -
jak w sandbox'ie Java - przeglądarka działa w niemal kompletnej
izolacji, np. z wyłączonym dostęp do fizycznego dysku, itd.)
> Tyle, ze bez tego tzw. "balastu" JVM jest bezuzyteczna :-) - gdzies w koncu
> ta reszta (RDBMS, LDAP, filesystem itd itp) musi dzialac....
Nakrótsza odpowiedź: TAK SAMO JAK DZISIAJ. Rozmieszczenie tych
komponentów na oddzielnych maszynach jest to reguła w dzisiejszych
(zwłaszcza produkcyjnych) systemach. Sam o tym Michał powyżej
napisałeś:
"Jezeli jest potrzebna izolacja poszczegolnych czesci systemu ze
wzgledu na bezpieczenstwo, to stawia sie wiele _fizycznych_". Tyle, że
słowo _fizycznych_ można zastąpić słowem _wirtualnych_ (z podanymi
wcześniej zastrzeżeniami).
Pozdrawiam,
Waldek Kot
Waldek Kot
> O to, ze w normalnym OSie jakis program wpadnie w nieskonczona petle, to go
> ubijasz. Innych programow to nie obchodzi.
> W serwerze J2EE (dzialajacym w ramach jednej JVM) jak masz dwie aplikacje
> J2EE i jedna z nich zwisnie, to lezysz i kwiczysz, bo musisz zrobic restart
> calego serwera.
To zależy od implementacji serwera aplikacyjnego (w OS zresztą
podobnie: vide Windows 3.1/95/98). Jeśli serwer aplikacyjny ma tego
rodzaju mechanizmy "ochronne" i/lub scheduler w którym można podać
Quality of Service, to odpowiedź będzie brzmiała: NIE leżysz (i NIE
kwiczysz).
Przez QoS rozumiem np. takie rzeczy jak podanie priorytetów aplikacji
(lub wybranych jej części, np. servlet-u czy EJB), określenie min/max
liczby wątków dla danej aplikacji (lub jej składnika), itd.
W produkcyjnych rozwiązaniach dosyć powszechnie stosuje się
klastrowanie serwerów aplikacyjnych (a dokładniej aplikacji i ich
komponentów), które pozwalają zmniejszyć ryzyko zatrzymania całej
aplikacji z powodu awarii jednego z komponentów systemu.
Warto też pamiętać o tym, że W PRZECIWIEŃSTWIE do OS, serwery
aplikacyjne Java EE Z ZAŁOŻENIA wykonują kod zaufany (administrator
robi deployment aplikacji, itd). Czyli znowu mały kompromis. Ale od
kilkunastu lat działa raczej dobrze...
Pozdrawiam,
Waldek Kot
Michal Kleczek
[ciach]
>
> Co do izolacji, to się nie zgodzę. Izolacja (aplikacji Java) w
> JRockitVE jest w najgorszym razie taka sama jak w dzisiejszych JVM
> (podkreślałem już też, że JVM działający na JRockitVE jest
> niemodyfikowany, tj. identyczny z tym, który można uruchomić na
> klasycznym OS).
Czyli izolacja jest badziewna - nie mozna chociazby ubic watku wiszacego w:
while(true);
> Biorąc też pod uwagę, że wirtualizacja oferuje lepszy
> poziom izolacyjności niż to co oferują systemy operacyjne
A na czym polega ta "lepszosc" dla _aplikacji_???
>> Znacznie bardziej efektywnie jest na jednym fizycznym serwerze
>> zainstalowac dobry "klasyczny OS" i uruchamiac na nim cokolwiek dusza
>> zapragnie. Po to wlasnie wymyslono OS.
>
> OK, czyli tym razem chcesz zanegować sens wirtualizowania i
> przydatności hypervisor'ów...
Nie. Ja neguje sens wirtualizacji maszyny wirtualnej, a nie wirtualizacji
jako takiej.
> Zalety i wady wirtualizacji są
> powszechnie znane. Trend ku wirtualizacji jest jednak dosyć wyraźny i
> raczej nie widać, aby cokolwiek miało się tu zmienić. Za chwilę będzie
> trudno zobaczyć komputer (czy komórkę) bez wirtualizacji... Każdy
> serwerowy system operacyjny dzisiaj w większym, bądź mniejszym stopniu
> ma wsparcie dla wirtualizacji. Jądra Linux'a nawet mają wsparcie
> (parawirtualizację) dla kilku hypervisor'ów (Xen, KVM)...
IMHO to wynika z kilku rzeczy:
1. Producenci lubia wciskac kit i sprzedawac rzeczy nikomu do niczego
niepotrzebne. Wydaja nawet na to sporo pieniedzy.
2. Kupujacy czesto nie maja pojecia o tym, ze to kit (bo decyzje o kupnie
podejmuje najczesciej dyrektor, a nie pracownik merytoryczny)
3. Wirtualizacja jest _czasami_ potrzebna
a) np. zeby uruchomic dwa rozne OSy w tym samym czasie na jednym sprzecie,
bo takie sa potrzeby organizacji
b) w srodowiskach, gdzie istnieje potrzeba czestej reinstalacji calego
zestawu programow (lacznie z osem) czyli np. srodowiska
testowe/developerskie itp. Jako zestaw programow rozumiem np.
OS+DBMS+serwer aplikacyjny+inne niezbedne programy skladajace sie na
system. W tym kontekscie jest oczywiscie bez sensu wirtualizacja _jednego_
z komponentow (czyli w przypadku naszej dyskusji JVM), bo chodzi o sprawne
zarzadzanie calym zestawem naraz.
>
>
>> > Daj spokój - serwery aplikacyjne dosyć dobrze izolują uruchomione
>> > wewnątrz nich aplikacje. Przynajmniej na tyle, że działa na nich
>> > dziesiątki tysięcy produkcyjnych aplikacji od paru ładny lat. Raczej
>> > trzeba się mocno postarać, żeby do takiej sytuacji jak ta, którą
>> > opisałeś doprowadzić. Stosując się do ogólnych zaleceń Java i Java EE
>> > łatwo tego uniknąć.
>>
>> Nie sadze, zeby w niebananlnych systemach latwo bylo uniknac
>> nieskonczonych petli i memory leakow. To pierwsze jest niemozliwe nawet
>> teoretycznie.
>
> Można uniknąć.
A niby jak mozna uniknac bledow?
> Pomijam hackerskie sztuczki i wykorzystanie bug'ów (bug
> to bug) - notabene od których żaden OS też nie jest wolny - to
> trzymając się rekomendacji Java/JavaEE w serwerze aplikacyjnym Java EE
> bardzo trudno jest zrobić to o czym piszesz. Jak napiszesz servlet,
> czy EJB które ma nieskończoną pętlę, to serwer aplikacyjny wątek
> obsługujący ten servlet czy EJB w końcu ubije.
Czyzby? Pokaz mi JVM, ktora umie zabic watek wiszacy w:
while (true);
> Jeśli serwer
> aplikacyjny ma wbudowane mechanizmy Quality of Service, to możesz
> skonfigurować, żeby taki servlet/wątek (o ile nie jest zawieszony) nie
> dostał więcej niż określony kwant czasu procesora (lub odpowiedni
> priorytet) - o to dba scheduler serwera aplikacyjnego.
Tyle, ze jak 200 instancji EJB zawisnie w nieskonczonej petli, to scheduler
mozna sobie wsadzic gleboko...
> Daj spokój
> Michał - nie muszę chyba Ci tłumaczyć, że GŁÓWNĄ rolą serwera
> aplikacyjnego jest zarządzanie zasobami (CPU, pamięć, połączenia do
> baz danych, itd). Mało się to różni od podobnego zadania, które robi
> OS.
Zadanie rozni sie malo, ale JVM+serwer aplikacyjny tego zadania wykonywac
nie umie.
>
>> > Mimo tego, że technicznie, to oczywiście serwer
>> > aplikacyjny, czyli z punktu widzenia systemu operacyjnego - proces,
>>
>> Po pierwsze - niekoniecznie proces bo moze byc uruchomiony na OS w ktorym
>> nie istnieje pojecie procesu.
>
> A jaki to OS (i serwer aplikacyjny) ? Chyba jakiś bardzo
> specjalizowany. No cóż, a przed chwilą "badziewiem" nazwałeś
> JRockitVE, który jest hmm... specjalizowanym "OS-em" ???
Jest wiele roznych OSow poza Unixami i Windows. Nie we wszystkich istnieje
pojecie "procesu". Na niektorych z nich sa dostepne JVM.
>
>
>> Po drugie - znam przynajmniej jeden serwer J2EE, ktory uruchamia wiele
>> procesow OS.
>
> A to ciekawe ? Co to za serwer aplikacyjny Java EE ?
O ile dobrze pamietam OC4J w jakiejs starszej wersji dla poszczegolnych
aplikacji tworzyl odrebne procesy. I nie ma sie co z tego smiac, bo pomysl
jest bardzo rozsadny - pozwala _naprawde_ izolowac od siebie aplikacje, a
nie tylko tak udawac.
Ja nie twierdze, ze to jest _bardziej_ skalowalne. Ale pozwala na _izolacje_
aplikacji, zas z drugiej strony nie musi powodowac, ze system skalowalny
nie jest.
>
> Wracając do izolacyjności - mam ogromny szacunek do Tuxedo (jakżeby
> inaczej) - ale obowiązują tutaj te same reguły, czyli źle napisana
> aplikacja uruchomiona w tej samej instancji Tuxedo może zakłócić
> działanie innych.
Jezeli te inne aplikacje sa innymi procesami?
> Nawet łatwiej tu o to, bo aplikacje w Tuxedo to
> aplikacje systemowe (w C, czy COBOL-u) i mają większy poziom dostępu
> do sprzętu.
???
Wlasnie od tego jest OS i jego mechanizmy ochrony zasobow, zeby zle napisana
aplikacja (czy to w C, czy COBOLu, czy w Javie) nie wplywala na inne
aplikacje.
>
> Myślę, że zły przykład podałeś do swojej tezy...
>
>> A ile takich maszyn wirtualnych mozna odpalic na jednym fizycznym
>> serwerze i jak ta liczba ma sie do mozliwej ilosci uruchomionych
>> programow w ramach systemu operacyjnego dzialajacego na tym samym
>> sprzecie?
>
> Najkrócej: to po prostu złe porównanie (przysłowiowych jabłek do
> pomarańczy).
A dlaczego? Przeciez tak naprawde dyskutujemy na temat tego w jaki sposob
najlepiej wykorzystac dostepny sprzet (no i oczywiscie w jaki sposob wydac
najmniej pieniedzy osiagajac te same efekty). Po prostu dobry OS jest
tanszy niz Hypervisor+JRockitVE+dobry OS (to zeby odpalic RDBMS). Co
wiecej - jest rowniez tanszy w zarzadzaniu.
>
>
>> > ??? Rozumiem, że podważasz sens używania serwerów aplikacyjnych. No
>> > comments...
>>
>> Alez skad. Podwazam tylko sens stosowania serwerow aplikacyjnych w
>> zastepstwie systemow operacyjnych.
>
> Tak daleko żeby zastępować OS serwerem aplikacji, to nikt się nie
> posunął. Ale z drugiej strony, 99.5% typowego systemu operacyjnego
> jest w <<zwirtualizowanych serwerowych aplikacjach Java>>
A co to za aplikacje?
> zbędne i
> można się tego pozbyć. Czyli, dzięki hypervisor'om bardzo łatwo
> zbudować specjalizowany OS, który lepiej będzie takie aplikacje
> obsługiwał.
Dwie uwagi:
1. Nie wiem po co zastepowac "klasyczny OS" hypervisorem i "specjalizowanym
OSem" - gdzie lezy przewaga tego drugiego rozwiazania???
2. Po co komu taki "specjalizowany OS". Podwazasz tutaj sens kilkadziesieciu
lat rozwoju systemow operacyjnych ogolnego przeznaczenia.
> Wsparcie tej tezy podałem we wcześniejszym poście,
> prezentując przykład z książki Chisnall'a o Xen - działający "kernel"
> OS który ma 10 linii kodu.
>
>
>> >> Tylko po co to komu? A gdzie RDBMS, gdzie serwer SMTP, gdzie - dajmy
>> >> nato - LDAP, juz nie mowiac o takich tam pierdolach jak serwery ftp,
>> >> ssh itd.
>>
>> > Nic nie stoi na przeszkodzie, aby wciąż ich używał. Tyle, że nie na
>> > JEDNYM systemie operacyjnym, tylko na oddzielnych (a przynajmniej
>> > korzystające z nich aplikacje Java na oddzielnej niż one maszynie -
>> > wirtualnej bądź fizycznej). Sytuacja w której oddziela się RDBMS,
>> > LDAP, serwer poczty, itd. od aplikacji jest REGUŁĄ w PRODUKCYJNYCH
>> > systemach serwerowych (w tym opartych o Java EE).
>>
>> Jest bardzo roznie - czasem jest lepiej miec poszczegolne komponenty
>> odizolowane, czasem nie. Szczegolnie, ze w mocno obciazanych systemach
>> czesto stosuje sie zasade dokladnie odwrotna: przetwarzanie danych blisko
>> danych. Innymi slowy np. program (lub jego fragment) przetwarzajacy dane
>> z RDBMS uruchamia sie na tym samym komputerze, co RDBMS. Zas skalowalnosc
>> osiaga sie poprzez partycjonowanie danych - znowu zeby daleko nie szukac
>> - patrz GigaSpaces lub map-reduce Google'a.
>
>
> Słowo klucz tutaj to "czasem". Czasem lepiej przetransportować dane do
> kodu, czasem kod rozdystybuować do źródeł/partycji danych.
>
> W kontekście zwirtualizowanej Java, to niewiele zmienia, choć
> wirtualizacja wnosi bardzo dużo elastyczności - bo oddziela od
> fizycznego sprzętu.
Przeciez aplikacja Java jest oddzielona od fizycznego sprzetu, bo dziala na
maszynie wirtualnej Java. Jeszcze raz spytam - po co wirtualizowac maszyne
wirtualna? Jakie sa tego korzysci???
>
> Wracając do JRockitVE - jej specjalizacja (pod kątem aplikacji Java i
> "rozumienia" tego co się dzieje wewnątrz JVM) daje tu nieporównanie
> większe szanse na lepszą inteligencję takich optymalizacji niż
> klasyczny OS, który cóż... traktuje proces JVM tak samo jak proces
> Solitaire.
>
Zapomniales tylko o tej warstwie Hypervisora, ktora jest w tym przypadku
niezbedna, a traktuje przeciez JRockitVE tak samo jak proces Solitaire
uruchomiony na Windows dzialajacym na tym samym komputerze.
>
>> Tyle tylko, ze izolacja _aplikacji_ przy pomocy hypervisora i przy
>> pomocy "klasycznego OS" specjalnie sie nie rozni. Prawdziwa izolacja to
>> izolacja _fizyczna_ a nie wirtualna.
>
> W każdym razie, izolacja którą daje wirtualizacja (przynajmniej w
> wykonaniu hypervisorów o takiej konstrukcji jak VMware ESX czy Xen/
> OracleVM) jest lepsza niż ta, którą daje typowy OS. Bo wewnątrz maszyn
> wirtualnych udostępnianych przez hypervisor działa jeszcze guest OS
> (klasyczny, np. Red Hat Linux/Solaris albo specjalizowany, np.
> JRockitVE).
Tyle, ze dolozenie dodatkowej warstwy (hypervisor) nie podnosi poziomu
izolacji, bo i tak instrukcje programu (aplikacji) sa wykonywane
bezposrednio przez procesor. Innymi slowy izolacja aplikacji w ramach
jednego OSa i izolacja aplikacji dzialajacych na dwoch OSach w ramach
jednego hypervisora jest taka sama.
>
>> ?? jak mozna sie komunikowac z programem ktory nie dziala. Rozumiem, ze
>> to skrot myslowy i komunikujesz sie z _innym_ programem.
>
> A no widzisz. Witaj w świecie wirtualizacji (chciałoby się
> sparafrazować Morpheus'a i powiedzieć: welcome to the virtual
> world ;-))
>
> Tu chodziło o to, że taka wirtualna maszyna jest zapisana w postaci
> pliku. Zawartością tego pliku i znajdujących się w nim:
> - definicji wirtualnego sprzętu (tu: wystawianego przez OracleVM)
> - guest OS (tu: JRockitVE)
> - aplikacji (tu: JVM, opcjonalnie middleware i aplikacje Java)
> - wirtualnego filesystemu (o ile został utworzony)
> można manipulować "z zewnątrz" (np. chciałbyś utworzyć folder w
> wirtualnym systemie plików i wgrać tam JARa z aplikacją). Możesz to
> robić także wtedy, gdy taka maszyna wirtualna nie działa (czyli tak
> samo, jakbyś chciał zmieniać zawartość pliku .ISO z Twoim ulubionym
> systemem operacyjnym). Osoby, które były na konferencji GeeCon 2009 w
> Krakowie mogły to zobaczyć "na żywo".
Wybacz, ale manipulacja obrazem maszyny wirtualnej to nie jest to samo, co
komunikowanie sie z maszyna wirtualna... Chyba, ze zawitasz w wirtualnym
swiecie - tam wszystko jest mozliwe.
>
>> Niestety JVM tylko teoretycznie to umozliwia. W praktyce - nie. Juz zbyt
>> wiele razy spotkalem sie z potrzeba restartu JVM z WLSem, zeby wierzyc,
>> ze to dziala.
>
> Uważasz, że memory leak jest specyficznym zjawiskiem dla Java ??? W
> 99% przypadków z którymi się stykam memory leak powstają jednak na
> poziomie kodu aplikacyjnego.
Dokladnie - i dlatego tez potrzebny jest stabilny system operacyjny, ktory
pozwala zle dzialajace aplikacje wylaczyc bez wplywu na inne aplikacje.
Tego JVM nie zapewnia.
> Zresztą co ma restartowanie do tego jak poszczególne komponenty będą
> rozmieszczone...
> Co do WLS, to powiem Ci, że ja też widziałem systemy, w których WLS
> jest restartowany raz na rok. Dla higieny. A czasem też dla higieny OS
> na którym ten WLS działa ;-).
Ja sie spotkalem z systemami, gdzie OS _nigdy_ nie byl restartowany, zas JVM
wielokrotnie - co oczywiscie niczego nie dowodzi... :-)
[ciach]
>
>> Tyle, ze bez tego tzw. "balastu" JVM jest bezuzyteczna :-) - gdzies w
>> koncu ta reszta (RDBMS, LDAP, filesystem itd itp) musi dzialac....
>
> Nakrótsza odpowiedź: TAK SAMO JAK DZISIAJ. Rozmieszczenie tych
> komponentów na oddzielnych maszynach jest to reguła w dzisiejszych
> (zwłaszcza produkcyjnych) systemach. Sam o tym Michał powyżej
> napisałeś:
> "Jezeli jest potrzebna izolacja poszczegolnych czesci systemu ze
> wzgledu na bezpieczenstwo, to stawia sie wiele _fizycznych_". Tyle, że
> słowo _fizycznych_ można zastąpić słowem _wirtualnych_ (z podanymi
> wcześniej zastrzeżeniami).
Jezeli mowimy o rzeczywistym bezpieczenstwie - nie mozna.
--
Michal
Michal Kleczek
> On May 12, 2:47 pm, Michal Kleczek <klek...@gmail.com> wrote:
>> O to, ze w normalnym OSie jakis program wpadnie w nieskonczona petle, to
>> go ubijasz. Innych programow to nie obchodzi.
>> W serwerze J2EE (dzialajacym w ramach jednej JVM) jak masz dwie aplikacje
>> J2EE i jedna z nich zwisnie, to lezysz i kwiczysz, bo musisz zrobic
>> restart calego serwera.
>
>
> To zależy od implementacji serwera aplikacyjnego (w OS zresztą
> podobnie: vide Windows 3.1/95/98). Jeśli serwer aplikacyjny ma tego
> rodzaju mechanizmy "ochronne" i/lub scheduler w którym można podać
> Quality of Service, to odpowiedź będzie brzmiała: NIE leżysz (i NIE
> kwiczysz).
Pokaz mi serwer aplikacji J2EE+JVM, ktory pozwala ubic watek krecacy sie w:
while (true);
> W produkcyjnych rozwiązaniach dosyć powszechnie stosuje się
> klastrowanie serwerów aplikacyjnych (a dokładniej aplikacji i ich
> komponentów), które pozwalają zmniejszyć ryzyko zatrzymania całej
> aplikacji z powodu awarii jednego z komponentów systemu.
Ale to sie ma nijak do wirtualizacji JVM, prawda?
>
> Warto też pamiętać o tym, że W PRZECIWIEŃSTWIE do OS, serwery
> aplikacyjne Java EE Z ZAŁOŻENIA wykonują kod zaufany (administrator
> robi deployment aplikacji, itd). Czyli znowu mały kompromis. Ale od
> kilkunastu lat działa raczej dobrze...
Nie rozmawiamy o tym, czy kod pochodzi z zaufanego zrodla, tylko o
programach zawierajacych bledy (czyli wszystkich - nawet tych zaufanych).
--
Michal
Waldek Kot
> > Co do izolacji, to się nie zgodzę. Izolacja (aplikacji Java) w
> > JRockitVE jest w najgorszym razie taka sama jak w dzisiejszych JVM
> > (podkreślałem już też, że JVM działający na JRockitVE jest
> > niemodyfikowany, tj. identyczny z tym, który można uruchomić na
> > klasycznym OS).
>
> Czyli izolacja jest badziewna - nie mozna chociazby ubic watku wiszacego w:
>
> while(true);
Zgadza się. JVM (przynajmniej te implementacje które znam) takiego
wątku same nie ubiją. Natomiast serwer aplikacyjny Java EE który to
może zrobić, to owszem znam. Żadna nowość, bo ma to od wersji 9.0,
czyli ponad 4 lata. No i oczywiście mówimy o wątku, który jest
zarządzany przez serwer aplikacyjny - tj. pochodzi z jego puli wątków.
> > Biorąc też pod uwagę, że wirtualizacja oferuje lepszy
> > poziom izolacyjności niż to co oferują systemy operacyjne
>
> A na czym polega ta "lepszosc" dla _aplikacji_???
Tak jak to wyjaśniałem wcześniej, system operacyjny w guest OS daje
dodatkowy poziom izolacji (dodatkowy do tego który daje hypervisor).
> >> Znacznie bardziej efektywnie jest na jednym fizycznym serwerze
> >> zainstalowac dobry "klasyczny OS" i uruchamiac na nim cokolwiek dusza
> >> zapragnie. Po to wlasnie wymyslono OS.
>
> > OK, czyli tym razem chcesz zanegować sens wirtualizowania i
> > przydatności hypervisor'ów...
>
> Nie. Ja neguje sens wirtualizacji maszyny wirtualnej, a nie wirtualizacji
> jako takiej.
Tyle, że każde z użytych tu słów "wirtualizacja" ma inne znaczenie:
- wirtualizacja w "maszyna wirtualna" odnosi się do hypervisora i
wirtualnego sprzętu
- JVM odnosi się do środowiska wykonawczego dla bytecode'u Java
Ale podobnie jak mniemam i Tobie, ta gra słowna mi też się podoba -
można pójść dalej: wirtualna pamięć wirtualna, wirtualna pamięć
fizyczna, Virtual Virtual Memory Manager, virtual virtual file system,
itd. :-)
> > Zalety i wady wirtualizacji są
> > powszechnie znane. Trend ku wirtualizacji jest jednak dosyć wyraźny i
> > raczej nie widać, aby cokolwiek miało się tu zmienić. Za chwilę będzie
> > trudno zobaczyć komputer (czy komórkę) bez wirtualizacji... Każdy
> > serwerowy system operacyjny dzisiaj w większym, bądź mniejszym stopniu
> > ma wsparcie dla wirtualizacji. Jądra Linux'a nawet mają wsparcie
> > (parawirtualizację) dla kilku hypervisor'ów (Xen, KVM)...
>
> IMHO to wynika z kilku rzeczy:
> 1. Producenci lubia wciskac kit i sprzedawac rzeczy nikomu do niczego
> niepotrzebne. Wydaja nawet na to sporo pieniedzy.
> 2. Kupujacy czesto nie maja pojecia o tym, ze to kit (bo decyzje o kupnie
> podejmuje najczesciej dyrektor, a nie pracownik merytoryczny)
> 3. Wirtualizacja jest _czasami_ potrzebna
> a) np. zeby uruchomic dwa rozne OSy w tym samym czasie na jednym sprzecie,
> bo takie sa potrzeby organizacji
> b) w srodowiskach, gdzie istnieje potrzeba czestej reinstalacji calego
> zestawu programow (lacznie z osem) czyli np. srodowiska
> testowe/developerskie itp. Jako zestaw programow rozumiem np.
> OS+DBMS+serwer aplikacyjny+inne niezbedne programy skladajace sie na
> system.
OK, to już mi odpowiedziałeś na pytanie czy miałeś w praktyce do
czynienia z wirtualizacją...
Co do dwóch pierwszych punktów, to pozwól, że zostawię bez komentarza.
Mamy widać różne doświadczenia życiowe...
> W tym kontekscie jest oczywiscie bez sensu wirtualizacja _jednego_
> z komponentow (czyli w przypadku naszej dyskusji JVM), bo chodzi o sprawne
> zarzadzanie calym zestawem naraz.
Nie ma problemu, możesz zarządzać całym środowiskiem wirtualnym "na
raz". Cała para w oprogramowaniu do wirtualizacji idzie w tej chwili w
to, aby takimi złożonymi środowiskami zarządzać. Można łączyć
(linkować) maszyny wirtualne nawzajem. I np. jako CAŁOŚĆ potraktować
takie przykładowe sklastrowane środowisko webowe (tu "VM" oznacza
"maszynę wirtualną pod kontrolą hypervisor'a", nie mylić z "JVM"):
a. 2 VM z serwerami HTTP
b. 2 VM z serwerem aplikacyjnym (w każdym VM można guest OS - tutaj
JRockitVE i uruchomić JVM z serwerem aplikacyjnym)
c. 2 VM z bazą danych
Niestety nie ma (jeszcze ?) specjalizowanych OS do warstwy a i b (choć
można użyć JeOS - just enough OS, "przykrojonych" do danego celu).
Do tego możesz dołożyć wirtualne firewall'e, routery, itd i jako
CAŁOŚĆ odpalić na fizycznych maszynach. Nie ma też specjalnego powodu,
żebyś nie mógł takich obrazów VM wysłać (np. poprzez FTP) jako całość
(czyli ze WSZYSTKIMI ustawieniami, typu adresy IP, porty, reguły
routing'u, itd) do zdalnego data center i masz całkiem łatwo, całkiem
strawne środowisko disaster recovery.
> >> Nie sadze, zeby w niebananlnych systemach latwo bylo uniknac
> >> nieskonczonych petli i memory leakow. To pierwsze jest niemozliwe nawet
> >> teoretycznie.
>
> > Można uniknąć.
>
> A niby jak mozna uniknac bledow?
Błędów nie, ale ich konsekwencji (np. nieskończonych pętli, czy memory
leak'ów) tak. Chyba nie uważasz, że OS potrafi "uniknąć błędów" ?
> Pokaz mi JVM, ktora umie zabic watek wiszacy w:
> while (true);
JVM - nie (chyba, bo implementacji JVM są setki). Serwer aplikacyjny
Java EE - tak.
> > Jeśli serwer
> > aplikacyjny ma wbudowane mechanizmy Quality of Service, to możesz
> > skonfigurować, żeby taki servlet/wątek (o ile nie jest zawieszony) nie
> > dostał więcej niż określony kwant czasu procesora (lub odpowiedni
> > priorytet) - o to dba scheduler serwera aplikacyjnego.
>
> Tyle, ze jak 200 instancji EJB zawisnie w nieskonczonej petli, to scheduler
> mozna sobie wsadzic gleboko...
Nie. Jeśli scheduler ma obsługę ochrony przed zawiśnięciami i/lub
obsługę QoS, to nie trzeba wsadzać niczego nigdzie. Zarówno ochronę,
jak i QoS możesz ustawiać per aplikacja, per komponenty, itd.
> > ... nie muszę chyba Ci tłumaczyć, że GŁÓWNĄ rolą serwera
> > aplikacyjnego jest zarządzanie zasobami (CPU, pamięć, połączenia do
> > baz danych, itd). Mało się to różni od podobnego zadania, które robi
> > OS.
>
> Zadanie rozni sie malo, ale JVM+serwer aplikacyjny tego zadania wykonywac
> nie umie.
No, to teraz do podważania sensu istnienia doszła jeszcze para JVM i
serwer aplikacyjny. Who's next ?
> >> Po pierwsze - niekoniecznie proces bo moze byc uruchomiony na OS w ktorym
> >> nie istnieje pojecie procesu.
>
> > A jaki to OS (i serwer aplikacyjny) ? Chyba jakiś bardzo
> > specjalizowany. No cóż, a przed chwilą "badziewiem" nazwałeś
> > JRockitVE, który jest hmm... specjalizowanym "OS-em" ???
>
> Jest wiele roznych OSow poza Unixami i Windows. Nie we wszystkich istnieje
> pojecie "procesu". Na niektorych z nich sa dostepne JVM.
OK, czyli masz na myśli specjalizowany OS, a w każdym razie, żaden z
mainstreamowych. A skoro nie ma w nim pojęcia "proces", to chyba jest
on bardziej egzotyczny (parafrazując Twoją wypowiedź: "bardziej
badziewny") w stosunku do JRockitVE ?
> >> Po drugie - znam przynajmniej jeden serwer J2EE, ktory uruchamia wiele
> >> procesow OS.
>
> > A to ciekawe ? Co to za serwer aplikacyjny Java EE ?
>
> O ile dobrze pamietam OC4J w jakiejs starszej wersji dla poszczegolnych
> aplikacji tworzyl odrebne procesy. I nie ma sie co z tego smiac, bo pomysl
> jest bardzo rozsadny - pozwala _naprawde_ izolowac od siebie aplikacje, a
> nie tylko tak udawac.
Hmm, nie wiem czy tak było (koledzy z pracy podpowiadają mi, że też
nie słyszeli o takim OC4J), ale skoro się z tego wycofano, to chyba
pomysł nie był najlepszy. Zresztą, to co piszesz można zrobić w
serwerach aplikacyjnych. Na jednej maszynie można odpalić wiele
instancji serwerów aplikacyjnych i w każdym osadzić inne aplikacje. W
środowisku wirtualnym można też odpalić wiele maszyn wirtualnych
(guestów). Efekt, jeśli chodzi o zwiększenie poziomu izolacji
aplikacji od siebie, będzie podobny...
> Ja nie twierdze, ze to jest _bardziej_ skalowalne. Ale pozwala na _izolacje_
> aplikacji, zas z drugiej strony nie musi powodowac, ze system skalowalny
> nie jest.
OK, nie musi, ale zwykle tak jest. Do pewnej skali nie ma istotnej
różnicy, od pewnej to podejście z procesami przestaje działać
(przykład z historii: CGI).
> > Wracając do izolacyjności - mam ogromny szacunek do Tuxedo (jakżeby
> > inaczej) - ale obowiązują tutaj te same reguły, czyli źle napisana
> > aplikacja uruchomiona w tej samej instancji Tuxedo może zakłócić
> > działanie innych.
>
> Jezeli te inne aplikacje sa innymi procesami?
OK - w tym przypadku raczej nie. Ale ja myślałem o przypadku, gdy w
ramach jednej instancji serwera aplikacyjnego Tuxedo jest
uruchomionych kilka usług (aplikacji). Wtedy, owszem - jest to
możliwe.
> > Nawet łatwiej tu o to, bo aplikacje w Tuxedo to
> > aplikacje systemowe (w C, czy COBOL-u) i mają większy poziom dostępu
> > do sprzętu.
>
> ???
> Wlasnie od tego jest OS i jego mechanizmy ochrony zasobow, zeby zle napisana
> aplikacja (czy to w C, czy COBOLu, czy w Javie) nie wplywala na inne
> aplikacje.
Zgoda, ale w Java jest jeszcze JVM, który wprowadza dodatkowe
mechanizmy ochronne (od najbardziej podstawowych, np. weryfikacja
poprawności binariów, po bardziej zaawansowane). Nie zrozum mnie źle,
"łatwiej" niż Javie, nie oznacza "banalnie łatwo"...
> >> A ile takich maszyn wirtualnych mozna odpalic na jednym fizycznym
> >> serwerze i jak ta liczba ma sie do mozliwej ilosci uruchomionych
> >> programow w ramach systemu operacyjnego dzialajacego na tym samym
> >> sprzecie?
>
> > Najkrócej: to po prostu złe porównanie (przysłowiowych jabłek do
> > pomarańczy).
>
> A dlaczego? Przeciez tak naprawde dyskutujemy na temat tego w jaki sposob
> najlepiej wykorzystac dostepny sprzet (no i oczywiscie w jaki sposob wydac
> najmniej pieniedzy osiagajac te same efekty). Po prostu dobry OS jest
> tanszy niz Hypervisor+JRockitVE+dobry OS (to zeby odpalic RDBMS). Co
> wiecej - jest rowniez tanszy w zarzadzaniu.
Porównanie które zrobiłeś "liczba możliwych procesów vs. liczba
możliwych maszyn wirtualnych" nie ma sensu.
Co do taniości, kosztu zarządzania - czy mówiąc szerzej efektywności
wykorzystania zasobów sprzętowych, to cóż - główny cel wirtualizacji
polega na tym, aby BARDZIEJ efektywnie wykorzystywać dostępne zasoby
sprzętowe. Co do JRockitVE, to cel jest podobny - bardziej efektywne
wykorzystanie sprzętu dla aplikacji Java. Stos:
- hypervisor + VM + klasyczny OS + JVM + aplikacje
jest mniej efektywny niż stos:
- hypervisor + VM + JRockitVE + JVM + aplikacje
Przez "efektywność" rozumiem tu wykorzystanie pamięci, procesora, I/O
przydzielonych do VM. Skoro JRockitVE to - upraszczam - mniej więcej
0.5% klasycznego OS, to różnicę widać. Będzie bardziej widać, jak się
tę "różnicę" pomnoży przez liczbę maszyn wirtualnych (VM). Na typowym
dzisiaj serwerze fizycznym z 16 core (4CPU quad core), mnożnik wynosi
~16. Jak się pojawią maszyny z setkami core'ów, to nawet bardziej.
Odzyskane RAM, CPU, I/O można zarówno "oddać" już uruchomionym na tym
fizycznym sprzęcie maszynom wirtualnym (VM), jak i uruchomić więcej
maszyn wirtualnych. Zgodnie ze słownikową definicją efektywności:
"efekt do nakładów", to rośnie nam mocno "efekt", a tylko odrobinę
"nakład" (czyli narzut wirtualizacji - dzięki wsparciu w sprzęcie
zjawisko dosyć mocno zanikające). Wynik: wzrost efektywności...
> > Tak daleko żeby zastępować OS serwerem aplikacji, to nikt się nie
> > posunął. Ale z drugiej strony, 99.5% typowego systemu operacyjnego
> > jest w <<zwirtualizowanych serwerowych aplikacjach Java>>
>
> A co to za aplikacje?
Te, które działają po stronie serwera :-). Technicznie: nie korzystają
z dźwięku, graficznego GUI, itd. W przypadku JRockitVE, do ograniczeń
dochodzą jeszcze:
- aplikacje, które uruchamiają procesy (np. poprzez fork/clone)
- aplikacje, które bezpośrednio odwołują się do sprzętu (w przypadku
Java, będzie to np. JNI)
To ostatnie ograniczenie (dot. natywnego kodu, np. poprzez JNI) też
nie jest takie czarno-białe. Większość natywnego kodu ("linuksowego",
bo ABI JRockitVE jest zgodne z ABI Linux'ów) zadziała.
Dla mówimy zdecydowanej większości (99.9% ?) aplikacji J2EE i Java EE.
> Dwie uwagi:
> 1. Nie wiem po co zastepowac "klasyczny OS" hypervisorem i "specjalizowanym
> OSem" - gdzie lezy przewaga tego drugiego rozwiazania???
Po co wprowadzać hypervisor ? Żeby skorzystać z zalet wirtualizacji.
Po co wprowadzać specjalizowany OS ? Żeby sprawić, że aplikacje (tu:
Java) działały jeszcze bardziej efektywnie.
> 2. Po co komu taki "specjalizowany OS". Podwazasz tutaj sens kilkadziesieciu
> lat rozwoju systemow operacyjnych ogolnego przeznaczenia.
Podważam ? W którym miejscu ? W ramach klasy "systemy operacyjne
ogólnego przeznaczenia" znajdziesz wiele dosyć specjalizowanych OS-ów
(np. real-time). JRockitVE nie jest "egzotyką" (dla przykładu: pojęcie
procesu w nim występuje ;-). Specjalizowany dla Java ..., owszem.
> > Wracając do JRockitVE - jej specjalizacja (pod kątem aplikacji Java i
> > "rozumienia" tego co się dzieje wewnątrz JVM) daje tu nieporównanie
> > większe szanse na lepszą inteligencję takich optymalizacji niż
> > klasyczny OS, który cóż... traktuje proces JVM tak samo jak proces
> > Solitaire.
>
> Zapomniales tylko o tej warstwie Hypervisora, ktora jest w tym przypadku
> niezbedna, a traktuje przeciez JRockitVE tak samo jak proces Solitaire
> uruchomiony na Windows dzialajacym na tym samym komputerze.
Nie zapomniałem, ale owszem warstwa hypervisora jest niezbędna (przy
czym na marginesie: czysto na potrzeby testów, deweloperzy JRockitVE
są w stanie uruchomić JRockitVE bezpośrednio na fizycznym sprzęcie.
Ale zakłada się, że w praktyce zawsze będzie działać wewnątrz maszyny
wirtualnej udostępnianej przez hypervisor - nawet konkretne
hypervisory: do celów produkcyjnych: bazujący na Xen OracleVM, do
celów demonstracyjnych dodatkowo jeszcze VMware Player).
Hypervisor oferuje dodatkowe możliwości (np. pause/unpause maszyny,
save/restore jej stanu, jej suspend/resume, migracja na inną fizyczną
maszynę, w tym "na żywo" i tak dalej). Przede wszystkim jednak
hypervisor "wystawia" dla "OS-a" (czyli JRockitVE) standardowy sprzęt
(CPU, pamięć, chipset'y, sieć, dyski, itd.). Dzięki temu ten
specjalizowany OS nie musi się już martwić o sterowniki do setek
tysięcy przeróżnych elementów sprzętowych. W zasadzie potrzebuje tylko
2 driver'y: do dysków i do sieci (oba są wirtualne - jak się mapują na
fizyczne, to już rola hypervisora, nie JRockitVE).
Poza tym, hypervisor daje znacznie większe możliwości systemom
operacyjnym działającym wewnątrz maszyn wirtualnych w zakresie
sterowania zarówno fizycznym, jak i wirtualnym sprzętem. Znacznie
większe niż klasyczny OS daje działającym w jego ramach procesom... To
można wykorzystywać do całkiem ciekawych optymalizacji...
W tym sensie, to "traktowanie" JRockitVE przez hypervisor jest inne
niż Solitaire'a przez Windows :-). Dodatkowo, także JRockitVE (jako
"OS") "traktuje" JVM inaczej - np. "rozumie" (tj. uwzględnia w swoim
działaniu) jej krytyczne struktury i ich stan: np. Java heap, Java
threads, itd.
> Tyle, ze dolozenie dodatkowej warstwy (hypervisor) nie podnosi poziomu
> izolacji, bo i tak instrukcje programu (aplikacji) sa wykonywane
> bezposrednio przez procesor. Innymi slowy izolacja aplikacji w ramach
> jednego OSa i izolacja aplikacji dzialajacych na dwoch OSach w ramach
> jednego hypervisora jest taka sama.
Nie. Nie wiem na ile wiesz jak działają hypervisory, ale są zasadniczo
dwie opcje:
1. skanowanie przez hypervisor ciągu instrukcji programu i wyłapywanie
określonych instrukcji i emulowanie ich w softwarze
2. wprowadzenie procesora w specjalny tryb pracy (taki ring "-1"),
dostępny TYLKO dla hypervisora (czyli guest OS w maszynie wirtualnej
do tego trybu i wynikających z tego trybu uprawnień NIE ma dostępu).
W tym sensie jest dodatkowa warstwa, czyli lepsza izolacja.
Natomiast masz rację w tym, że dzisiejsze serwerowe hypervisory NIE
wirtualizują CPU (w przeciwieństwie do wirtualizacji wszelkich innych
komponentów maszyny, np. fizyczne karty sieciowe, dyski czy chipset'y
SĄ wirtualne). Ale to wynika z wydajności...
> Wybacz, ale manipulacja obrazem maszyny wirtualnej to nie jest to samo, co
> komunikowanie sie z maszyna wirtualna...
Zgoda - ja w swojej wypowiedzi podałem jednak OBA "tryby" pracy:
offline (modyfikacja obrazu niedziałającej maszyny wirtualnej) i
online (czyli komunikacja z maszyną wirtualną i uruchomionym w niej
oprogramowaniem tak samo jak z normalnym komputerem). Odwołam się
znowu do mojej prezentacji na GeeCon 2009 w Krakowie, gdzie
pokazywałem uruchomienie WebLogic Server'a na JRockitVE - z zewnątrz
(konsola administracyjna, itd) NIC się nie zmienia. Do samego
wirtualnego komputera też się można dostać "online": ping, SSH,
syslog, itd.
> > Uważasz, że memory leak jest specyficznym zjawiskiem dla Java ??? W
> > 99% przypadków z którymi się stykam memory leak powstają jednak na
> > poziomie kodu aplikacyjnego.
>
> Dokladnie - i dlatego tez potrzebny jest stabilny system operacyjny, ktory
> pozwala zle dzialajace aplikacje wylaczyc bez wplywu na inne aplikacje.
> Tego JVM nie zapewnia.
JVM - nie zapewnia. Serwer aplikacyjny Java EE - może zapewniać.
> Jezeli mowimy o rzeczywistym bezpieczenstwie - nie mozna.
:-). OK - pewnie pozostaniemy przy swoich opiniach. Dla mnie
wirtualizacja oprócz innych funkcjonalności, jest także szansą na
podniesienie poziomu bezpieczeństwa.
Pozdrawiam,
Waldek Kot
Waldek Kot
> Pokaz mi serwer aplikacji J2EE+JVM, ktory pozwala ubic watek krecacy sie w:
> while (true);
Proszę bardzo: WebLogic Server (od wersji 9.0, czyli ok. 2005 roku).
Przypuszczam, że podobne funkcje ochronne mają też inne serwery
aplikacyjne Java EE (przynajmniej te pozycjonowane jako produkcyjne,
high-end'owe), ale musiałbym poszukać w ich dokumentacji czy google
(hasło: overload protection). W każdym razie osoby zainteresowane
innymi serwerami aplikacyjnymi powinny sprawdzić dokumentację tych
serwerów.
Co do implementacji w WLS, to możesz ustawić (globalnie, per
aplikacja, per komponent - np. servlet czy EJB), że jeśli dany wątek
jest "stucked" (czyli żyje, działa, ale nie został zwrócony do puli
wątków serwera aplikacyjnego w określonym - konfigurowalnym - czasie,
to ma być podjęta określona akcja (np. ubicie wątku, ustawienie całej
aplikacji w tryb "admin" - czyli aplikacja działa, ale jest
udostępniona tylko wybranej grupie użytkowników, np. administratorów.
Akcją można być restart work manager'a z którego dany wątek pochodzi,
a także restart całej instancji serwera aplikacyjnego - jeśli jest
skonfigurowany klaster niezawodnościowy, to nastąpi przełączenie na
inną instancję serwera aplikacyjnego i działanie aplikacji nie będzie
wstrzymane).
> > W produkcyjnych rozwiązaniach dosyć powszechnie stosuje się
> > klastrowanie serwerów aplikacyjnych (a dokładniej aplikacji i ich
> > komponentów), które pozwalają zmniejszyć ryzyko zatrzymania całej
> > aplikacji z powodu awarii jednego z komponentów systemu.
>
> Ale to sie ma nijak do wirtualizacji JVM, prawda?
I tak, i nie. Pewne operacje są dzieki wirtualizacji znacznie szybsze
(np. udostępnienie nowej maszyny wirtualnej i włączenie jej do
klastra). Może to sprawić, że w sumie poziom dostępności jednak
wzrośnie - a o to przecież chodzi... Klastrowanie aplikacyjne i
klastrowanie OS nie są sobie przeciwstawne...
Pozdrawiam,
Waldek Kot
Michal Kleczek
> On May 12, 3:45 pm, Michal Kleczek <klek...@gmail.com> wrote:
>> > Co do izolacji, to się nie zgodzę. Izolacja (aplikacji Java) w
>> > JRockitVE jest w najgorszym razie taka sama jak w dzisiejszych JVM
>> > (podkreślałem już też, że JVM działający na JRockitVE jest
>> > niemodyfikowany, tj. identyczny z tym, który można uruchomić na
>> > klasycznym OS).
>>
>> Czyli izolacja jest badziewna - nie mozna chociazby ubic watku wiszacego
>> w:
>>
>> while(true);
>
> Zgadza się. JVM (przynajmniej te implementacje które znam) takiego
> wątku same nie ubiją. Natomiast serwer aplikacyjny Java EE który to
> może zrobić, to owszem znam. Żadna nowość, bo ma to od wersji 9.0,
> czyli ponad 4 lata. No i oczywiście mówimy o wątku, który jest
> zarządzany przez serwer aplikacyjny - tj. pochodzi z jego puli wątków.
To mnie zaskoczyles. Pare pytan:
1. Jak to robi WLS skoro JVM nie daje mozliwosci ubicia watku?
2. Jak na te umiejetnosc wplywa fakt, ze watek pochodzi z puli watkow?
3. Dlaczego WLS w wersji 10 wyrzuca tylko do logu ostrzezenie, ze watek
zawisl, ale - niestety - watek wisi sobie bez konca (to z mojego
doswiadczenia - konsultanci z firmy Bea nie mowili nic o mozliwosci ubicia
watku)?
--
Michal
Michal Kleczek
> On May 12, 3:50 pm, Michal Kleczek <klek...@gmail.com> wrote:
>> Pokaz mi serwer aplikacji J2EE+JVM, ktory pozwala ubic watek krecacy sie
>> w: while (true);
>
> Proszę bardzo: WebLogic Server (od wersji 9.0, czyli ok. 2005 roku).
> Przypuszczam, że podobne funkcje ochronne mają też inne serwery
> aplikacyjne Java EE (przynajmniej te pozycjonowane jako produkcyjne,
> high-end'owe), ale musiałbym poszukać w ich dokumentacji czy google
> (hasło: overload protection). W każdym razie osoby zainteresowane
> innymi serwerami aplikacyjnymi powinny sprawdzić dokumentację tych
> serwerów.
>
> Co do implementacji w WLS, to możesz ustawić (globalnie, per
> aplikacja, per komponent - np. servlet czy EJB), że jeśli dany wątek
> jest "stucked" (czyli żyje, działa, ale nie został zwrócony do puli
> wątków serwera aplikacyjnego w określonym - konfigurowalnym - czasie,
> to ma być podjęta określona akcja (np. ubicie wątku, ustawienie całej
> aplikacji w tryb "admin" - czyli aplikacja działa, ale jest
> udostępniona tylko wybranej grupie użytkowników, np. administratorów.
To oczywiscie mozesz sobie poustawiac, ale watku WLS nie ubije.
> Akcją można być restart work manager'a z którego dany wątek pochodzi,
> a także restart całej instancji serwera aplikacyjnego - jeśli jest
> skonfigurowany klaster niezawodnościowy, to nastąpi przełączenie na
> inną instancję serwera aplikacyjnego i działanie aplikacji nie będzie
> wstrzymane).
To jest jedyna rzecz, ktora moze zrobic serwer aplikacyjny - ale ta
mozliwosc oczywiscie wynika z tego, ze dziala on w srodowisku programu
nadzorcy (inaczej OSa), ktory pozwala zrobic restart "procesu" - lub
odpowiednika procesu.
>
>
>> > W produkcyjnych rozwiązaniach dosyć powszechnie stosuje się
>> > klastrowanie serwerów aplikacyjnych (a dokładniej aplikacji i ich
>> > komponentów), które pozwalają zmniejszyć ryzyko zatrzymania całej
>> > aplikacji z powodu awarii jednego z komponentów systemu.
>>
>> Ale to sie ma nijak do wirtualizacji JVM, prawda?
>
> I tak, i nie. Pewne operacje są dzieki wirtualizacji znacznie szybsze
> (np. udostępnienie nowej maszyny wirtualnej i włączenie jej do
> klastra).
Niby prawda, ale to nie ma zadnej przewagi nad instalowaniem systemu poprzez
tworzenie obrazu dysku i kopiowaniu go (lub - jeszcze lepiej - odpalanie
systemu z jednego wspoldzielonego storage'u)
> Może to sprawić, że w sumie poziom dostępności jednak
> wzrośnie - a o to przecież chodzi... Klastrowanie aplikacyjne i
> klastrowanie OS nie są sobie przeciwstawne...
Ale, zeby miec wysoka dostepnosc i tak musisz miec przynajmnieje dwie
_fizyczne_ maszyny w klastrze. Skoro tak to po co jeszcze dokladac maszyny
wirtualne???
--
Michal
Waldek Kot
> > Zgadza się. JVM (przynajmniej te implementacje które znam) takiego
> > wątku same nie ubiją. Natomiast serwer aplikacyjny Java EE który to
> > może zrobić, to owszem znam. Żadna nowość, bo ma to od wersji 9.0,
> > czyli ponad 4 lata. No i oczywiście mówimy o wątku, który jest
> > zarządzany przez serwer aplikacyjny - tj. pochodzi z jego puli wątków.
>
> To mnie zaskoczyles. Pare pytan:
> 1. Jak to robi WLS skoro JVM nie daje mozliwosci ubicia watku?
> 2. Jak na te umiejetnosc wplywa fakt, ze watek pochodzi z puli watkow?
> 3. Dlaczego WLS w wersji 10 wyrzuca tylko do logu ostrzezenie, ze watek
> zawisl, ale - niestety - watek wisi sobie bez konca (to z mojego
> doswiadczenia - konsultanci z firmy Bea nie mowili nic o mozliwosci ubicia
> watku)?
WLS ma pulę wątków z której wątki są pobierane do wykonywania
określonego zadania, w tym do obsługi żądań do aplikacji. Tą pulą w
pełni zarządza WLS i określa na podstawie całkiem sprytnych heurystyk
ile jest wątków w puli, komu i kiedy je dać, itd. Obok wątków
"aplikacyjnych" w WLS działają wątki techniczne "serwera
aplikacyjnego" (podobnie jak w JVM działają wątki techniczne, np.
wykonujące GC). Na przykład wątek skanujący czas wykonania innych
wątków. Jeśli ten wątek skanujący wykryje wątek który działa zbyt
długo, oznaczy go jako 'stucked' i wyzwalana jest zdefiniowana akcja
(np. restart Work Manager'a do którego dany wątek należy albo całego
serwera). Work Manager to taki obiekt który można przypisywać do
aplikacji i/lub jej składników i w którym m.in. można określić, kiedy
wątek jest uznawany za unieruchomiony ('stucked') i co się ma stać,
gdy pojawi się określona liczba takich wątków. Wątek zawsze
"przynależy" do określonego Work Manager'a. Restartując Work Manager
kasuje się wszystkie należące do niego wątki.
Ad 1
Nie do końca odpowiadam na Twoje pytanie, ale w każdym razie w WLS ta
"nadbudowa" ponad gołe wątki oferowane przez JVM jest spora i pozwala
na bardziej inteligentne zarządzanie wątkami...
Co do zatrzymywania wątków w JVM, to chyba nie do końca masz rację z
tym, że "JVM nie daje możliwości ubicia wątku". Choćby poprzez
Thread.interrupt. Dobry opis różnych wariantów bezpiecznego
zatrzymywania wątków jest w książce Goetz'a "Java Concurrency in
Practice" (chyba cały rozdział jest temu poświęcony).
Ad 2
Właściwie to, że jest możliwe ubicie wynika TYLKO z tego, że ten wątek
pochodzi z puli serwera. Inaczej (tj. gdyby wątek nie pochodził z
puli) serwer sobie z tym nie poradzi. Stąd jest rekomendacja, aby w
komponentach (np. servlet'ach czy EJB) do własnego zarządzania wątkami
posługiwać dedykowanymi do tego narzędziami, a nie "gołym"
java.lang.Thread. Przykładem takiego narzędzia jest CommonJ Work
Manager API, zrobione wspólnie przez BEA i IBM (a od Java EE 6
wreszcie trafi ono do specyfikacji Java EE - JSR-236 i JSR-237). Fajne
jest to, że w WLS-ie jest to zgrane z koncepcją Work Manager'ów,
opisaną powyżej. Czyli można używać ochrony i QoS także do własnych
wątków ("własnych", czyli wątków tworzonych z servlet'ów, EJB, itd.)
Ad 3
Domyślnie w WLS jest 1 work manager (default work manager) i używają
go wszystkie komponenty. Ten domyślny ma QoS typu "fair share", czyli
każdemu komponentowi daje taki sam "priorytet". Ten domyślny ma też
zdefiniowane, że za wątki zablokowane ('stucked') uznaje te, które
przez 15 minut (600 sekund) nie zostały zwrócone do puli. Domyślną
akcją wtedy jest tylko wypisanie ostrzeżenia o tym w logu i z takim
zablokowanym wątkiem serwer nic nie robi.
Możesz zdefiniować sobie własny work manager i określić stosowne
parametry, a następnie przypisać ("target-ować") go do określonego
serwera, aplikacji, komponentu.
Co do konsultantów BEA, to nie wiem, czemu o tym nie mówili - mam
nadzieję, że nie byłem to ja ;-) Było nas w sumie dwóch "na Polskę",
więc jeśli nie ja, to musiał być ten drugi ;-))).
W każdym razie, Work Manager'y są dostępne od wersji 9.0, czyli bardzo
dawna (ponad 4 lata). Na każdym szkoleniu z administracji WLS tego się
uczy.
Tu jest link do dokumentacji WLS pokazujący jak to działa:
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/config_wls/self_tuned.html
Tutaj, jak użyć API do zarządzania własnymi wątkami poprzez CommonJ
Work Manager: http://download.oracle.com/docs/cd/E12840_01/wls/docs103/commonj/index.html
Tu też fajny artykuł na ten temat z dawnego BEA dev2dev przeniesionego
teraz do OTN (Oracle Technology Network):
http://www.oracle.com/technology/pub/articles/dev2arch/2006/01/workload-management.html
Pozdrawiam,
Waldek Kot
Michal Kleczek
> On May 12, 8:55 pm, Michal Kleczek <klek...@gmail.com> wrote:
>> > Zgadza się. JVM (przynajmniej te implementacje które znam) takiego
>> > wątku same nie ubiją. Natomiast serwer aplikacyjny Java EE który to
>> > może zrobić, to owszem znam. Żadna nowość, bo ma to od wersji 9.0,
>> > czyli ponad 4 lata. No i oczywiście mówimy o wątku, który jest
>> > zarządzany przez serwer aplikacyjny - tj. pochodzi z jego puli wątków.
>>
>> To mnie zaskoczyles. Pare pytan:
>> 1. Jak to robi WLS skoro JVM nie daje mozliwosci ubicia watku?
>> 2. Jak na te umiejetnosc wplywa fakt, ze watek pochodzi z puli watkow?
>> 3. Dlaczego WLS w wersji 10 wyrzuca tylko do logu ostrzezenie, ze watek
>> zawisl, ale - niestety - watek wisi sobie bez konca (to z mojego
>> doswiadczenia - konsultanci z firmy Bea nie mowili nic o mozliwosci
>> ubicia watku)?
>
[ciach]
> Ad 1
> Nie do końca odpowiadam na Twoje pytanie,
Wlasnie
> ale w każdym razie w WLS ta
> "nadbudowa" ponad gołe wątki oferowane przez JVM jest spora i pozwala
> na bardziej inteligentne zarządzanie wątkami...
Wiem, wiem: oczywiscie WLS jest super...
MSPANC.
>
> Co do zatrzymywania wątków w JVM, to chyba nie do końca masz rację z
> tym, że "JVM nie daje możliwości ubicia wątku". Choćby poprzez
> Thread.interrupt. Dobry opis różnych wariantów bezpiecznego
> zatrzymywania wątków jest w książce Goetz'a "Java Concurrency in
> Practice" (chyba cały rozdział jest temu poświęcony).
>
Bardzo dobra ksiazka, ale nawet w niej nie ma recepty na to, jak ubic watek
krecacy sie w nieskonczonej petli. Polecam przeczytanie javadoc o
Thread.interrupt(). W Javie sie tego po prostu NIE DA zrobic.
Wiec pisanie, ze WLS to potrafi jest albo:
1. OSZUKIWANIEM czytajacych (aczkolwiek nie wiem jaki bylby tego cel)
2. pisaniem o czyms, o czym nie ma sie pojecia
Co za tym idzie jest to podwazaniem swojego wlasnego autorytetu -
szczegolnie, ze o ile wiem jestes zwiazany z producentem tego serwera.
>
[ciach - tekst zupelnie nie na temat]
>
MSPANC
--
Michal
Waldek Kot
[ciach - frustracje]
Zacznę od spraw merytorycznych (a do Twoich insynuacji Michał odniosę
się w na końcu).
Jedną z rzeczy które podkreślałem w tej części dyskusji było, że "JVM
tego nie potrafi, serwer aplikacyjny owszem - może potrafić". Przyda
się więc pewnie trochę precyzji. W tej implementacji serwera
aplikacyjnego do której ja się odnosiłem, zrobiono scheduler wątków,
który może priorytetyzować wątki i implementować różne ich QoS.
Minimalizując tym samym ryzyko tego, że jeden wątek może zabrać całą
moc CPU i 'zabić' cały serwer aplikacyjny i wszystkie działające w nim
aplikacji. Taki wątek, który przekroczy pewnen czas działania - np.
jest w długodziałającej lub nieskończonej pętli - jest oznaczony jako
'stucked'. Można skonfigurować, że work manager, do którego ten wątek
przynależy, zostanie przez serwer aplikacyjny zrestartowany. Co
będzie skutkowało tym, że czekające w app serwerze żądania do tej
aplikacji (czyli te, które trafiły do kolejki zadań oczekujących na
rozpoczęcie wykonywania) zostaną wycofane (Error 503, więc load
balancer lub inny mechanizm - powinen przekierować te żądania do innej
działającej instancji).
Pozostaje kwestia co zrobić z wątkiem (lub wątkami), których
wykonywanie JUŻ się rozpoczęło. Taki wątek - póki co (o czym więcej za
chwilę) - NIE jest zatrzymywany, ale dostaje najmniejszy z możliwych
priorytetów. Czyli owszem, wciąż "wisi" i zabiera część czasu CPU, ale
stosunkowo mało - w każdym razie nie zablokuje kompletnie całego
procesu serwera aplikacyjnego. W skrajnym przypadku, maksymalna
liczba takich "wiszących" wątków per aplikacja jest równa liczbie
żądań, których obsługę serwer aplikacyjny zaczął (żądania przyjęte, a
nierozpoczęte będą wycofane). Czyli mniej więcej liczba ta będzie
równa liczbie wątków wykonawczych, które w danym czasie były do
dyspozycji dla danej aplikacji (czyli w praktyce ok. 50-70 per CPU, o
ile nie ograniczono dla tej aplikacji maksymalnej liczby wątków
wykonawczych - choć i ta wartość na mojego nosa byłaby możliwa jedynie
w bardzo skrajnym przypadku). Takie zablokowane wątki nie są usuwane,
będą widoczne w thread dump-ie JVM, będą obciążały CPU, choć będą
miały najniższy priorytet, więc w zasadzie będą dostawać czas
procesora tylko wtedy, gdy inne wątki, ten czas oddadzą. Aby się
pozbyć tych 'wiszących' wątków trzeba przerestartować proces serwera
aplikacyjnego (co też można zautomatyzować, np. poprzez
skonfigurowanie maksymalnej liczby takich wiszących wątków lub innych
czynników). Nie jest to sytuacja idealna, ale o niebo lepsza niż dla
schedulera, który nie pozwala takich QoS wprowadzić.
Idealnie byłoby, gdyby także te 'wiszące' wątki można było kompletnie
zatrzymać, a najlepiej jeszcze bezpiecznie usunąć. Wbrew temu co
napisałeś: w Javie DA SIĘ TO ZROBIĆ. To, że nie robią tego - a
przynajmniej NIE EKSPONUJĄ tego rodzaju możliwości DLA PROGRAMISTÓW -
obecne serwery aplikacyjne czy maszyny wirtualne, wynika z jednego
powodu: wydajność. Wątek musi być zatrzymany w tzw. bezpiecznym
stanie (safepoint). Najlepiej, żeby w zasadzie sam wątek wykrył, że
ktoś (inny wątek lub kontener) poprosił go o zatrzymanie się. To JEST
do zrobienia, ale wymaga jednego z trzech podejść:
1. na poziomie bytecode'u aplikacji w odpowiednie miejsca powstawiać
instrukcje sprawdzające czy poproszono wątek o zatrzymanie
2. powstawiać te instrukcje sprawdzające, tyle, że na poziomie
"poniżej bytecode'u" - czyli na poziomie kodu maszynowego
skompilowanego z bytecode'u
3. sterować wątkami tyle, że na poziomie schedulera w systemie
operacyjnym (co wymagałoby stworzenia w OS schedulera, który "rozumie"
JVM - pewnie łączysz już fakty - przykład MOŻLIWEJ optymalizacji,
którą "OS-y" w rodzaju JRockitVE pewnie za jakiś czas będą
implementować - na dzisiaj akurat tej JRockitVE jeszcze NIE ma).
Trudność w 1 i 2 polega na tym, że taki kod sprawdzający trzeba
wprowadzić w aplikacji w bardzo wiele miejsc - przed wywołaniem metod,
wewnątrz pętli, itd. Pewnie też trzeba odpowiednio opakować kod JNI i
wywołania metod systemowych, np. I/O (socket'y, file system, itd.).
W podejściu nr 1, należałoby skorzystać z AOP (ale implementacji
zdolnej do wyłuskania z bytecode'u pętli, odwołań do funkcji
systemowych - z tego co wiem, sprawa nie jest prosta, bo takie
struktury językowe jak pętle (while, for, ...) "giną" na poziomie
bytecode'u. Trzeba więc je z bytecode'u na nowo identyfikować i
"odtwarzać" (co robią JVM, ale popularne implementacje AOP póki co
nie). Nawet zrobienie takiej instrumentacji 'ahead of time' w opcji 1
będzie kosztowało duży spadek wydajności podczas wykonywania takiego
kodu. Ale jest to wykonalne...
W opcji nr 2, kompilator bytecode'u w JVM musiałby generować
wzbogacony o te sprawdzenia kod maszynowy. Wydajnościowo (czas
wykonania) będzie to lepsze, choć pewnie trzeba uwzględnić różnice w
architekturze CPU i systemu operacyjnego (potencjalnie dziesiątki
kombinacji). Ale plusem będzie tu przezroczystość - cokolwiek zadziała
na JVM (Groovy, Scala, JRuby, itd.) z tych możliwości wstrzymania i
zatrzymania wątków skorzysta. W każdym razie - też wykonalne.
Pewnie bardziej inteligentna analiza statyczna kodu (bytecode'u) i np.
wykrywanie skończonych pętli i niewstawianie do nich tego kodu
sprawdzającego też trochę zredukowałyby spadek wydajności. Równie
dobrze taką analizę statyczną aplikacji możnaby robić teraz i nie
robić deploymentu aplikacji, dla której analiza statyczna wykaże, że
są nieskończone pętle... Cóż, kompromisy, kompromisy, ... Tak, jak
pisałem - założenie jest takie, że serwery aplikacyjne mają wykonywać
kod zaufany...
Wariant 3 - owszem możliwy, ale praktycznie realizowalny tylko przy
takim podejściu jakiego użyto w JRockit VE - dedykowanego,
specjalizowanego "OS" dla JVM. Takiego, który ma pełną kontrolę nad
procesorem (tu wirtualnym, ale jednak). Taki "OS" daje też możliwość
kontroli działania - w tym przerywania wykonania - kodu natywnego
(JNI) i funkcji systemowych (bo to ten OS ten kod wykonuje i
implementuje funkcje systemowe - w dodatku są one napisane POD KĄTEM
JVM). Bez problemu też będzie w stanie wykonywać zatrzymywanie wątków
w bezpiecznym z punktu widzenia JVM stanie, a samo zatrzymanie jest
dokładnie takie, jakiego JVM w danej chwili potrzebuje (może być inne
na potrzeby GC, inne na potrzeby przełączania kontekstu/
wywłaszczania, a jeszcze inne na potrzeby związane z synchronizacją i
blokadami). Na normalnym OS, JVM takiego wsparcia nie dostanie...
Ten wariant jest zresztą analogią do tego co robią dzisiejsze
hypervisor'y - które pozwalają na przykład spauzować maszynę
wirtualną, czyli nie usuwać jej z pamięci, ale i nie dawać czasu
procesora (fizycznego). Może też przejąć wywołania systemowe z guest
OS'ów i zrobić z nimi dowolne rzeczy.
Z ciekawostek, to powiem, że w obecnej wersji JRockit VE ma
optymalizację dającą szybsze zatrzymywanie i startowanie wątków JVM,
ale ma to jedynie wpływ na wydajność (nie na funkcjonalność)
aplikacji. Możliwości kompletnego bezpiecznego kasowania i usuwania
wątków, a tym bardziej 'na żądanie' i żądanie z poziomu aplikacji
(serwera aplikacyjnego), jeszcze nie ma.
Książka Goetz'a o takich możliwościach nie wspomina, choć wszystkie
trzy podejścia były już w jej czasach znane (co NIE zmienia faktu, że
ta książka JEST bardzo dobra. Nie czyni też z autora ani oszusta, ani
kompletnego ignoranta przekonanego o własnej nieomylności). JavaDoc do
Thread też nie wspomina, ale cóż, to tylko Javadoc.
OFF TOPIC:
Michał - co do Twoich insynuacji, to cóż: każdy mierzy świat swoją
miarą. Autorytet ? Mi on do szczęścia potrzebny nie jest (ale rozumiem
- głodnemu chleb na myśli). A i grupa dyskusyjna to nie miejsce na
leczenie kompleksów i wyładowywanie frustracji. Ale nawet nie liczę,
że Ty to zrozumiesz...
Pozdrawiam,
Waldek Kot
Michal Kleczek
>
> Jedną z rzeczy które podkreślałem w tej części dyskusji było, że "JVM
> tego nie potrafi, serwer aplikacyjny owszem - może potrafić". Przyda
> się więc pewnie trochę precyzji.
Rzeczywiscie - przyda sie, bo nie pisales, ze "moze potrafic", lecz ze -
cytuje:
> > Natomiast serwer aplikacyjny Java EE który to
> > może zrobić, to owszem znam. Żadna nowość, bo ma to od wersji 9.0,
> > czyli ponad 4 lata.
Ale przejdzmy do meritum.
> W tej implementacji serwera
> aplikacyjnego do której ja się odnosiłem, zrobiono scheduler wątków,
> który może priorytetyzować wątki i implementować różne ich QoS.
> Minimalizując tym samym ryzyko tego, że jeden wątek może zabrać całą
> moc CPU i 'zabić' cały serwer aplikacyjny i wszystkie działające w nim
> aplikacji. Taki wątek, który przekroczy pewnen czas działania - np.
> jest w długodziałającej lub nieskończonej pętli - jest oznaczony jako
> 'stucked'. Można skonfigurować, że work manager, do którego ten wątek
> przynależy, zostanie przez serwer aplikacyjny zrestartowany. Co
> będzie skutkowało tym, że czekające w app serwerze żądania do tej
> aplikacji (czyli te, które trafiły do kolejki zadań oczekujących na
> rozpoczęcie wykonywania) zostaną wycofane (Error 503, więc load
> balancer lub inny mechanizm - powinen przekierować te żądania do innej
> działającej instancji).
>
> Pozostaje kwestia co zrobić z wątkiem (lub wątkami), których
> wykonywanie JUŻ się rozpoczęło.
Dyskusja o watkach, ktorych wykonywanie sie nie rozpoczelo jest chyba malo
ciekawa i troche nie na temat w kontekscie dyskusji o mozliwosci
zastapienia OSa przez serwer aplikacyjny.
> Taki wątek - póki co (o czym więcej za
> chwilę) - NIE jest zatrzymywany, ale dostaje najmniejszy z możliwych
> priorytetów. Czyli owszem, wciąż "wisi" i zabiera część czasu CPU, ale
> stosunkowo mało - w każdym razie nie zablokuje kompletnie całego
> procesu serwera aplikacyjnego.
Moze bardzo latwo - pamietaj, ze mowimy o blednym programie, ktory wpadl w
nieskonczona petle. Na przyklad:
Collection c = new ArrayList();
while (true) {
c.add(new Object());
}
Innymi slowy - OS (lub cos co ma OS zastepowac) MUSI umozliwiac wylaczenie
blednego programu.
> W skrajnym przypadku, maksymalna
> liczba takich "wiszących" wątków per aplikacja jest równa liczbie
> żądań, których obsługę serwer aplikacyjny zaczął (żądania przyjęte, a
> nierozpoczęte będą wycofane). Czyli mniej więcej liczba ta będzie
> równa liczbie wątków wykonawczych, które w danym czasie były do
> dyspozycji dla danej aplikacji (czyli w praktyce ok. 50-70 per CPU, o
> ile nie ograniczono dla tej aplikacji maksymalnej liczby wątków
> wykonawczych - choć i ta wartość na mojego nosa byłaby możliwa jedynie
> w bardzo skrajnym przypadku). Takie zablokowane wątki nie są usuwane,
> będą widoczne w thread dump-ie JVM, będą obciążały CPU, choć będą
> miały najniższy priorytet, więc w zasadzie będą dostawać czas
> procesora tylko wtedy, gdy inne wątki, ten czas oddadzą.
Nieprawda - gdyby JVM zarzadzala w ten sposob watkami to dochodziloby do
zaglodzenia watkow o niskich priorytetach. Na szczescie tak nie jest i to,
ze dzialaja watki o wysokich priorytetach nie powoduje, ze watki o niskich
sa calkowicie zatrzymane.
> Aby się
> pozbyć tych 'wiszących' wątków trzeba przerestartować proces serwera
> aplikacyjnego (co też można zautomatyzować, np. poprzez
> skonfigurowanie maksymalnej liczby takich wiszących wątków lub innych
> czynników). Nie jest to sytuacja idealna, ale o niebo lepsza niż dla
> schedulera, który nie pozwala takich QoS wprowadzić.
>
> Idealnie byłoby, gdyby także te 'wiszące' wątki można było kompletnie
> zatrzymać, a najlepiej jeszcze bezpiecznie usunąć. Wbrew temu co
> napisałeś: w Javie DA SIĘ TO ZROBIĆ. To, że nie robią tego - a
> przynajmniej NIE EKSPONUJĄ tego rodzaju możliwości DLA PROGRAMISTÓW -
> obecne serwery aplikacyjne czy maszyny wirtualne, wynika z jednego
> powodu: wydajność.
Nie - to nie jest jedyny powod - a nawet nie jest to powod zasadniczy.
Zasadniczym powodem jest to, ze w JVM nie da sie tego zrobic bezpiecznie.
Polecam przeczytac:
http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
i dodatkowo dokumentacje Thread.destroy()
> Wątek musi być zatrzymany w tzw. bezpiecznym
> stanie (safepoint). Najlepiej, żeby w zasadzie sam wątek wykrył, że
> ktoś (inny wątek lub kontener) poprosił go o zatrzymanie się. To JEST
> do zrobienia, ale wymaga jednego z trzech podejść:
> 1. na poziomie bytecode'u aplikacji w odpowiednie miejsca powstawiać
> instrukcje sprawdzające czy poproszono wątek o zatrzymanie
> 2. powstawiać te instrukcje sprawdzające, tyle, że na poziomie
> "poniżej bytecode'u" - czyli na poziomie kodu maszynowego
> skompilowanego z bytecode'u
Te dwie opcje sa tozsame - nie ma znaczenia, czy zmodyfikujesz bytecode, zas
pozniej kompilator go skompiluje (i zoptymalizuje), czy modyfikacje
bedziesz robil na etapie kompilacji. Jedyna roznica, to to, ze
implementacja 1 bylaby przenosna pomiedzy roznymi JVM.
> 3. sterować wątkami tyle, że na poziomie schedulera w systemie
> operacyjnym (co wymagałoby stworzenia w OS schedulera, który "rozumie"
> JVM - pewnie łączysz już fakty - przykład MOŻLIWEJ optymalizacji,
> którą "OS-y" w rodzaju JRockitVE pewnie za jakiś czas będą
> implementować - na dzisiaj akurat tej JRockitVE jeszcze NIE ma).
A moze znacznie prosciej byloby, gdyby JVM po prostu korzystala z natywnej
implementacji watkow OSa?
[ciach]
>
> Wariant 3 - owszem możliwy, ale praktycznie realizowalny tylko przy
> takim podejściu jakiego użyto w JRockit VE - dedykowanego,
> specjalizowanego "OS" dla JVM.
Ale dlaczego musi to byc specjalizowany OS dla JVM. Normalny nie moze byc?
> Takiego, który ma pełną kontrolę nad
> procesorem (tu wirtualnym, ale jednak). Taki "OS" daje też możliwość
> kontroli działania - w tym przerywania wykonania - kodu natywnego
> (JNI) i funkcji systemowych (bo to ten OS ten kod wykonuje i
> implementuje funkcje systemowe - w dodatku są one napisane POD KĄTEM
> JVM).
Ale dlaczego te funkcje musza byc specjalizowane dla JVM?
> Bez problemu też będzie w stanie wykonywać zatrzymywanie wątków
> w bezpiecznym z punktu widzenia JVM stanie,
Ale nie chodzi o zatrzymanie watku w bezpiecznym stanie "z punktu widzenia
JVM" lecz takie zatrzymanie watku, zeby INNE APLIKACJE dzialajace w tej
samej JVM byly bezpieczne. Problem polega na tym, ze ramach JVM nie
istnieje dobrze zdefiniowane pojecie aplikacji (w odroznieniu od OSa, ktory
wprowadza pojecie procesu).
Kwestia nie lezy tak naprawde w samym zatrzymaniu watku (to jest proste -
wystarczy tylko powiedziec schedulerowi, zeby wiecej danego watku juz nie
uruchamial). Problem lezy w "posprzataniu" - czyli bezpiecznym zwolnieniu
wszystkich zasobow zajetych przez watek.
Czyli np. blokad (problemy z tym zwiazane sa opisane w linku, ktory podalem
wyzej).
Ale tez pamieci. To jest duzy problem, bo w JVM zaalokowana pamiec w zaden
sposob nie jest zwiazana z zadnym watkiem.
Teoretycznie serwer J2EE wprowadza pojecie "aplikacji". Czyli jak jakis
watek sie zawiesi mozna po prostu wylaczyc cala aplikacje. Ale co ze
wspoldzielonymi obiektami (np. utworzonymi przez sterownik JDBC, lub jakis
adapter JCA) - musialyby byc one czescia serwera aplikacyjnego
(takiego "jadra") i podlegac rygorom kodu tego "jadra" (czyli przestalyby
byc modulami zewnetrznymi wobec samego serwera).
> a samo zatrzymanie jest
> dokładnie takie, jakiego JVM w danej chwili potrzebuje (może być inne
> na potrzeby GC, inne na potrzeby przełączania kontekstu/
> wywłaszczania, a jeszcze inne na potrzeby związane z synchronizacją i
> blokadami). Na normalnym OS, JVM takiego wsparcia nie dostanie...
Nie rozumiem na czym to wsparcie mialoby polegac.
> Ten wariant jest zresztą analogią do tego co robią dzisiejsze
> hypervisor'y - które pozwalają na przykład spauzować maszynę
> wirtualną, czyli nie usuwać jej z pamięci, ale i nie dawać czasu
> procesora (fizycznego).
Do zawieszania programu nie jest potrzebny zaden hypervisor.
Odpal dowolny program z konsoli Linuksa i wcisnij Ctrl+Z.
> Może też przejąć wywołania systemowe z guest
> OS'ów i zrobić z nimi dowolne rzeczy.
>
> Z ciekawostek, to powiem, że w obecnej wersji JRockit VE ma
> optymalizację dającą szybsze zatrzymywanie i startowanie wątków JVM,
> ale ma to jedynie wpływ na wydajność (nie na funkcjonalność)
> aplikacji. Możliwości kompletnego bezpiecznego kasowania i usuwania
> wątków, a tym bardziej 'na żądanie' i żądanie z poziomu aplikacji
> (serwera aplikacyjnego), jeszcze nie ma.
Wlasnie... Czyli - jak na razie - OSa zastapic nie moze.
Zupelnie inna kwestia jest, czy jest sens wywazac otwarte drzwi i
implementowac funkcjonalnosc systemu operacyjnego w JVM? Moim zdaniem to
nie ma sensu - dla mnie nie ma problemu z odpalaniem wielu JVM w ramach
jednego systemu operacyjnego i wykorzystywaniu udostepnianych przez ten OS
mechanizmow IPC do ich wspoldzialania. Ma to taka zalete, ze w ramach tego
samego OS moge uruchomic np. RDBMS lub inny program, z ktorym aplikacje
Java maja wspoldzialac i nie potrzebuje do tego zadnych hypervisorow.
>
> Książka Goetz'a o takich możliwościach nie wspomina, choć wszystkie
> trzy podejścia były już w jej czasach znane (co NIE zmienia faktu, że
> ta książka JEST bardzo dobra. Nie czyni też z autora ani oszusta, ani
> kompletnego ignoranta przekonanego o własnej nieomylności).
Nikt nie pisal o Goetzu jako o oszuscie ani ignorancie - proba przypisania
mi takich stwierdzen jest nie fair.
> OFF TOPIC:
> Michał - co do Twoich insynuacji, to cóż: każdy mierzy świat swoją
> miarą. Autorytet ? Mi on do szczęścia potrzebny nie jest (ale rozumiem
> - głodnemu chleb na myśli). A i grupa dyskusyjna to nie miejsce na
> leczenie kompleksów i wyładowywanie frustracji. Ale nawet nie liczę,
> że Ty to zrozumiesz...
Moje frustracje nie maja tu nic do rzeczy. Pisales nieprawde (a nawet sie
przy niej upierales), wiec to skomentowalem.
Wybacz ostre slowa, ale czasem w dyskusji sa one potrzebne. I - jak wydaje
mi sie - w tym przypadku pomogly. Zaczela sie merytoryczna i - IMHO -
interesujaca rozmowa, zamiast nie wprowadzajacych nic ciekawego zachwytow
nad istniejacymi (i nieistniejacymi) cechami konkretnych produktow.
--
Michal
Waldek Kot
> > Pozostaje kwestia co zrobić z wątkiem (lub wątkami), których
> > wykonywanie JUŻ się rozpoczęło.
>
> Dyskusja o watkach, ktorych wykonywanie sie nie rozpoczelo jest chyba malo
> ciekawa i troche nie na temat w kontekscie dyskusji o mozliwosci
> zastapienia OSa przez serwer aplikacyjny.
W kontekście kontenera takiego jak serwer aplikacyjny owszem, jest to
ważne, żeby wycofać zadania, które zostały przyjęte do wykonania, ale
ich wykonanie jeszcze się nie zaczęło. A przynajmniej ważne z punktu
widzenia końcowego użytkownika takiej aplikacji - wysłane przez niego
żądanie zostanie przekierowane do innego serwera aplikacyjnego w
klastrze. Pomijając timeout'y, jest duża szansa, że taki request
będzie poprawnie obsłużony...
Wariant zastąpienia OS przez serwer aplikacyjny NIE był rozważany.
Natomiast możliwość zastąpienia generycznego OS-a specjalizowanym OS-
em dla serwerowych JVM, tak...
> > Taki wątek - póki co (o czym więcej za
> > chwilę) - NIE jest zatrzymywany, ale dostaje najmniejszy z możliwych
> > priorytetów. Czyli owszem, wciąż "wisi" i zabiera część czasu CPU, ale
> > stosunkowo mało - w każdym razie nie zablokuje kompletnie całego
> > procesu serwera aplikacyjnego.
>
> Moze bardzo latwo - pamietaj, ze mowimy o blednym programie, ktory wpadl w
> nieskonczona petle. Na przyklad:
>
> Collection c = new ArrayList();
> while (true) {
> c.add(new Object());
>
> }
OK - ja raczej skupiłem się na zasobie pt. CPU, niż na zasobie pt.
"Java heap". W Twoim przykładzie mamy zresztą do czynienia z memory
leak i GC JVM z nim sobie nie poradzi. Analizy memory leak w czasie
rzeczywistym też się (dzisiaj jeszcze) nie robi z powodu (utraty)
wydajności...
> > W skrajnym przypadku, maksymalna
> > liczba takich "wiszących" wątków per aplikacja jest równa liczbie
> > żądań, których obsługę serwer aplikacyjny zaczął (żądania przyjęte, a
> > nierozpoczęte będą wycofane). Czyli mniej więcej liczba ta będzie
> > równa liczbie wątków wykonawczych, które w danym czasie były do
> > dyspozycji dla danej aplikacji (czyli w praktyce ok. 50-70 per CPU, o
> > ile nie ograniczono dla tej aplikacji maksymalnej liczby wątków
> > wykonawczych - choć i ta wartość na mojego nosa byłaby możliwa jedynie
> > w bardzo skrajnym przypadku). Takie zablokowane wątki nie są usuwane,
> > będą widoczne w thread dump-ie JVM, będą obciążały CPU, choć będą
> > miały najniższy priorytet, więc w zasadzie będą dostawać czas
> > procesora tylko wtedy, gdy inne wątki, ten czas oddadzą.
>
> Nieprawda - gdyby JVM zarzadzala w ten sposob watkami to dochodziloby do
> zaglodzenia watkow o niskich priorytetach. Na szczescie tak nie jest i to,
> ze dzialaja watki o wysokich priorytetach nie powoduje, ze watki o niskich
> sa calkowicie zatrzymane.
Zgadza się - napisałem, że byłoby idealnie, gdyby takie zablokowane
wątki były całkowicie zatrzymane, a najlepiej jeszcze usunięte.
Działają, ale na najniższym możliwym priorytecie (przyznam, że nawet
przy braku możliwości całkowitego usunięcia takiego wątku, byłoby
fajnie móc przynajmniej skonfigurować per aplikacja, żeby taki wątek w
ogóle nie dostawał czasu procesora. Jak widać jednak uznano, że tak
robić nie warto - kolejny kompromis). Co do priorytetów i zagładzania,
to oczywiście - masz rację - priorytet to priorytet, zagłodzenia nie
ma (ta część mojego zdania rozpoczynała się od "w zasadzie ..." i być
może zabrakło precyzji).
> > Idealnie byłoby, gdyby także te 'wiszące' wątki można było kompletnie
> > zatrzymać, a najlepiej jeszcze bezpiecznie usunąć. Wbrew temu co
> > napisałeś: w Javie DA SIĘ TO ZROBIĆ. To, że nie robią tego - a
> > przynajmniej NIE EKSPONUJĄ tego rodzaju możliwości DLA PROGRAMISTÓW -
> > obecne serwery aplikacyjne czy maszyny wirtualne, wynika z jednego
> > powodu: wydajność.
>
> Nie - to nie jest jedyny powod - a nawet nie jest to powod zasadniczy.
> Zasadniczym powodem jest to, ze w JVM nie da sie tego zrobic bezpiecznie.
> Polecam przeczytac:http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDepreca...
>
> i dodatkowo dokumentacje Thread.destroy()
Nie zgodzę się tu Michał. Ten JavaDoc odnosi się do JEDNEJ
implementacji JVM - Sun HotSpot i do KONKRETNEJ wersji JDK. JVM, w
której zaimplementowano by te trzy podane opcje (generacja bytecode'u,
modyfikacja kodu natywnego, OS "rozumiejący" JVM - a pewnie i inne
pomysły rozwiązujące ten problem) i które wystawiłoby takie API "na
zewnątrz" nie wydają się żadnym science fiction. Podtrzymuję, że na
przeszkodzie w budowie takiego JVM stoi głównie wydajność (pewnie
warto też wziąć pod uwagę biznesowe aspekty, że producentów JVM -
przynajmniej takich JVM, jak te na których działają serwery Java EE -
jest mało - i coraz mniej ;-) - a i JVM to nie produkt, na którym
można specjalnie zarobić...). Tym co jest w JDK też rządzą trochę
inne "prawa" niż czysta technologia - nadzieja na zdrową konkurencję
i innowacje ze strony OpenJDK i Apache Harmony. W każdym razie nie ma
technicznych ograniczeń w samym JVM.
Żeby nie być gołosłownym, to odwołam się do prac polskich naukowców
Grzegorza Czajkowskiego i Krzysztofa Palacza, dotyczących Application
Isolatates (nawet JSR-a się doczekały - JSR-121), Multitasking VM (MVM
- http://java.sun.com/developer/technicalArticles/Programming/mvm/) i
słynnego projektu Sun Barcelona (http://research.sun.com/projects/
barcelona/). Oczywiście, nie widać kontynuacji tych projektów od
strony biznesowej (jakiś udział może mieć tu to, że G. Czajkowski nie
jest już pracownikiem Sun, tylko Google, gdzie, jeśli dobrze
zrozumiałem, zajmuje się MapReduce - a kto wie, może i też - to
najczystsza spekulacja - Google JVM ;-)). Tym niemniej - od strony
technologicznej są to dowody na to, że jednak "w JVM da się to
zrobić". MVM to jednak JVM tyle, że po stosownych modyfikacjach.
Takich przykładów można znaleźć więcej - każdemu polecam zostać
członkiem ACM (http://acm.org) i kupić sobie dostęp do http://portal.acm.org.
Nieprzebrane źródło bardzo dobrych - w większości naukowych -
opracowań. Także materiały z konferencji (np. OOPSLA). Nie tylko o
Java. Na acm.org wciąż Polska figuruje jako "economically developing
country" - podobnie jak Gabon ;-). Dla studentów to oznacza 18 USD na
rok.
> > Wątek musi być zatrzymany w tzw. bezpiecznym
> > stanie (safepoint). Najlepiej, żeby w zasadzie sam wątek wykrył, że
> > ktoś (inny wątek lub kontener) poprosił go o zatrzymanie się. To JEST
> > do zrobienia, ale wymaga jednego z trzech podejść:
> > 1. na poziomie bytecode'u aplikacji w odpowiednie miejsca powstawiać
> > instrukcje sprawdzające czy poproszono wątek o zatrzymanie
> > 2. powstawiać te instrukcje sprawdzające, tyle, że na poziomie
> > "poniżej bytecode'u" - czyli na poziomie kodu maszynowego
> > skompilowanego z bytecode'u
>
> Te dwie opcje sa tozsame - nie ma znaczenia, czy zmodyfikujesz bytecode, zas
> pozniej kompilator go skompiluje (i zoptymalizuje), czy modyfikacje
> bedziesz robil na etapie kompilacji. Jedyna roznica, to to, ze
> implementacja 1 bylaby przenosna pomiedzy roznymi JVM.
Tożsame raczej nie, ale oczywiście - dosyć podobne. Myślę jednak, że
od strony wydajności lepszych efektów należałoby spodziewać się w tym
podejściu z generacją kodu natywnego. Zanim kompilator bytecode'u
"wypluje" z siebie finalny kod maszynowy, to dokonuje sporej liczby
optymalizacji i powinien być w stanie bardziej inteligentnie
powstawiać te odwołania dotyczące ewentualnego zatrzymania wątku. Na
przykład dzięki takim optymalizacjom jak rozwijanie pętli, czy
usuwanie dead code, liczba tych sprawdzeń mogłaby być znacznie
mniejsza. To co jest w tym podejściu wadą (=brak przenośności),
potencjalnie byłby też i zaletą - skorzystanie z możliwości OS (i ew.
sprzętu) w "lepszym" (np. szybszym) zatrzymywaniu takiego wątku i
"czyszczeniu" użytych przez niego zasobów (np. funkcji I/O). Jeśli
wątek "wisiałby" na wolnodziałającym I/O (np. socket przez który
przepychany jest terabajt danych), to OS-owi potencjalnie będzie
łatwiej bezpiecznie zamknąć takie I/O.
Inna sprawa - bardziej dotycząca ekosystemu Java - to to, że chyba z
punktu widzenia narzędzi do debugowania też lepiej byłoby nie pakować
tego dodatkowego kodu sprawdzającego do bytecode'u. Nie byłoby też
specjalnie potrzeby modyfikować standardowych narzędzi (np. javac).
> > 3. sterować wątkami tyle, że na poziomie schedulera w systemie
> > operacyjnym (co wymagałoby stworzenia w OS schedulera, który "rozumie"
> > JVM - pewnie łączysz już fakty - przykład MOŻLIWEJ optymalizacji,
> > którą "OS-y" w rodzaju JRockitVE pewnie za jakiś czas będą
> > implementować - na dzisiaj akurat tej JRockitVE jeszcze NIE ma).
>
> A moze znacznie prosciej byloby, gdyby JVM po prostu korzystala z natywnej
> implementacji watkow OSa?
JVM-y zwykle z natywnych wątków OS korzystają - jeśli w Twojej
wypowiedzi chodziło o green threads vs. native threads. Jeśli nie o to
chodziło, to niezbyt widzę, jak ZWYKŁY (=nie rozumiejący JVM) OS
miałby BEZPIECZNIE (z punktu widzenia Java, zasobów JVM, itd)
zatrzymać wątek ?
JRockit VE pełni rolę OS-a - i to on "dostarcza" wątków dla JVM. I na
tym ma polegać udogodnienie, że zarządzanie wątków jest robione w
sposób dopasowany do JVM. Podawałem już (realny) przykład z
zatrzymywaniem wątków tak, jak "pasuje" to danemu algorytmowi GC. Inne
pomysły (z mojej głowy, co planują deweloperzy w JRockit w tym
zakresie, to nie wiem):
- skrócenie czasu powoływania wątku przez skorzystanie z puli wątków i
prealokacji/preinicjalizacji typowych struktur danych przez te wątki
używanych (w końcu i tak jest zawsze tylko jeden proces w tym "OS". W
dodatku, wiemy, że ten proces to JVM. Mówimy też o serwerowej Javie,
więc na 99.9% pewności będzie konstruowana pula wątków. Znacznie mniej
mamy tu przypadkowości, więc można z tego skorzystać)
- bardziej inteligentny locking wątków - skoro JVM "wie" które wątki
wiszą na blokadzie i "wie" który wątek trzyma tę blokadę, a "OS" wie
który wątek na którym procesorze działa, to dlaczegóżby z tego nie
skorzystać - JVM mógłby poprosić "OS" o przyspieszenie schedulowania
tego blokującego wątku ?
Doprawdy, the sky is the limit...
> > Wariant 3 - owszem możliwy, ale praktycznie realizowalny tylko przy
> > takim podejściu jakiego użyto w JRockit VE - dedykowanego,
> > specjalizowanego "OS" dla JVM.
>
> Ale dlaczego musi to byc specjalizowany OS dla JVM. Normalny nie moze byc?
[...]
> Ale dlaczego te funkcje musza byc specjalizowane dla JVM?
Musieć nie muszą, ale w praktyce trudno to inaczej zrobić. Microsoft,
Sun, czy deweloperzy kernela linuksowego, raczej takich specjalnych
optymalizacji dla Java nie wprowadzą - ani do jądra, ani do bibliotek
systemowych. Łatwiej to zrobić poprzez stworzenie dedykowanego "OS".
A dzięki hypervisorom, stworzenie takiego dedykowanego "OS" jest
bardzo ułatwione (nie piszę, że łatwe, ale łatwiejsze. Główne
ułatwienie: nie trzeba babrać się ze sterownikami do sprzętu - 60%
jądra Linuxa to sterowniki do sprzętu). Wracając do tego przykładu z
bezpiecznym zatrzymywaniem wątków - dla tych wątków które wiszą na
funkcjach systemowych (np. I/O) - to OS musi bezpiecznie przerwać
wykonywanie takiej funkcji systemowej (JVM do tego poziomu nie ma
dostępu, choć JVM mógłby wystawić deweloperom Java API do tego, aby
takie operacje na wątkach robić...).
> > Bez problemu też będzie w stanie wykonywać zatrzymywanie wątków
> > w bezpiecznym z punktu widzenia JVM stanie,
>
> Ale nie chodzi o zatrzymanie watku w bezpiecznym stanie "z punktu widzenia
> JVM" lecz takie zatrzymanie watku, zeby INNE APLIKACJE dzialajace w tej
> samej JVM byly bezpieczne.
Wydaje mi się, że nie powinno być chyba zbytniem różnicy między
zatrzymaniem wątku bezpiecznie "z punktu widzenia JVM" a "z punktu
widzenia innych wątków".
> Kwestia nie lezy tak naprawde w samym zatrzymaniu watku (to jest proste -
> wystarczy tylko powiedziec schedulerowi, zeby wiecej danego watku juz nie
> uruchamial). Problem lezy w "posprzataniu" - czyli bezpiecznym zwolnieniu
> wszystkich zasobow zajetych przez watek.
> Czyli np. blokad (problemy z tym zwiazane sa opisane w linku, ktory podalem
> wyzej).
Zgadza się. Na tym polega ten kompromis, że wątki oznaczają lepszą
wydajność i skalowalność, ale kosztem komplikacji w zarządzaniu
zasobami. OS też w zasadzie po wątkach "nie sprząta", po prostu usuwa
wszelkie struktury procesu i zwalnia używane przez niego (w tym przez
jego wątki) zasoby. Co do śledzenia zasobów, to oczywiście - aby móc
je posprzątać, trzeba je śledzić. Wracając do tezy o tym co jest
główną przeszkodą, że dzisiejsze JVM tego nie robią - to kosztuje to
wydajność i pamięć.
Co do zwalniania blokad, to w tych podejściach które opisywałem -
zwłaszcza 1 i 2 - chodzi o to, aby wątek sam się zakończył
("kooperatywnie wyskoczył z metody run()") - ten kod "wyjścia z run"
też można wygenerować i wstawić w bytecode/kod maszynowy metody
"run". Wtedy, blokady się pozwalniają i poprawne alokacje wątku też
zostaną usunięte. Alokacje typu "memory leak" :) i inne niepoprawne
użycia zasobów, oczywiście nie. Tu znowu wydajność stoi na
przeszkodzie, aby wykonywać tak głęboką analizę (śledzenie zasobów,
czy analizę statyczną) w trakcie działania programu. Podawany
wcześniej przykład MVM wprowadził takie konstrukcje, aby to czego
używa Isolate (najczęściej jednak realizowany w postaci wątku) było
śledzone, a przynajmniej - tak jak to ma miejsce w procesie - ubite
wraz z ubiciem Isolate.
> Ale tez pamieci. To jest duzy problem, bo w JVM zaalokowana pamiec w zaden
> sposob nie jest zwiazana z zadnym watkiem.
Nie wiem, czy dobrze zrozumiałem, ale w tę stronę, którą opisałeś
(tzn. zaalokowana pamięć jest związana z wątkiem), to zgoda. W drugą
(tzn. wątek wie, które obszary pamięci zaalokował), to już nie.
Inaczej garbage collector'y nie mogłyby działać (a przynajmniej te
GC, które korzystają z techniki 'mark&sweep' - pomijam te używające
reference counting). W tym sensie, obszary w Java heap do których NIE
prowadzą referencje do obiektów ze stosu wątków i/lub JNI będą
usunięte. Stos wątku ubitego (lub oznaczonego jako do ubicia) nie
będzie brany pod uwagę w ramach fazy 'mark' przy garbage collection,
więc te obszary pamięci będą odzyskane.
Inna sprawa, że zwłaszcza serwerowe JVM (bo tu efektywne zarządzanie
wątkami jest szczególnie istotne) mogą stosować podział Java heap na
tzw. thread local areas (TLA), w których umieszczane są obiekty
alokowane przez dany wątek. Ponieważ zdecydowana większość takich
obiektów nie jest współdzielona między wątkami, usunięcie/
wyczyszczenie takiego obszaru odzyskuje zaalokowaną przez wątek
pamięć. Referencje do obiektów współdzielonych między wątkami mogą być
traktowane specjalnie (w serwerowych aplikacjach Java takich
referencji będzie stosunkowo mało) - także podczas czyszczenia pamięci
po wątku. JVM wie do którego wątku dane TLA należy...
Najgorzej jest oczywiście ze śledzeniem alokacji wykonywanych w ramach
kodu natywnego w JNI. Tu mógłby pomóc OS i je śledzić. Najlepiej
jeszcze OS "rozumiejący" JNI/JVM ;-))...
> > a samo zatrzymanie jest
> > dokładnie takie, jakiego JVM w danej chwili potrzebuje (może być inne
> > na potrzeby GC, inne na potrzeby przełączania kontekstu/
> > wywłaszczania, a jeszcze inne na potrzeby związane z synchronizacją i
> > blokadami). Na normalnym OS, JVM takiego wsparcia nie dostanie...
>
> Nie rozumiem na czym to wsparcie mialoby polegac.
Trochę już tych pomysłów podałem, np. inteligentny locking wątków.
Mając informacje zarówno "z poziomu JVM", jak i "poziomu OS", można
podjąć decyzję, czy takie wiszące na blokadzie wątki lepiej uśpić, czy
lepiej wprowadzić je w spinning (niech się "pokręcą" i co określony
interwał czasu sprawdzają, czy blokada już jest zwolniona - czasem
wydajniej jest pozwolić wątkowi się kręcić niż go usypiać a potem
budzić). Sposób zatrzymywania wątków może być też zgrany ze sposobem
działania konkretnego algorytmu GC i potencjalnie może znacznie
działanie tego algorytmu przyspieszyć. Skoro GC polega na czyszczeniu
pewnego obszaru pamięci (Java heap), a niskopoziomowe zarządzanie
pamięcią robi "OS" (jego podsystemy Virtual Memory Manager i Physical
Memory Manager), to skoordynowanie obydwu może dać ciekawe
optymalizacje. Inaczej z VMM/PMM korzystają wątki GC, a inaczej wątki
aplikacyjne. O takie wsparcie mi chodziło.
> > Ten wariant jest zresztą analogią do tego co robią dzisiejsze
> > hypervisor'y - które pozwalają na przykład spauzować maszynę
> > wirtualną, czyli nie usuwać jej z pamięci, ale i nie dawać czasu
> > procesora (fizycznego).
>
> Do zawieszania programu nie jest potrzebny zaden hypervisor.
> Odpal dowolny program z konsoli Linuksa i wcisnij Ctrl+Z.
No, tak, ale chodziło mi tylko o analogię - to, że poprzez
wprowadzenie hypervisor'a i oddzielenie OS od fizycznego sprzętu,
można robić ciekawe rzeczy - w pewnym sensie "oszukiwać" OS, np.
dynamicznie zmieniać ilość zasobów, które ten OS "myśli, że ma".
Zasobów w rodzaju CPU czy pamięć RAM. Takich rzeczy jak np. migracja
pomiędzy fizycznymi komputerami działającego OS i znajdujących się w
nim procesów, bez ich zatrzymywania (a nawet zauważenia faktu
migracji), to bez hypervisora łatwo się nie zrobi... A przynajmniej ja
takiej kombinacji klawiszy w OS-ie nie znam ;-)
> > Z ciekawostek, to powiem, że w obecnej wersji JRockit VE ma
> > optymalizację dającą szybsze zatrzymywanie i startowanie wątków JVM,
> > ale ma to jedynie wpływ na wydajność (nie na funkcjonalność)
> > aplikacji. Możliwości kompletnego bezpiecznego kasowania i usuwania
> > wątków, a tym bardziej 'na żądanie' i żądanie z poziomu aplikacji
> > (serwera aplikacyjnego), jeszcze nie ma.
>
> Wlasnie... Czyli - jak na razie - OSa zastapic nie moze.
Zgadza się - i powtórzę się (bo coś nie mogę się u Ciebie z tym
komunikatem przebić): nie ma zastępować OS. Zależnie co się rozumie
pod pojęciem "OS" - JRockit VE jest albo namiastką OS (co ja osobiście
wolę) albo wręcz: jest OS-em. Specjalizowanym. Dla Java. Serwerowej
Java. Pod hypervisorem.
> Zupelnie inna kwestia jest, czy jest sens wywazac otwarte drzwi i
> implementowac funkcjonalnosc systemu operacyjnego w JVM? Moim zdaniem to
> nie ma sensu - dla mnie nie ma problemu z odpalaniem wielu JVM w ramach
> jednego systemu operacyjnego i wykorzystywaniu udostepnianych przez ten OS
> mechanizmow IPC do ich wspoldzialania. Ma to taka zalete, ze w ramach tego
> samego OS moge uruchomic np. RDBMS lub inny program, z ktorym aplikacje
> Java maja wspoldzialac i nie potrzebuje do tego zadnych hypervisorow.
OK. To już trochę przerabialiśmy i chyba najlepszą odpowiedzią będzie,
że trzeba tu wrócić do korzyści z wirtualizacji w ogóle...
Dodam też drobną korektę, że aż tak daleko, żeby implementować OS w
JVM, to deweloperzy JRockit VE nie poszli. JVM działa na JRockit VE.
Sam JVM (tu jest to JRockit JVM) jest niemodyfikowana (czyli zadziała
zarówno na normalnym OS - Linux, jak i na takim "OS" jak JRockit VE).
Zaleta, którą podajesz jest oczywiście prawdziwa - tyle, że taka
konieczność, aby uruchamiać w ramach jednej maszyny więcej niż jeden
proces w produkcyjnych środowiskach serwerowej Java (np. Java EE) nie
jest duża. Łatwo też ją obejść (zdalny dostęp do tych zasobów). A przy
tym, można skorzystać z korzyści wirtualizacji.
OFF TOPIC:
> > Książka Goetz'a o takich możliwościach nie wspomina, choć wszystkie
> > trzy podejścia były już w jej czasach znane (co NIE zmienia faktu, że
> > ta książka JEST bardzo dobra. Nie czyni też z autora ani oszusta, ani
> > kompletnego ignoranta przekonanego o własnej nieomylności).
>
> Nikt nie pisal o Goetzu jako o oszuscie ani ignorancie - proba przypisania
> mi takich stwierdzen jest nie fair.
Uległem emocjom - "MSPANC" ;-) - i zastosowałem "logikę", którą i Ty
wtedy użyłeś w swojej wypowiedzi: Goetz nie napisał, że w JVM można
takie rzeczy robić (i bezpiecznie ubijać wątki), więc...
> Moje frustracje nie maja tu nic do rzeczy. Pisales nieprawde (a nawet sie
> przy niej upierales), wiec to skomentowalem.
> Wybacz ostre slowa, ale czasem w dyskusji sa one potrzebne. I - jak wydaje
> mi sie - w tym przypadku pomogly. Zaczela sie merytoryczna i - IMHO -
> interesujaca rozmowa, zamiast nie wprowadzajacych nic ciekawego zachwytow
> nad istniejacymi (i nieistniejacymi) cechami konkretnych produktow.
Michał, te słowa, które napisałeś o oszustwie i doszukiwanie się
drugiego dna były niepotrzebne. Nie chcę Cię pouczać, ale można
wyrażać odmienne zdanie w mniej ostry sposób. Nie znamy się, więc i Ty
prawa do pouczania mnie za pomocą ostrych słów czy czegokolwiek innego
nie masz. Do posiadania odmiennego zdania - jak najbardziej tak.
Inaczej, to albo nie będzie dyskusji, albo będzie przerzucanie się
inwektywami. Grupa dyskusyjna w internecie daje to słodkie poczucie,
że można pozwolić sobie na ostrzejsze zachowania, ale jest wręcz
przeciwnie - trzeba się bardziej powstrzymywać...
Pewnie inni czytelnicy niż ja powinni się tu wypowiedzieć, ale
specjalnego braku "merytoryki" w moich wypowiedziać nie dostrzegłem. I
nawet gdybym gdzieś się mylił, to hmm.. no big deal...
Co do moich zachwytów - tak, szczerze mnie ta tematyka pasjonuje (a
biorąc pod uwagę reakcje innych osób wiem, że temat wirtualizacji
Java interesuje wielu. Interesuje technologicznie, nie biznesowo - i
to też był główny powód mojej decyzji o pokazaniu tej technologii na
konferencji GeeCon 2009 w Krakowie). To, że mój aktualny pracodawca
dostarcza te technologie, nie ma tu żadnego znaczenia. KAŻDY gdzieś
pracuje i idąc tym tropem ZAWSZE możnaby się tego drugiego dna
doszukiwać w wypowiedzi KAŻDEJ osoby. Pachnie paranoją. Podobnie, za
każdą technologią - open source czy nie - stoją ludzie. Można im
zarzucać niecne zamiary, ale można też ich zachwyty składać na karb
zaangażowania w dany projekt. Można też mieć podziw i szacunek dla
tego co robią inni. Staram się trzymać tego, że kwestie biznesowe/
handlowe to NTG (Nie Ta Grupa). Informacja o tym gdzie aktualnie
pracuję jest dostępna publicznie w moim profilu na tej grupie, więc
uważam, że sprawa jest czysta (no hidden agenda). Jak ktoś z góry
zakłada drugie dno, to owszem - te informacje mogą działać na niego
jak czerwona płachta na byka (zbieżność kolorów przypadkowa ;-)).
Przyznam też, że raczej rzadko słyszę zarzuty o stronniczość, a z
całkiem sporą liczbą pasjonatów Java mam przyjemność spotykać się
podczas JUG-ów, czy konferencji... Zauważ, że w moich wypowiedziach
dość często używam zwrotów "NA PRZYKŁADZIE produktu X". Cieszy mnie,
gdy ktoś napisze że "produkt Y też ma taką funkcjonalność", bo to
poszerza moją wiedzę.
Jak prześledzisz wpisy na moim blogu, czy zobaczysz dobór tematów na
konferencjach społecznościowych w których jestem zaproszony jako
speaker, to zauważysz, że dominują w nich dosyć offowe tematy (choć
wciąż innowacje) - SIP i SIP Servlet, CEP - Complex Event Processing,
Comet/Bayeux, teraz - wirtualizacja Java. Pewnie, że możesz przypiąć
do tego łatkę "komercyjne produkty", ale można też to potraktować jako
zasygnalizowanie ciekawych rzeczy dziejących się w społeczności Java.
A mnie to prostu cieszy. Mam też satysfakcję, że parę prac na studiach
zostało tymi tematami zainspirowanych...
Kończąc - bardzo, bardzo liczę na to, że dzięki temu, że Java i JVM
są open source oraz że są dostępne dobre open source'owe rozwiązania
wirtualizacyjne (np. Xen) i OS-y (np. Linux), tego rodzaju innowacje
w Java, jak "zwirtualizowana JVM" będą się pojawiać - także i w tych
open source'owych implementacjach (może dzięki temu, że ktoś napisze
pracę inżynierską lub magisterską na podobny temat ? Może ten ktoś
będzie studentem polskiej uczelni ? Może założy fajny start-up ?).
Wciąż jeszcze bardzo wiele ciekawych rzeczy można zrobić w Java /JVM i
"niemożliwe" zamienić w "fajne"...
Pozdrawiam,
Waldek Kot
Wojciech Jaczewski
>> A moze znacznie prosciej byloby, gdyby JVM po prostu korzystala z
>> natywnej implementacji watkow OSa?
>
> JVM-y zwykle z natywnych w�tk�w OS korzystaj� - je�li w Twojej
> wypowiedzi chodzi�o o green threads vs. native threads. Je�li nie o to
> chodzi�o, to niezbyt widz�, jak ZWYK�Y (=nie rozumiej�cy JVM) OS
> mia�by BEZPIECZNIE (z punktu widzenia Java, zasob�w JVM, itd)
> zatrzyma� w�tek ?
�eby bezpiecznie zatrzymywa� w�tek, OS musia�by rozumie� intencj�
programisty, a niekoniecznie rozumieďż˝ JVM.
Po to w systemach operacyjnych jest podzia� na procesy, aby programista m�g�
wyrazi� swoj� intencj�: je�li tworzy jeden proces i w nim ile� w�tk�w, to
ubicie w�tku w niew�a�ciwym momencie mo�e zepsu� dzia�anie ca�ego procesu.
Je�li tworzy si� osobne procesy, to oznacza �e mo�na ubi� jeden proces w
dowolnym momencie, pozostawiaj�c pozosta�e w poprawnym stanie.
> - skr�cenie czasu powo�ywania w�tku przez skorzystanie z puli w�tk�w i
> prealokacji/preinicjalizacji typowych struktur danych przez te w�tki
> u�ywanych
Zdecydowanie, czy skorzysta� z puli w�tk�w, a je�li tak, to z jak du�ej, to
zadanie programisty a nie OS.
> - bardziej inteligentny locking w�tk�w - skoro JVM "wie" kt�re w�tki
> wisz� na blokadzie i "wie" kt�ry w�tek trzyma t� blokad�, a "OS" wie
> kt�ry w�tek na kt�rym procesorze dzia�a, to dlaczeg�by z tego nie
> skorzysta� - JVM m�g�by poprosi� "OS" o przyspieszenie schedulowania
> tego blokuj�cego w�tku ?
OS bez JVM te� wie, kt�ry w�tek wisi na kt�rej blokadzie. Czy z tej wiedzy
korzysta - nie mam poj�cia. Je�li nie korzysta, to zapewne z tego powodu,
�e bardzo trudno to zrealizowa� praktycznie.
> Doprawdy, the sky is the limit...
To mo�e jeszcze ten OS z JVM-em powinien wykrywa�, �e programista wybra�
nieoptymalny algorytm do danego zadania? I podmienia� go na w�a�ciwy.
>> > Wariant 3 - owszem mo�liwy, ale praktycznie realizowalny tylko przy
>> > takim podej�ciu jakiego u�yto w JRockit VE - dedykowanego,
>> > specjalizowanego "OS" dla JVM.
>>
>> Ale dlaczego musi to byc specjalizowany OS dla JVM. Normalny nie moze
>> byc?
> [...]
>> Ale dlaczego te funkcje musza byc specjalizowane dla JVM?
>
> Musieďż˝ nie muszďż˝, ale w praktyce trudno to inaczej zrobiďż˝. Microsoft,
> Sun, czy deweloperzy kernela linuksowego, raczej takich specjalnych
> optymalizacji dla Java nie wprowadz� - ani do j�dra, ani do bibliotek
> systemowych. �atwiej to zrobi� poprzez stworzenie dedykowanego "OS".
Jakie, przyk�adowo, specjalizowane funkcje ju� wprowadzono w dedykowanych
OS?
> Zgadza si�. Na tym polega ten kompromis, �e w�tki oznaczaj� lepsz�
> wydajno�� i skalowalno��, ale kosztem komplikacji w zarz�dzaniu
> zasobami.
Pod warunkiem, �e te w�tki intensywnie korzystaj� ze wsp�lnych danych. W
przeciwnym przypadku nie maj� �adnej wydajno�ciowej przewagi nad procesami.
Nie rozumiem te�, dlaczego w�tki mia�yby by� bardziej skalowalne -
niezale�nie, czy operuj� na wsp�lnych danych, czy na osobnych. Nawet s�dz�,
�e korzystanie z osobnych proces�w prowokuje do robienia bardziej
skalowalnego oprogramowania - minimalizowania wymiany danych pomi�dzy
poszczeg�lnymi procesami.
Michal Kleczek
[ciach]
>
> Wariant zastąpienia OS przez serwer aplikacyjny NIE był rozważany.
> Natomiast możliwość zastąpienia generycznego OS-a specjalizowanym OS-
> em dla serwerowych JVM, tak...
Mam wrazenie, ze jakos inaczej definiujemy pojecie "OS" i stad pewne
niezrozumienie. Zeby program mogl byc nazwany OSem musi spelniac pewne
funkcje. Bez wnikania w szczegoly jego glowna funkcja jest umozliwienie
innym programom (aplikacjom) jednoczesnego i bezpiecznego korzystania z
_fizycznego_ sprzetu (hardware). W tym sensie OSem mozemy nazwac:
1) hypervisor - wtedy aplikacjami sa wirtualne maszyny
2) inny progam (np. jadro linuksa) - wtedy aplikacja jest np. JVM
3) JVM - wtedy aplikacjami sa hmm... dobre pytanie, co mozna nazwac
aplikacja
4) serwer J2EE dzialajacy w ramach JVM - wtedy aplikacjami mozna nazwac
komponenty J2EE (eary, wary i inne) instalowane i uruchamiane na takim
serwerze.
>
>>
>> Nie - to nie jest jedyny powod - a nawet nie jest to powod zasadniczy.
>> Zasadniczym powodem jest to, ze w JVM nie da sie tego zrobic bezpiecznie.
>> Polecam
>>
przeczytac:http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDepreca...
>>
>> i dodatkowo dokumentacje Thread.destroy()
>
>
> Nie zgodzę się tu Michał. Ten JavaDoc odnosi się do JEDNEJ
> implementacji JVM - Sun HotSpot i do KONKRETNEJ wersji JDK.
Nie - to sa problemy _inherentne_ dla JVM (znowu - klania sie definicja
JVM - to jest program zgodny ze specyfikacja JVM).
> JVM, w
> której zaimplementowano by te trzy podane opcje (generacja bytecode'u,
> modyfikacja kodu natywnego, OS "rozumiejący" JVM - a pewnie i inne
> pomysły rozwiązujące ten problem) i które wystawiłoby takie API "na
> zewnątrz" nie wydają się żadnym science fiction.
Oczywiscie - mozna zrobic taka maszyne wirtualna, ale:
1. trzeba zmienic (byc moze tylko rozszerzyc) specyfikacje JVM
2. zasadne jest pytanie, czy jest sens to robic
> Żeby nie być gołosłownym, to odwołam się do prac polskich naukowców
> Grzegorza Czajkowskiego i Krzysztofa Palacza, dotyczących Application
> Isolatates (nawet JSR-a się doczekały - JSR-121), Multitasking VM (MVM
> - http://java.sun.com/developer/technicalArticles/Programming/mvm/) i
> słynnego projektu Sun Barcelona (http://research.sun.com/projects/
> barcelona/).
Wszystko to bardzo fajnie, ale to jest wlasnie _rozszerzenie_ standardu.
Co wazniejsze - wlasnie w MVM wprowadza sie pojecie "isolate" (koncepcyjnie
jest to dokladnie to samo co "proces" w OSie typu Unix czy Windows) i
dopiero zdefiniowanie takiego pojecia pozwala na sensowne rozwazanie
zastosowania JVM jako systemu operacyjnego.
Proba zrobienia z JVM OSa _bez_ tego rodzaju modyfikacji jest skazana na
niepowodzenie (chociaz mozna probowac sztuczek z modyfikacja bytecodu
itp.).
Co ciekawe - materialy dotyczace Isolate API (nie pomne w tej chwili linkow)
wspominaja, ze:
1) API jest tak skonstruowane, zeby mozna bylo je zaimplementowac po prostu
uruchamiajac wiele instancji JVM (procesow) w ramach OSa
2) taka implementacja Isolate API jest najprostsza, zas ewentualne inne
implementacje sa przedmiotem badan - bo tak naprawde wcale nie wiadomo, czy
przynioslyby jakiekolwiek korzysci. Innymi slowy nalezy sie zastanowic, czy
powielac funkcjonalnlosc istniejacych OSow w JVM, czy _skorzystac_ z tej
funkcjonalnosci (co zapewne wymagaloby zmian w JVM, ktore likwidowalyby
znana od lat piete achillesowa Javy - dlugi czas uruchamiania JVM i spory
apetyt na zasoby - jaskolke widac w postaci 6u10 tylko pytanie czy to nie
jest za pozno)
[ciach]
>> Kwestia nie lezy tak naprawde w samym zatrzymaniu watku (to jest proste -
>> wystarczy tylko powiedziec schedulerowi, zeby wiecej danego watku juz nie
>> uruchamial). Problem lezy w "posprzataniu" - czyli bezpiecznym zwolnieniu
>> wszystkich zasobow zajetych przez watek.
>> Czyli np. blokad (problemy z tym zwiazane sa opisane w linku, ktory
>> podalem wyzej).
>
> Zgadza się. Na tym polega ten kompromis, że wątki oznaczają lepszą
> wydajność i skalowalność, ale kosztem komplikacji w zarządzaniu
> zasobami. OS też w zasadzie po wątkach "nie sprząta", po prostu usuwa
> wszelkie struktury procesu i zwalnia używane przez niego (w tym przez
> jego wątki) zasoby.
To jest wlasnie "sprzatanie".
> Co do śledzenia zasobów, to oczywiście - aby móc
> je posprzątać, trzeba je śledzić. Wracając do tezy o tym co jest
> główną przeszkodą, że dzisiejsze JVM tego nie robią - to kosztuje to
> wydajność i pamięć.
> Co do zwalniania blokad, to w tych podejściach które opisywałem -
> zwłaszcza 1 i 2 - chodzi o to, aby wątek sam się zakończył
> ("kooperatywnie wyskoczył z metody run()") - ten kod "wyjścia z run"
> też można wygenerować i wstawić w bytecode/kod maszynowy metody
> "run".
Polecam jednak przeczytanie dlaczego _obydwie_ metody Thread.destroy() i
Thread.stop() sa "deprecated". Po prostu nie mozna bezpiecznie ani zwolnic
wszystkich blokad, ani ich zostawic.
I nie ma znaczenia, ze kod zatrzymywania watku jest wstawiany przez jakis
generator, bo ten wygenerowany kod musi przyjac strategie taka, jak w
Thread.destroy(), albo taka jak w Thread.stop().
> Wtedy, blokady się pozwalniają i poprawne alokacje wątku też
> zostaną usunięte. Alokacje typu "memory leak" :) i inne niepoprawne
> użycia zasobów, oczywiście nie. Tu znowu wydajność stoi na
> przeszkodzie, aby wykonywać tak głęboką analizę (śledzenie zasobów,
> czy analizę statyczną) w trakcie działania programu. Podawany
> wcześniej przykład MVM wprowadził takie konstrukcje, aby to czego
> używa Isolate (najczęściej jednak realizowany w postaci wątku) było
> śledzone, a przynajmniej - tak jak to ma miejsce w procesie - ubite
> wraz z ubiciem Isolate.
Czyli innymi slowy MVM wprowadza pojecie zbioru zasobow - a to jest to samo
co "proces". I dokladnie tak jak w OSie te zasoby nie moga byc
wspoldzielone pomiedzy isolates (koncepcyjnie oczywiscie, OS moze robic
optymalizacje typu wspoldzielenie segmentow pamieci tylko do odczytu
itp.) - wlasnie po to, zeby mozna bylo je bezpiecznie zwolnic.
>
>> Ale tez pamieci. To jest duzy problem, bo w JVM zaalokowana pamiec w
>> zaden sposob nie jest zwiazana z zadnym watkiem.
>
> Nie wiem, czy dobrze zrozumiałem, ale w tę stronę, którą opisałeś
> (tzn. zaalokowana pamięć jest związana z wątkiem), to zgoda. W drugą
> (tzn. wątek wie, które obszary pamięci zaalokował), to już nie.
> Inaczej garbage collector'y nie mogłyby działać (a przynajmniej te
> GC, które korzystają z techniki 'mark&sweep' - pomijam te używające
> reference counting). W tym sensie, obszary w Java heap do których NIE
> prowadzą referencje do obiektów ze stosu wątków i/lub JNI będą
> usunięte. Stos wątku ubitego (lub oznaczonego jako do ubicia) nie
> będzie brany pod uwagę w ramach fazy 'mark' przy garbage collection,
> więc te obszary pamięci będą odzyskane.
Chodzi mi o to, ze nie mozna wnioskowac, ze mozna zwolnic jakis fragment
pamieci tylko dlatego, ze zostal zaalokowany przez watek, ktory zakonczyl
swoje dzialanie - bo pamiec jest wspodzielonoa pomiedzy watkami. Co
powoduje, ze "ubicie" watku moze bardzo latwo prowadzic do memory leakow.
> Inna sprawa, że zwłaszcza serwerowe JVM (bo tu efektywne zarządzanie
> wątkami jest szczególnie istotne) mogą stosować podział Java heap na
> tzw. thread local areas (TLA), w których umieszczane są obiekty
> alokowane przez dany wątek. Ponieważ zdecydowana większość takich
> obiektów nie jest współdzielona między wątkami, usunięcie/
> wyczyszczenie takiego obszaru odzyskuje zaalokowaną przez wątek
> pamięć. Referencje do obiektów współdzielonych między wątkami mogą być
> traktowane specjalnie (w serwerowych aplikacjach Java takich
> referencji będzie stosunkowo mało) - także podczas czyszczenia pamięci
> po wątku. JVM wie do którego wątku dane TLA należy...
Patrz wyzej - nie da sie uniknac memory leakow. W aplikacjach serwerowych to
jest _katastrofa_ , bo one maja dzialac dlugo, bardzo dlugo...
> Najgorzej jest oczywiście ze śledzeniem alokacji wykonywanych w ramach
> kodu natywnego w JNI. Tu mógłby pomóc OS i je śledzić. Najlepiej
> jeszcze OS "rozumiejący" JNI/JVM ;-))...
>
>> > a samo zatrzymanie jest
>> > dokładnie takie, jakiego JVM w danej chwili potrzebuje (może być inne
>> > na potrzeby GC, inne na potrzeby przełączania kontekstu/
>> > wywłaszczania, a jeszcze inne na potrzeby związane z synchronizacją i
>> > blokadami). Na normalnym OS, JVM takiego wsparcia nie dostanie...
>>
>> Nie rozumiem na czym to wsparcie mialoby polegac.
>
> Trochę już tych pomysłów podałem, np. inteligentny locking wątków.
Czyli?
>>
>> Wlasnie... Czyli - jak na razie - OSa zastapic nie moze.
>
> Zgadza się - i powtórzę się (bo coś nie mogę się u Ciebie z tym
> komunikatem przebić): nie ma zastępować OS. Zależnie co się rozumie
> pod pojęciem "OS" - JRockit VE jest albo namiastką OS (co ja osobiście
> wolę) albo wręcz: jest OS-em. Specjalizowanym. Dla Java. Serwerowej
> Java. Pod hypervisorem.
OK - czyli hypervisor+JRockitVE+JRockit+WLS to jest system operacyjny.
Specjalizowany. Dla Java. Serwerowej Java.
Tyle, ze badziewny :)
>
>> Zupelnie inna kwestia jest, czy jest sens wywazac otwarte drzwi i
>> implementowac funkcjonalnosc systemu operacyjnego w JVM? Moim zdaniem to
>> nie ma sensu - dla mnie nie ma problemu z odpalaniem wielu JVM w ramach
>> jednego systemu operacyjnego i wykorzystywaniu udostepnianych przez ten
>> OS mechanizmow IPC do ich wspoldzialania. Ma to taka zalete, ze w ramach
>> tego samego OS moge uruchomic np. RDBMS lub inny program, z ktorym
>> aplikacje Java maja wspoldzialac i nie potrzebuje do tego zadnych
>> hypervisorow.
>
> OK. To już trochę przerabialiśmy i chyba najlepszą odpowiedzią będzie,
> że trzeba tu wrócić do korzyści z wirtualizacji w ogóle...
> Dodam też drobną korektę, że aż tak daleko, żeby implementować OS w
> JVM, to deweloperzy JRockit VE nie poszli. JVM działa na JRockit VE.
> Sam JVM (tu jest to JRockit JVM) jest niemodyfikowana (czyli zadziała
> zarówno na normalnym OS - Linux, jak i na takim "OS" jak JRockit VE).
> Zaleta, którą podajesz jest oczywiście prawdziwa - tyle, że taka
> konieczność, aby uruchamiać w ramach jednej maszyny więcej niż jeden
> proces w produkcyjnych środowiskach serwerowej Java (np. Java EE) nie
> jest duża.
No wlasnie koniecznosc uruchamiania wielu aplikacji na jednym fizycznym
komputerze jest oczywista. Jest bez znaczenia, czy to beda aplikacje
(procesy) w ramach jednego OS, czy maszyny wirtualne w ramach jednego
hypervisora, czy tez aplikacje J2EE w ramach jednego kontenera J2EE - efekt
jest ten sam - wiele programow dzialajacych jednoczesnie na jednym
komputerze.
Tak swoja droga - po tej dyskusji zaczynam sie zastanawiac - jak juz
powstana te "specjalizowane OSy" mogace dzialac na konkretnym "wirtualnym
sprzecie" (np. VMWare), to ile czasu minie zanim palaca potrzeba stanie sie
wirtualizacja hypervisorow.
Jak duzo musi sie zmienic, zeby wszystko zostalo po staremu...
--
Michal
Waldek Kot
> >> A moze znacznie prosciej byloby, gdyby JVM po prostu korzystala z
> >> natywnej implementacji watkow OSa?
>
> > wypowiedzi chodziło o green threads vs. native threads. Jeśli nie o to
> > chodziło, to niezbyt widzę, jak ZWYKŁY (=nie rozumiejący JVM) OS
> > miałby BEZPIECZNIE (z punktu widzenia Java, zasobów JVM, itd)
> > zatrzymać wątek ?
>
> programisty, a niekoniecznie rozumieć JVM.
I tak, i nie. JVM też musi wykonywać sporo operacji (choćby GC), które
wymagają odpowiedniego zatrzymania wątków. W dyskusji chodziło o to,
żeby zatrzymanie wątku było możliwe także wtedy, gdy programista tego
nie przewidział (Michał podał przykład z nieskończoną pętlą np. "while
(true) {}").
> Po to w systemach operacyjnych jest podział na procesy, aby programista mógł
> wyrazić swoją intencję: jeśli tworzy jeden proces i w nim ileś wątków, to
> ubicie wątku w niewłaściwym momencie może zepsuć działanie całego procesu.
> Jeśli tworzy się osobne procesy, to oznacza że można ubić jeden proces w
> dowolnym momencie, pozostawiając pozostałe w poprawnym stanie.
Z tym, że dyskusja dotyczyła serwerowych aplikacji Java,
korzystających z serwerów aplikacyjnych i takiego modelu budowy
aplikacji jak Java EE... Deweloper aplikacji Java EE ma raczej mały
wpływ na konstrukcję serwera aplikacyjnego i działanie jego mechanizmu
puli wątków wykonawczych...
> > - skrócenie czasu powoływania wątku przez skorzystanie z puli wątków i
> > prealokacji/preinicjalizacji typowych struktur danych przez te wątki
> > używanych
>
> Zdecydowanie, czy skorzystać z puli wątków, a jeśli tak, to z jak dużej, to
> zadanie programisty a nie OS.
Nie wiem Wojtku na ile przeczytałeś wcześniejsze posty, bo to moje
zdanie trzeba umieścić we właściwym kontekście. Tu chodziło o jedną z
potencjalnych optymalizacji jakie taki specjalizowany-dla-JVM OS może
dawać w przypadku serwerowych aplikacji Java. Te aplikacje - niemal na
pewno - będą posługiwać się pulą wątków (przykład: serwer aplikacyjny
Java EE). Stąd, taki "OS" może wykonać prealokację/preinicjaliację/
cachowanie/itd struktur na poziomie OS-a, do obsługi takiej puli. Cel
jest jeden - skrócić czas przydziału i zatrzymywania wątków. Sposób
działania tych operacji też może zależeć od tego co aktualnie JVM robi
- GC, scheduling, itd.
Zmieniając więc trochę temat: co do rozmiaru puli wątków, to też
zależy - w przypadku takiej implementacji puli wątków jaka jest
używana w serwerze aplikacyjnym WebLogic Server, rozmiar tej puli NIE
jest ustalany bezpośrednio przez człowieka (a już na pewno nie przez
programistę aplikacji Java EE, która ma w tym serwerze działać).
Rozmiar puli wątków zależy tu od wielu czynników, w tym od historii
obsługi danej aplikacji. Pula może rosnąć i maleć w zależności od tych
czynników. Oczywiście - można tu pewne parametry podać (np. w ramach
QoS podać min/max liczbę wątków używanych przez aplikację). Te
wartości Quality of Service można zresztą podać "per aplikacja", ale
też "per komponent aplikacji (np. servlet, czy EJB)". Można nawet
"per użytkownik", czy "per grupa użytkowników" (np. grupa
administratorzy). To są też bardziej hint'y niż sztywne wartości.
Czasem to są dosyć "nieoczywiste" parametry, w rodzaju oczekiwania,
że średni czas odpowiedzi danego komponentu (np. servlet'u) ma być
większy/mniejszy niż czas odpowiedzi innego komponentu. To serwer
aplikacyjny ma "wymyśleć" jak najlepiej sprostać takiemu oczekiwaniu
(przy czym nie ma gwarancji, że tak się właśnie stanie -> to jest hint/
oczekiwanie). Przykład z życia wzięty: servlet do obsługi zapytań
AJAX który dopowiada dalszą część wpisanego tekstu w pole tekstowe na
formularze powinien mieć QoS nastawione na czas odpowiedzi i to w
miarę krótki czas. Servlet generujący (dynamicznie) stronę
internetową zawierającą opis jakiegoś produktu takich restrykcji na
czas odpowiedzi raczej nie będzie miał (będzie raczej "nastawiony" na
maksymalną przepustowość, ewentualnie z przypisaniem min/max liczby
wątków). Można też przypisać, że żądania wyświetlenia tej strony
pochodzące od użytkowników należących do grupy "Gold Customer" będą
miały wyższy priorytet niż te pochodzące od użytkowników "Anonymous".
Tak więc - wracając do Twojego komentarza - wszystko zależy od
kontekstu.
> > - bardziej inteligentny locking wątków - skoro JVM "wie" które wątki
> > wiszą na blokadzie i "wie" który wątek trzyma tę blokadę, a "OS" wie
> > który wątek na którym procesorze działa, to dlaczegóżby z tego nie
> > skorzystać - JVM mógłby poprosić "OS" o przyspieszenie schedulowania
> > tego blokującego wątku ?
>
> OS bez JVM też wie, który wątek wisi na której blokadzie. Czy z tej wiedzy
> korzysta - nie mam pojęcia. Jeśli nie korzysta, to zapewne z tego powodu,
> że bardzo trudno to zrealizować praktycznie.
Blokady po stronie aplikacji Java i po stronie OS, to są dwa różne
światy (m.in. nie zawsze "blokada" w JVM, to to samo, co "blokada" w
OS). OS tego świata który jest w JVM nie widzi. Relacja która wydaje
się tu słuszna, to: JVM może korzystać z pewnych mechanizmów
współbieżności i synchronizacji oferowanych przez OS i sprzęt. Tyle,
że dzisiejsze JVM zdecydowaną większość mechanizmów synchronizacji
wątków starają się wykonać tak, aby w minimalnym stopniu skorzystać z
mechanizmów oferowanych w tym zakresie przez OS - szczególnie z
monitorów (jak to gdzieś wyczytałem - monitory dostarczane przez OS są
traktowane przez JVM jako "heavyweight" i dąży się do tego, aby używać
ich jak najrzadziej). Takie JVM stosują na przykład spinning wątku
(chwilowe kręcenie się w pętli) w sytuacji, gdy wątek próbuje dostać
się do już zajętej blokady (oczywiście - spinning ma sens wtedy, gdy
JVM działa na maszynie z wieloma CPU/core - albo przynajmniej SMT/
hyperthreading). Dopiero, gdy spinning trwa zbyt długo, JVM usypia ten
czekający wątek (i korzysta z monitora OS). Czyli - wracając do tego
pomysłu na optymalizację: w pewnych sytuacjach (np. kilku wątków
żądających tej samej blokady) zamiast (w ogóle albo zbyt długo)
"kręcić" wątkiem, JVM mógłby poprosić "OS" o próbę dania czasu
procesora wątkowi, który trzyma blokadę (podkreślam słowo "próbę" - są
zapewne sytuacje, gdy takie wcześniejsze schedulowanie blokującego
wątku nie będzie możliwe). Sens tej optymalizacji byłby taki, żeby:
- zminimalizować czas kręcenia się wątków (podczas spinningu wątek nie
wykonuje kodu aplikacyjnego)
- zminimalizować liczbę usypianych wątków (bo usypianie i budzenie
wątków są stosunkowo kosztownymi operacjami - używają struktur OS)
W efekcie potencjalnie liczba blokad powinna się zmniejszych, a całość
działać w bardziej zrównoleglony sposób. W kontekście sprawienia żeby
Java była bardziej deterministyczna (aplikacje real-time), mogę sobie
wyobrazić dodanie do tej optymalizacji priorytetów wątków (np. wątki
samej JVM - np. do obsługi GC - bądź wątki aplikacyjne wykonujące kod
o bardziej real-time'owej charakterystyce miałyby wyższy priorytet i
większą "agresywność" w aplikowaniu tej optymalizacji).
Podsumowując: taka optymalizacja, czyli w ogólności zgranie obydwu
światów (JVM i OS) wydaje mi się praktycznie realizowalny tylko, jeśli
stosowne modyfikacje wprowadzi się do "OS". Te modyfikacje muszą być
specyficzne (=dla JVM). Stąd potrzeba specjalizowanego "OS" (ścieżka z
wprowadzaniem tych zmian do Windows, Linux, czy Solaris wydaje mi się
znacznie trudniejsza - także z powodów politycznych: kod Windows zna
tylko Microsoft; wątpię by rządzący kernelem Linuxa chcieli wprowadzać
optymalizacje specyficzne dla jednej technologii.
> > Doprawdy, the sky is the limit...
>
> To może jeszcze ten OS z JVM-em powinien wykrywać, że programista wybrał
> nieoptymalny algorytm do danego zadania? I podmieniać go na właściwy.
ALEŻ TO CAŁKIEM REALNE !!! Polecam poczytać o projektach robionych w
amerykańskiej National Security Agency: zwirtualizowanej sztucznej
inteligencji i algorytmach hyper-genetycznych (hyper = skrót od
hypervisor) ! Więcej informacji na stronach NSA: http://coding-by-talking.nsa.gov.
> >> Ale dlaczego musi to byc specjalizowany OS dla JVM. Normalny nie moze
> >> byc?
> > [...]
> >> Ale dlaczego te funkcje musza byc specjalizowane dla JVM?
>
> > Musieć nie muszą, ale w praktyce trudno to inaczej zrobić. Microsoft,
> > Sun, czy deweloperzy kernela linuksowego, raczej takich specjalnych
> > optymalizacji dla Java nie wprowadzą - ani do jądra, ani do bibliotek
> > systemowych. Łatwiej to zrobić poprzez stworzenie dedykowanego "OS".
>
> Jakie, przykładowo, specjalizowane funkcje już wprowadzono w dedykowanych
> OS?
Ta specjalizacja dotyczy kilku "poziomów":
- specyficzne implementacje funkcji systemowych (np. wywołań
Posix'owych) - w przypadku JRockit VE dokonano re-implementacji
wszystkich tych funkcji systemowych systemu operacyjnego, których JVM
(tu linuksowa wersja JRockit JVM) od używa.
- parawirtualizację (czyli skorzystanie z faktu, że pod JVM/VE jest
hypervisor - np. wykorzystanie jego hypercall's)
- założenia jądra OS (o których pisałem w jednym z pierwszych postów):
single-user, single-process, niemal wszystko wykonuje się w user-mode
(czyli minimalizacja tranzycji między user a kernel space), prostsze
mechanizmy VMM/PMM
Przykład trochę innego poziomu specjalizacji podałem powyżej, przy
okazji omawiania pomysłu na bardziej inteligentny scheduling wątków. Z
tym, że nie mam informacji, czy i na ile takie głębsze
parawirtualizowanie JVM (=uczynienie JVM "świadomej", że pod spodem
jest specjalizowany OS) jest już stosowane. Z tego co wiem, to na
razie sama JVM (tu: JRockit JVM) nie została zmodyfikowana (to jest
ta sama binarka, która zadziała na Linux-ie). Takie dodatkowe
funkcjonalności jak serwer SSH są uruchamiane poprzez Java agent
(czyli też powinny zadziałać na normalnym OS).
> > Zgadza się. Na tym polega ten kompromis, że wątki oznaczają lepszą
> > wydajność i skalowalność, ale kosztem komplikacji w zarządzaniu
> > zasobami.
>
> Pod warunkiem, że te wątki intensywnie korzystają ze wspólnych danych. W
> przeciwnym przypadku nie mają żadnej wydajnościowej przewagi nad procesami.
> Nie rozumiem też, dlaczego wątki miałyby być bardziej skalowalne -
> niezależnie, czy operują na wspólnych danych, czy na osobnych. Nawet sądzę,
> że korzystanie z osobnych procesów prowokuje do robienia bardziej
> skalowalnego oprogramowania - minimalizowania wymiany danych pomiędzy
> poszczególnymi procesami.
Tu znowu - trzeba to zdanie o wydajności i skalowalności umieścić w
kontekście całej dyskusji - mówimy o serwerowych aplikacjach
(przykład: aplikacje webowe), szczególnie tych umieszczonych wewnątrz
serwera aplikacyjnego. Zachodzi tu zatem ten pierwszy warunek który
podałeś. Dodałbym jeszcze do niego i to, że komunikacja między wątkam
tego samego procesu jest znacznie szybsza, niż komunikacja między
procesami. Żądania do takich aplikacji które podałem są od siebie
niezależne. Powoływanie nowego procesu dla każdego z żądań (a nawet
utrzymywanie puli procesów - co też zakłada komunikację
międzyprocesową i konieczność zrobienia wydajnego dispatcher'a żądań
do procesów) źle by się skończyło dla wydajności takich aplikacji
(powołanie wątku jest lekką operacją w stosunku do operacji powołania
nowego procesu - utrzymanie puli wątków też jest lżejsze niż
utrzymanie puli procesów, itd). Nieprzypadkowo wątki nazywa się w
literaturze lightweight processes...
Powoływanie nowych procesów (serwera aplikacyjnego, czy tego
mechanizmu, który zarządza pulą wątków) też jest pewnym pomysłem na
skalowanie takich aplikacji. Zarówno powoływanie nowych procesów na
tej samej maszynie, jak i dodawanie maszyn i powoływanie tych procesów
na nich.
Pozdrawiam,
Waldek Kot
PS
Wybaczcie małą ściemę z tą "zwirtualizowaną sztuczną
inteligencją" ;-)). Chociaż...
Waldek Kot
> > Wariant zastąpienia OS przez serwer aplikacyjny NIE był rozważany.
> > Natomiast możliwość zastąpienia generycznego OS-a specjalizowanym OS-
> > em dla serwerowych JVM, tak...
>
> Mam wrazenie, ze jakos inaczej definiujemy pojecie "OS" i stad pewne
> niezrozumienie. Zeby program mogl byc nazwany OSem musi spelniac pewne
> funkcje. Bez wnikania w szczegoly jego glowna funkcja jest umozliwienie
> innym programom (aplikacjom) jednoczesnego i bezpiecznego korzystania z
> _fizycznego_ sprzetu (hardware).
Czyli Windows bądź Linux działający jako guest OS w maszynie
wirtualnej hypervisor'a przestaje być OS-em ? Nie wiem czy Linus
pogodziłby się z takim potraktowaniem ;-). Bo w większości
implementacji hypervisor'ów sprzęt wystawiany w ramach guest VM (dla
guest OS) - jest wirtualny (za wyjątkiem CPU).
Natomiast, ja też mam pewien problem z tym czy JRockit VE jest czy nie
jest OS (stąd umieszczam go w kategorii "OS" - OS w cudzysłowiu). No
bo jest to guest OS, umożliwia działanie innym aplikacjom (ale tylko
jednej, i tylko JVM) i zarządza _wirtualnym_ sprzętem. Z drugiej
strony nie ma dosyć dzisiaj elementarnych cech, choćby obsługi wielu
użytkowników...
> >> Nie - to nie jest jedyny powod - a nawet nie jest to powod zasadniczy.
> >> Zasadniczym powodem jest to, ze w JVM nie da sie tego zrobic bezpiecznie.
> >> Polecam przeczytac:http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDepreca...
> >> i dodatkowo dokumentacje Thread.destroy()
>
> > Nie zgodzę się tu Michał. Ten JavaDoc odnosi się do JEDNEJ
> > implementacji JVM - Sun HotSpot i do KONKRETNEJ wersji JDK.
>
> Nie - to sa problemy _inherentne_ dla JVM (znowu - klania sie definicja
> JVM - to jest program zgodny ze specyfikacja JVM).
Zmotywowałeś mnie do przeglądnięcia zarówno Java Virtual Machine
Specification (http://java.sun.com/docs/books/jvms/) jak i Java
Language Specification (http://java.sun.com/docs/books/jls/). Może źle
patrzę, ale takich zapisów świadczących o _inherentności_ tego
problemu w JVM NIE dostrzegam.
Przywołany przeze mnie wcześniej przykład MVM też w żaden sposób nie
narusza tych specyfikacji i jest pełnoprawną JVM.
Skąd więc ta opinia o inherentności tego problemu w JVM ?
> > JVM, w
> > której zaimplementowano by te trzy podane opcje (generacja bytecode'u,
> > modyfikacja kodu natywnego, OS "rozumiejący" JVM - a pewnie i inne
> > pomysły rozwiązujące ten problem) i które wystawiłoby takie API "na
> > zewnątrz" nie wydają się żadnym science fiction.
>
> Oczywiscie - mozna zrobic taka maszyne wirtualna, ale:
> 1. trzeba zmienic (byc moze tylko rozszerzyc) specyfikacje JVM
Żadna z podanych przeze mnie opcji nie narusza specyfikacji JVM.
Zresztą - czysto teoretycznie - jedyną opcją o którą byłby sens o to
podejrzewać jest opcja 1 (generowanie bytecode'u i wklejanie go w
odpowiednie miejsca aplikacji). To NIE narusza specyfikacji JVM (nowe
opcode'y nie są potrzebne, do zrealizowania tego zadania). Opcje 2 i 3
są w ogóle poza specyfikacją JVM.
MVM też nie zmienia specyfikacji JVM. Owszem, dodaje nowe API na
poziomie JDK (ale to też nie zasługuje mi na uzasadnienie "problem
inherentny dla JVM").
> 2. zasadne jest pytanie, czy jest sens to robic
Zgadza się. Na dzisiaj, dla typowych rodzajów aplikacji raczej nie.
Koszt (=wydajność) zbyt duży. Piszę to z przykrością, ale JSR-121
wydaje się być martwy... Kto wie, może specjalizowane OS-y coś tu
wniosą...
> > Żeby nie być gołosłownym, to odwołam się do prac polskich naukowców
> > Grzegorza Czajkowskiego i Krzysztofa Palacza, dotyczących Application
> > Isolatates (nawet JSR-a się doczekały - JSR-121), Multitasking VM (MVM
> > - http://java.sun.com/developer/technicalArticles/Programming/mvm/) i
> > słynnego projektu Sun Barcelona (http://research.sun.com/projects/
> > barcelona/).
>
> Wszystko to bardzo fajnie, ale to jest wlasnie _rozszerzenie_ standardu.
Owszem, jest to rozszerzenie JDK, ale żadnej groźby tu nie widzę. Ot,
dodatkowe API. Z takimi roszerzeniami mamy do czynienia stale.
> Co wazniejsze - wlasnie w MVM wprowadza sie pojecie "isolate" (koncepcyjnie
> jest to dokladnie to samo co "proces" w OSie typu Unix czy Windows) i
> dopiero zdefiniowanie takiego pojecia pozwala na sensowne rozwazanie
> zastosowania JVM jako systemu operacyjnego.
> Proba zrobienia z JVM OSa _bez_ tego rodzaju modyfikacji jest skazana na
> niepowodzenie (chociaz mozna probowac sztuczek z modyfikacja bytecodu
> itp.).
Próba, której nie było...
Opcje 2 i 3 są z punktu widzenia tego co napisałeś mniej "inwazyjne" i
nie wprowadzają dodatkowych konstrukcji, aby zapewnić bezpieczniejsze
zarządzanie wątkami.
> Co ciekawe - materialy dotyczace Isolate API (nie pomne w tej chwili linkow)
> wspominaja, ze:
> 1) API jest tak skonstruowane, zeby mozna bylo je zaimplementowac po prostu
> uruchamiajac wiele instancji JVM (procesow) w ramach OSa
Dokładniej, to pozwalają zrealizować koncepcję Isolate przy pomocy
różnych mechanizmów, w tym w szczególności zarówno w postaci procesów,
jak i w postaci wątków.
Warto przytoczyć, że specyfikacja JVM do zrealizowania wątków Java też
nie narzuca żadnej implementacji - są implementacje wątków Java przy
pomocy:
- procesów OS (o ile się nie mylę - przykład SAP JVM),
- wątków OS (mainstream: Sun HotSpot, Oracle/BEA JRockit, IBM, HP-
UX, ...)
- innych (w szczególności przykład green threads)
Z założenia, implementator JVM ma bardzo dużą dowolność realizacji
JVM.
> 2) taka implementacja Isolate API jest najprostsza, zas ewentualne inne
> implementacje sa przedmiotem badan - bo tak naprawde wcale nie wiadomo, czy
> przynioslyby jakiekolwiek korzysci.
Najprostsza na pewno, czy przydatna w praktyce wątpię (bo zarówno z
green threads, jak i implementacji wątków Java poprzez procesy OS,
wycofano się. Są oczywiście niszowe zastosowania, gdzie takie
podejścia mogą mieć sens. W mainstream'owej Java - zwłaszcza na
serwerze nie wydaje się).
Z tego co ja czytałem o MVM, to implementacja bazowała na wątkach OS,
czyli - tak jak w typowych JVM: pojedynczy MVM był widoczny w OS jako
1 proces, wewnątrz MVM można było uruchamiać wiele aplikacji ("metod
main"), poszczególne aplikacje działały jako wątki systemu
operacyjnego.
> > Zgadza się. Na tym polega ten kompromis, że wątki oznaczają lepszą
> > wydajność i skalowalność, ale kosztem komplikacji w zarządzaniu
> > zasobami. OS też w zasadzie po wątkach "nie sprząta", po prostu usuwa
> > wszelkie struktury procesu i zwalnia używane przez niego (w tym przez
> > jego wątki) zasoby.
>
> To jest wlasnie "sprzatanie".
Chodziło mi o to, że czasem trzeba bardziej inteligentnie potraktować
usuwanie niektórych zasobów używanych przez wątki (czy proces). Wiele
z tych zasobów OS też nie śledzi (i nie wie jak "posprzątać"). Plików
tymczasowych utworzonych przez wątek/proces sam z siebie nie usunie.
Zadań batchowych zainicjowanych przez wątek/proces na zdalnej maszynie
też sam nie przerwie... Itd.
> > Co do śledzenia zasobów, to oczywiście - aby móc
> > je posprzątać, trzeba je śledzić. Wracając do tezy o tym co jest
> > główną przeszkodą, że dzisiejsze JVM tego nie robią - to kosztuje to
> > wydajność i pamięć.
> > Co do zwalniania blokad, to w tych podejściach które opisywałem -
> > zwłaszcza 1 i 2 - chodzi o to, aby wątek sam się zakończył
> > ("kooperatywnie wyskoczył z metody run()") - ten kod "wyjścia z run"
> > też można wygenerować i wstawić w bytecode/kod maszynowy metody
> > "run".
>
> Polecam jednak przeczytanie dlaczego _obydwie_ metody Thread.destroy() i
> Thread.stop() sa "deprecated". Po prostu nie mozna bezpiecznie ani zwolnic
> wszystkich blokad, ani ich zostawic.
> I nie ma znaczenia, ze kod zatrzymywania watku jest wstawiany przez jakis
> generator, bo ten wygenerowany kod musi przyjac strategie taka, jak w
> Thread.destroy(), albo taka jak w Thread.stop().
W opcji 1 i 2 chodzi o trochę inne "wyjście" z wątku, niż to o którym
piszesz. Ten kod zatrzymywania wątku nie musi używać metod stop/
destroy - może być wstawiony do metody run() i pozwolić bezpiecznie z
niej wyjść - tym samym pozwalniać blokady, itd. Bezpiecznie, czyli
tak, jakby po prostu metoda run() się skończyła. Na tym ma polegać ta
"kooperacja" z wątkiem, który ma być zatrzymywany (to tak, jakby
wewnątrz Twojej nieskończonej pętli wstawić if-a sprawdzającego flagę
żądania zatrzymania i jeśli jest ona ustawiona na 'true', to wyskoczyć
z pętli. Po dojściu do końca metody run() wątek zakończy działanie,
więc zostaną pozwalniane zasoby i tak dalej).
> > Inna sprawa, że zwłaszcza serwerowe JVM (bo tu efektywne zarządzanie
> > wątkami jest szczególnie istotne) mogą stosować podział Java heap na
> > tzw. thread local areas (TLA), w których umieszczane są obiekty
> > alokowane przez dany wątek. Ponieważ zdecydowana większość takich
> > obiektów nie jest współdzielona między wątkami, usunięcie/
> > wyczyszczenie takiego obszaru odzyskuje zaalokowaną przez wątek
> > pamięć. Referencje do obiektów współdzielonych między wątkami mogą być
> > traktowane specjalnie (w serwerowych aplikacjach Java takich
> > referencji będzie stosunkowo mało) - także podczas czyszczenia pamięci
> > po wątku. JVM wie do którego wątku dane TLA należy...
>
> Patrz wyzej - nie da sie uniknac memory leakow. W aplikacjach serwerowych to
> jest _katastrofa_ , bo one maja dzialac dlugo, bardzo dlugo...
Z tym, że chodzi o bezpieczne ubicie, czyli takie, które ryzyko memory
leak'ów wyeliminuje (pomijam tu błędy programistów - aplikacji,
kontenera, czy JVM). Ten przykład z TLA miał służyć pokazaniu tego, że
narzut na takie śledzenie wykorzystania pamięci przez wątki można
bardzo mocno ograniczyć. Zdecydowana większość alokacji wątku będzie
się toczyła w ramach jego TLA. Niewielka liczba współdzielonych
obiektów będzie specjalnie traktowana (m.in. kosztem dodatkowych
struktur pamięci i czasu CPU).
Memory leak JVM czy kontenera są nieporównanie rzadsze niż memory leak
aplikacji. Dobre praktyki deweloperskie i narzędzia (zarówno analiza
kodu, jak i runtime'owe) pozwalają sobie z tym problemem dosyć dobrze
radzić...
> >> Nie rozumiem na czym to wsparcie mialoby polegac.
>
> > Trochę już tych pomysłów podałem, np. inteligentny locking wątków.
>
> Czyli?
Koncepcję opisałem we wcześniejszym poście (odpowiedzi do Wojtka
Jaczewskiego z 19.maja).
> OK - czyli hypervisor+JRockitVE+JRockit+WLS to jest system operacyjny.
> Specjalizowany. Dla Java. Serwerowej Java.
> Tyle, ze badziewny :)
Ehh... :-)
> Tak swoja droga - po tej dyskusji zaczynam sie zastanawiac - jak juz
> powstana te "specjalizowane OSy" mogace dzialac na konkretnym "wirtualnym
> sprzecie" (np. VMWare), to ile czasu minie zanim palaca potrzeba stanie sie
> wirtualizacja hypervisorow.
Jeśli dodawanie niskopoziomowych funkcjonalności w rodzaju security,
emulacja innych architektur sprzętowych, czy fault tolerance będzie
dzięki temu łatwiejsze, to czemu nie.
Mimo, że biznesowo okazała się klapą, to technologicznie taka
koncepcja z jaką próbowała przebić się firma Transmeta (http://
en.wikipedia.org/wiki/Transmeta) była dosyć ciekawa - procesor, który
implementował listę rozkazów software'owo. Kto wie, przy takim
podejściu, gdy będziemy mieć setki core'ów, to będzie można je
indywidualnie i dynamicznie przeprogramowywać - jeden core będzie
pełnił rolę chipsetu, inny hardware'u karty sieciowej, inny karty
graficznej, a jeszcze inny rolę urządzenia szyfrującego. Pewna grupa
core'ów będzie realizowała ISA x86, inna ARM, a inna PowerPC. Nowy
sprzęt będzie się nie tyle fizycznie kupować, co upgrade'ować software
tego "wirtualnego hypervisora". Hypervisorowi (jednemu lub wielu)
powyżej, będzie się wydawało, że ma to wszystko fizycznie w
sprzęcie...
Pozdrawiam,
Waldek Kot
Michal Kleczek
>> Mam wrazenie, ze jakos inaczej definiujemy pojecie "OS" i stad pewne
>> niezrozumienie. Zeby program mogl byc nazwany OSem musi spelniac pewne
>> funkcje. Bez wnikania w szczegoly jego glowna funkcja jest umozliwienie
>> innym programom (aplikacjom) jednoczesnego i bezpiecznego korzystania z
>> _fizycznego_ sprzetu (hardware).
>
> Czyli Windows bądź Linux działający jako guest OS w maszynie
> wirtualnej hypervisor'a przestaje być OS-em ?
Poniekad. Hypervisor jest OSem, a Win/Lin - aplikacja.
> Nie wiem czy Linus
> pogodziłby się z takim potraktowaniem ;-). Bo w większości
> implementacji hypervisor'ów sprzęt wystawiany w ramach guest VM (dla
> guest OS) - jest wirtualny (za wyjątkiem CPU).
Czyli to hypervisor jest OSem.
>
> Natomiast, ja też mam pewien problem z tym czy JRockit VE jest czy nie
> jest OS (stąd umieszczam go w kategorii "OS" - OS w cudzysłowiu). No
> bo jest to guest OS, umożliwia działanie innym aplikacjom (ale tylko
> jednej, i tylko JVM) i zarządza _wirtualnym_ sprzętem. Z drugiej
> strony nie ma dosyć dzisiaj elementarnych cech, choćby obsługi wielu
> użytkowników...
>
Jak to? Czyzby tylko jeden uzytkownik mogl korzystac z aplikacji dzialajacej
na JRockit VE?
>
>> >> Nie - to nie jest jedyny powod - a nawet nie jest to powod zasadniczy.
>> >> Zasadniczym powodem jest to, ze w JVM nie da sie tego zrobic
>> >> bezpiecznie. Polecam
>> >>
przeczytac:http://java.sun.com/j2se/1.5.0/docs/guide/misc/threadPrimitiveDepreca...
>> >> i dodatkowo dokumentacje Thread.destroy()
>>
>> > Nie zgodzę się tu Michał. Ten JavaDoc odnosi się do JEDNEJ
>> > implementacji JVM - Sun HotSpot i do KONKRETNEJ wersji JDK.
>>
>> Nie - to sa problemy _inherentne_ dla JVM (znowu - klania sie definicja
>> JVM - to jest program zgodny ze specyfikacja JVM).
>
> Zmotywowałeś mnie do przeglądnięcia zarówno Java Virtual Machine
> Specification (http://java.sun.com/docs/books/jvms/) jak i Java
> Language Specification (http://java.sun.com/docs/books/jls/). Może źle
> patrzę, ale takich zapisów świadczących o _inherentności_ tego
> problemu w JVM NIE dostrzegam.
Bo to nie jest nigdzie zapisane, ale wynika ze specyfikacji. Po prostu watku
nie mozna bezpiecznie przerwac, bo albo trzeba wtedy zwolnic blokady, albo
ich nie zwalniac, zas i jedna i druga opcja powoduja problemy.
> Przywołany przeze mnie wcześniej przykład MVM też w żaden sposób nie
> narusza tych specyfikacji i jest pełnoprawną JVM.
> Skąd więc ta opinia o inherentności tego problemu w JVM ?
Bo w ramach jednego isolate w MVM tez nie mozna bezpiecznie przerwac watku.
Mozna wylaczyc cale isolate (proces), ale nie mozna (bezpiecznie) przerwac
watku.
To wynika z tego, ze w MVM zasoby (czyli np. pamiec/obiekty) nie sa
wspoldzielone pomiedzy isolates - czyli blokady rowniez nie.
Natomiast we wpolczesnych JVM - sa.
>
>
>> > JVM, w
>> > której zaimplementowano by te trzy podane opcje (generacja bytecode'u,
>> > modyfikacja kodu natywnego, OS "rozumiejący" JVM - a pewnie i inne
>> > pomysły rozwiązujące ten problem) i które wystawiłoby takie API "na
>> > zewnątrz" nie wydają się żadnym science fiction.
>>
>> Oczywiscie - mozna zrobic taka maszyne wirtualna, ale:
>> 1. trzeba zmienic (byc moze tylko rozszerzyc) specyfikacje JVM
>
> Żadna z podanych przeze mnie opcji nie narusza specyfikacji JVM.
Tyle, ze zadna nie rozwiazuje problemu Thread.stop() i Thread.destroy().
Objasnienie nizej.
[ciach]
>> > Żeby nie być gołosłownym, to odwołam się do prac polskich naukowców
>> > Grzegorza Czajkowskiego i Krzysztofa Palacza, dotyczących Application
>> > Isolatates (nawet JSR-a się doczekały - JSR-121), Multitasking VM (MVM
>> > - http://java.sun.com/developer/technicalArticles/Programming/mvm/) i
>> > słynnego projektu Sun Barcelona (http://research.sun.com/projects/
>> > barcelona/).
>>
>> Wszystko to bardzo fajnie, ale to jest wlasnie _rozszerzenie_ standardu.
>
> Owszem, jest to rozszerzenie JDK, ale żadnej groźby tu nie widzę. Ot,
> dodatkowe API. Z takimi roszerzeniami mamy do czynienia stale.
Ale dopoki te rozszerzenia nie sa czescia specyfikacji, programista nie moze
z nich korzystac. Stad cos co _dzisiaj_ nazywamy JVM tych funkcji nie
spelnia.
>
>
>> Co wazniejsze - wlasnie w MVM wprowadza sie pojecie "isolate"
>> (koncepcyjnie jest to dokladnie to samo co "proces" w OSie typu Unix czy
>> Windows) i dopiero zdefiniowanie takiego pojecia pozwala na sensowne
>> rozwazanie zastosowania JVM jako systemu operacyjnego.
>> Proba zrobienia z JVM OSa _bez_ tego rodzaju modyfikacji jest skazana na
>> niepowodzenie (chociaz mozna probowac sztuczek z modyfikacja bytecodu
>> itp.).
>
> Próba, której nie było...
> Opcje 2 i 3 są z punktu widzenia tego co napisałeś mniej "inwazyjne" i
> nie wprowadzają dodatkowych konstrukcji, aby zapewnić bezpieczniejsze
> zarządzanie wątkami.
>
>
>> Co ciekawe - materialy dotyczace Isolate API (nie pomne w tej chwili
>> linkow) wspominaja, ze:
>> 1) API jest tak skonstruowane, zeby mozna bylo je zaimplementowac po
>> prostu uruchamiajac wiele instancji JVM (procesow) w ramach OSa
>
> Dokładniej, to pozwalają zrealizować koncepcję Isolate przy pomocy
> różnych mechanizmów, w tym w szczególności zarówno w postaci procesów,
> jak i w postaci wątków.
Sorry za zlosliwosc, ale to, ze specyfikacja nie zabrania zrealizowac
koncepcji Isolate przy pomocy watkow nie oznacza, ze to sie _da_
zrealizowac przy pomocy watkow.
>> 2) taka implementacja Isolate API jest najprostsza, zas ewentualne inne
>> implementacje sa przedmiotem badan - bo tak naprawde wcale nie wiadomo,
>> czy przynioslyby jakiekolwiek korzysci.
>
> Najprostsza na pewno, czy przydatna w praktyce wątpię (bo zarówno z
> green threads, jak i implementacji wątków Java poprzez procesy OS,
> wycofano się. Są oczywiście niszowe zastosowania, gdzie takie
> podejścia mogą mieć sens. W mainstream'owej Java - zwłaszcza na
> serwerze nie wydaje się).
> Z tego co ja czytałem o MVM, to implementacja bazowała na wątkach OS,
> czyli - tak jak w typowych JVM: pojedynczy MVM był widoczny w OS jako
> 1 proces, wewnątrz MVM można było uruchamiać wiele aplikacji ("metod
> main"), poszczególne aplikacje działały jako wątki systemu
> operacyjnego.
Czyli MVM reimplementuje pojecie procesu wewnatrz maszyny wirtualnej. Same
watki to malo - potrzebny jest jeszcze zestaw struktur danych + odpowiednie
algorytmy pozwalajace zarzadzac zasobami przydzielonymi poszczegolnym
isolates (np. sterta). Watki sa tylko jednym z takich zasobow - niczym
wiecej.
Co wiecej - taka implementacja MVM jest uwazana przez jednego z jej autorow
za malo uzyteczna (choc ciekawa ze wzgledow badawczych). Z bardzo prostego
powodu. Zamiast wykorzystac istniejace, dobrze przetestowane i pewne
oprogramowanie (np. linuksa albo windows) zaimplementowano OS od nowa. A
taki OS wymaga bardzo duzych nakladow finansowych i czasowych na
osiagniecie odpowiedniego poziomu dojrzalosci.
>
>
>> > Zgadza się. Na tym polega ten kompromis, że wątki oznaczają lepszą
>> > wydajność i skalowalność, ale kosztem komplikacji w zarządzaniu
>> > zasobami. OS też w zasadzie po wątkach "nie sprząta", po prostu usuwa
>> > wszelkie struktury procesu i zwalnia używane przez niego (w tym przez
>> > jego wątki) zasoby.
>>
>> To jest wlasnie "sprzatanie".
>
> Chodziło mi o to, że czasem trzeba bardziej inteligentnie potraktować
> usuwanie niektórych zasobów używanych przez wątki (czy proces). Wiele
> z tych zasobów OS też nie śledzi (i nie wie jak "posprzątać"). Plików
> tymczasowych utworzonych przez wątek/proces sam z siebie nie usunie.
> Zadań batchowych zainicjowanych przez wątek/proces na zdalnej maszynie
> też sam nie przerwie... Itd.
>
"Zasob" moze byc rozumiany na bardzo wiele sposobow - to prawda. Ale w tej
dyskusji istotne zasoby to te, ktorych niezwolnienie szybko powoduje
destabilizacje systemu (czyli np. pamiec).
>
>> > Co do śledzenia zasobów, to oczywiście - aby móc
>> > je posprzątać, trzeba je śledzić. Wracając do tezy o tym co jest
>> > główną przeszkodą, że dzisiejsze JVM tego nie robią - to kosztuje to
>> > wydajność i pamięć.
>> > Co do zwalniania blokad, to w tych podejściach które opisywałem -
>> > zwłaszcza 1 i 2 - chodzi o to, aby wątek sam się zakończył
>> > ("kooperatywnie wyskoczył z metody run()") - ten kod "wyjścia z run"
>> > też można wygenerować i wstawić w bytecode/kod maszynowy metody
>> > "run".
>>
>> Polecam jednak przeczytanie dlaczego _obydwie_ metody Thread.destroy() i
>> Thread.stop() sa "deprecated". Po prostu nie mozna bezpiecznie ani
>> zwolnic wszystkich blokad, ani ich zostawic.
>> I nie ma znaczenia, ze kod zatrzymywania watku jest wstawiany przez jakis
>> generator, bo ten wygenerowany kod musi przyjac strategie taka, jak w
>> Thread.destroy(), albo taka jak w Thread.stop().
>
> W opcji 1 i 2 chodzi o trochę inne "wyjście" z wątku, niż to o którym
> piszesz. Ten kod zatrzymywania wątku nie musi używać metod stop/
> destroy - może być wstawiony do metody run() i pozwolić bezpiecznie z
> niej wyjść - tym samym pozwalniać blokady, itd. Bezpiecznie, czyli
> tak, jakby po prostu metoda run() się skończyła.
Czy rozumiesz, ze ten wstawiony kod musi albo:
a) zwolnic wszystkie blokady
b) nie zwalniac blokad
Obydwie opcje powoduja problemy.
> Na tym ma polegać ta
> "kooperacja" z wątkiem, który ma być zatrzymywany (to tak, jakby
> wewnątrz Twojej nieskończonej pętli wstawić if-a sprawdzającego flagę
> żądania zatrzymania i jeśli jest ona ustawiona na 'true', to wyskoczyć
> z pętli. Po dojściu do końca metody run() wątek zakończy działanie,
> więc zostaną pozwalniane zasoby i tak dalej).
Zrozum - nie jest problemem przerwanie watku (czyli - jak to
nazywasz - "wyskoczenie z petli"). Problemem jest posprzatanie, czyli
zapewnienie, ze po "wyskoczeniu z petli" inne watki nie beda mialy
problemow.
Ilustracja:
class MyObj {
//zalozmy dla celow dyskusji
//ze niezmiennikiem jest
//ze tablica "odwrotnie" zawiera
//elementy tablicy "oryginal" w
//odwrotnym porzadku
private Object[] oryginal = new Object[] {};
private Object[] odwrotnie = new Object[] {};
//"wprowadzacz" bledu
private Random rnd = new Random();
synchronized void setOryginal(Object[] oryginal) {
this.oryginal = oryginal.clone();
odwrotnie = new Object[oryginal.length];
final boolean blad = rnd.nextInt() < 100;
for (int i = oryginal.length - 1; i >= 0; i--) {
odwrotnie[odwrotnie.length - i] = oryginal[i];
//blad w programie
//(pseudo)losowo wpadamy
//w nieskonczana petle
if (blad) {
i++;
}
}
}
synchronized Object[] getOdwrotnie() {
return odwrotnie.clone();
}
}
Pytanie:
Jak teraz chcesz bezpiecznie dla watkow czekajacych na getOdwrotnie()
przerwac watek ktory wpadl w nieskonczona petle w setOryginal() ???
Pamietaj, ze "bezpiecznie dla innych watkow" oznacza, ze zachowane zostana
niezmienniki (innymi slowy po przerwaniu watku system jest w stanie
spojnym).
>
>
>
>> > Inna sprawa, że zwłaszcza serwerowe JVM (bo tu efektywne zarządzanie
>> > wątkami jest szczególnie istotne) mogą stosować podział Java heap na
>> > tzw. thread local areas (TLA), w których umieszczane są obiekty
>> > alokowane przez dany wątek. Ponieważ zdecydowana większość takich
>> > obiektów nie jest współdzielona między wątkami, usunięcie/
>> > wyczyszczenie takiego obszaru odzyskuje zaalokowaną przez wątek
>> > pamięć. Referencje do obiektów współdzielonych między wątkami mogą być
>> > traktowane specjalnie (w serwerowych aplikacjach Java takich
>> > referencji będzie stosunkowo mało) - także podczas czyszczenia pamięci
>> > po wątku. JVM wie do którego wątku dane TLA należy...
>>
>> Patrz wyzej - nie da sie uniknac memory leakow. W aplikacjach serwerowych
>> to jest _katastrofa_ , bo one maja dzialac dlugo, bardzo dlugo...
>
> Z tym, że chodzi o bezpieczne ubicie, czyli takie, które ryzyko memory
> leak'ów wyeliminuje (pomijam tu błędy programistów - aplikacji,
> kontenera, czy JVM).
Gdyby programisci nie popelniali bledow, to nie byloby memory leak'ow.
> Ten przykład z TLA miał służyć pokazaniu tego, że
> narzut na takie śledzenie wykorzystania pamięci przez wątki można
> bardzo mocno ograniczyć. Zdecydowana większość alokacji wątku będzie
> się toczyła w ramach jego TLA. Niewielka liczba współdzielonych
> obiektów będzie specjalnie traktowana (m.in. kosztem dodatkowych
> struktur pamięci i czasu CPU).
> Memory leak JVM czy kontenera są nieporównanie rzadsze niż memory leak
> aplikacji. Dobre praktyki deweloperskie i narzędzia (zarówno analiza
> kodu, jak i runtime'owe) pozwalają sobie z tym problemem dosyć dobrze
> radzić...
Aha - z tego wynika, ze serwer aplikacji nadaje sie tylko do uruchamiania
aplikacji nie zawierajacych bledow. Powiedzialbym, ze dosyc ograniczony
obszar zastosowan.
--
Michal
Michal Kleczek
[ciach]
>> > Doprawdy, the sky is the limit...
>>
>> To może jeszcze ten OS z JVM-em powinien wykrywać, że programista wybrał
>> nieoptymalny algorytm do danego zadania? I podmieniać go na właściwy.
>
> ALEŻ TO CAŁKIEM REALNE !!! Polecam poczytać o projektach robionych w
> amerykańskiej National Security Agency: zwirtualizowanej sztucznej
> inteligencji i algorytmach hyper-genetycznych (hyper = skrót od
> hypervisor) ! Więcej informacji na stronach NSA:
> http://coding-by-talking.nsa.gov.
>
Jasne - jak NSA juz wymysli komputer zastepujacy czlowieka to problem
zostanie rozwiazany.
Inna sprawa jest to, ze jezeli ten komputer ma zastepowac czlowieka, to -
jak czlowiek - musi popelniac bledy. Rowniez bledy w tworzonych przez
siebie programach. Ciekawe jak sobie z nimi poradzi...
--
Michal
Waldek Kot
:-)
Nie doczytałeś mojego posta do końca, prawda ? Do post scriptum... ;-)
Pozdrawiam,
Waldek Kot
Filip Sielimowicz
> Pytanie:
> Jak teraz chcesz bezpiecznie dla watkow czekajacych na getOdwrotnie()
> przerwac watek ktory wpadl w nieskonczona petle w setOryginal() ???
> Pamietaj, ze "bezpiecznie dla innych watkow" oznacza, ze zachowane zostana
> niezmienniki (innymi slowy po przerwaniu watku system jest w stanie
> spojnym).
if (blad) {
i++;
}
->> zachowaj się tak, jakby instrukcja i++ wygenerowała RuntimeException.
I jak ? Sprząta się ?
Michal Kleczek
1. Dlaczego akurat w tym miejscu?
2. Skad kontener ma wiedziec, ze to akurat w tym miejscu?
3. To co proponujesz jest identyczne z dzialaniem Thread.stop() - przeczytaj
dlaczego to nie jest dobre rozwiazanie.
>
> I jak ? Sprząta się ?
Nie - niezmienniki nie sa zachowane. Spojrz na dokumentacje Thread.stop()
--
Michal
Waldek Kot
> > Czyli Windows bądź Linux działający jako guest OS w maszynie
> > wirtualnej hypervisor'a przestaje być OS-em ?
>
> Poniekad. Hypervisor jest OSem, a Win/Lin - aplikacja.
>
> > Nie wiem czy Linus
> > pogodziłby się z takim potraktowaniem ;-). Bo w większości
> > implementacji hypervisor'ów sprzęt wystawiany w ramach guest VM (dla
> > guest OS) - jest wirtualny (za wyjątkiem CPU).
>
> Czyli to hypervisor jest OSem.
<:-)>
No, ciekawa metamorfoza - z "Windows OS" działającego pod
hypervisor'em zostało tylko "Windows"... Ciekawe, czy to pozwala nie
płacić Microsoft-owi za licencję ;-)
</:-)>
> Jak to? Czyzby tylko jeden uzytkownik mogl korzystac z aplikacji dzialajacej
> na JRockit VE?
Nie - powyżej takiego "OS-a" jakim jest JRockit VE jest JVM, a
najczęściej jeszcze też serwer aplikacyjny. Oba załatwiają temat
security dla wielu użytkowników. Po przejściu tych dwóch warstw, ten
"OS" wykonuje operacje (np. dostęp do plików) jako jeden użytkownik.
Ani JVM, ani serwer aplikacyjny, ani tym bardziej aplikacja nie są
świadome, że pod spodem nie ma normalnego OS-a...
> >> Nie - to sa problemy _inherentne_ dla JVM (znowu - klania sie definicja
> >> JVM - to jest program zgodny ze specyfikacja JVM).
>
> > Zmotywowałeś mnie do przeglądnięcia zarówno Java Virtual Machine
> > Specification (http://java.sun.com/docs/books/jvms/) jak i Java
> > Language Specification (http://java.sun.com/docs/books/jls/). Może źle
> > patrzę, ale takich zapisów świadczących o _inherentności_ tego
> > problemu w JVM NIE dostrzegam.
>
> Bo to nie jest nigdzie zapisane, ale wynika ze specyfikacji. Po prostu watku
> nie mozna bezpiecznie przerwac, bo albo trzeba wtedy zwolnic blokady, albo
> ich nie zwalniac, zas i jedna i druga opcja powoduja problemy.
"Nie jest zapisane nigdzie, ale wynika ze specyfikacji" ??? Nie
zrozumiałem.
Te podawane wcześniej opcje (zwłaszcza 1 i 2) zakładają
"samozatrzymanie się" wątku. Czyli bezpieczne. Czyli normalne
zwalnianie blokad, zasobów, itd. Wczytaj się please w ten koncept
głębiej (oraz patrz przykład niżej).
> > Przywołany przeze mnie wcześniej przykład MVM też w żaden sposób nie
> > narusza tych specyfikacji i jest pełnoprawną JVM.
> > Skąd więc ta opinia o inherentności tego problemu w JVM ?
>
> Bo w ramach jednego isolate w MVM tez nie mozna bezpiecznie przerwac watku.
> Mozna wylaczyc cale isolate (proces), ale nie mozna (bezpiecznie) przerwac
> watku.
W tej implementacji MVM którą opisuje Czajkowski isolate JEST
realizowany w postaci wątek OS. Nieskończona pętla którą podawałeś
wcześniej jako przykład będzie przerwana. Bezpiecznie (tj. zasoby i
blokady isolate'u będą pozwalniane). Nie widziałem tego w działaniu,
ale czytam prace Czajkowskiego i tak to rozumiem: w jego
implementacji MVM, isolate = thread. Jedynym wyjątkiem w tej
konkretnej implementacji MVM, jest to, że kod natywny aplikacji (JNI)
wykonuje się w odrębnych procesach systemu operacyjnego. Jak
rozumiem, motywacja była taka, że eksperyment z taką JVM skupiał się
na kodzie Java, a także - co chyba ważniejsze - do osiągnięcia
założonych celów korzysta ze wstawiania bytecode'u. W tym sensie
podane wcześniej opcje 2 (generacja kodu maszynowego) i 3 (dedykowany
OS) dają łatwiejszą możliwość lepsze ilozacji także kodu natywnego.
Pomysł z połączeniem wszystkich trzech opcji (a także dodatkowych
mechanizmów o których Czajkowski wspomina) też zresztą był we
wcześniejszych postach przywoływany...
> >> > JVM, w
> >> > której zaimplementowano by te trzy podane opcje (generacja bytecode'u,
> >> > modyfikacja kodu natywnego, OS "rozumiejący" JVM - a pewnie i inne
> >> > pomysły rozwiązujące ten problem) i które wystawiłoby takie API "na
> >> > zewnątrz" nie wydają się żadnym science fiction.
>
> >> Oczywiscie - mozna zrobic taka maszyne wirtualna, ale:
> >> 1. trzeba zmienic (byc moze tylko rozszerzyc) specyfikacje JVM
>
> > Żadna z podanych przeze mnie opcji nie narusza specyfikacji JVM.
>
> Tyle, ze zadna nie rozwiazuje problemu Thread.stop() i Thread.destroy().
> Objasnienie nizej.
A ! Skoro Tobie chodzi o rozwiązanie problemów tych dwóch metod w
implementacji Sun JDK, to OK.
Jeśli chodzi o rozwiązanie problemów zapewnienia lepszej izolacji
wątków w JVM czy możliwości bezpiecznego zatrzymania błędnie
działającego programu (=tu: w nieskończonej pętli), to owszem -
rozwiązuje.
> > Owszem, jest to rozszerzenie JDK, ale żadnej groźby tu nie widzę. Ot,
> > dodatkowe API. Z takimi roszerzeniami mamy do czynienia stale.
>
> Ale dopoki te rozszerzenia nie sa czescia specyfikacji, programista nie moze
> z nich korzystac. Stad cos co _dzisiaj_ nazywamy JVM tych funkcji nie
> spelnia.
Idąc tym tokiem myślenia, to programista nie mógłby skorzystać z
żadnej biblioteki spoza JDK ani z żadnej innej implementacji JVM niż
Sun HotSpot. Nie ma to miejsca w rzeczywistości...
> >> Co ciekawe - materialy dotyczace Isolate API (nie pomne w tej chwili
> >> linkow) wspominaja, ze:
> >> 1) API jest tak skonstruowane, zeby mozna bylo je zaimplementowac po
> >> prostu uruchamiajac wiele instancji JVM (procesow) w ramach OSa
>
> > Dokładniej, to pozwalają zrealizować koncepcję Isolate przy pomocy
> > różnych mechanizmów, w tym w szczególności zarówno w postaci procesów,
> > jak i w postaci wątków.
>
> Sorry za zlosliwosc, ale to, ze specyfikacja nie zabrania zrealizowac
> koncepcji Isolate przy pomocy watkow nie oznacza, ze to sie _da_
> zrealizowac przy pomocy watkow.
Implementacja MVM prezentowanego przez Czajkowskiego działa na wątkach
OS. Innych implementacji MVM nie znam. Sorry Michał, ale taki
autorytet jak Czajkowski pisze w pracy naukowej, że się da, to hmm...
myślę, że się da (co więcej nie tylko napisał w pracy naukowej, ale
zrobił działającą implementację MVM).
> Czyli MVM reimplementuje pojecie procesu wewnatrz maszyny wirtualnej. Same
> watki to malo - potrzebny jest jeszcze zestaw struktur danych + odpowiednie
> algorytmy pozwalajace zarzadzac zasobami przydzielonymi poszczegolnym
> isolates (np. sterta). Watki sa tylko jednym z takich zasobow - niczym
> wiecej.
Pełna zgoda - nikt nie pisał, że aż tak łatwo będzie i że dla
osiągnięcia większego bezpieczeństwa _aplikacji_ wystarczy tylko
zapewnić bezpieczne zatrzymywanie wątków. Poza niebezpieczeństwem
nieskończonych pętli są też inne ryzyka.
> Co wiecej - taka implementacja MVM jest uwazana przez jednego z jej autorow
> za malo uzyteczna (choc ciekawa ze wzgledow badawczych). Z bardzo prostego
> powodu. Zamiast wykorzystac istniejace, dobrze przetestowane i pewne
> oprogramowanie (np. linuksa albo windows) zaimplementowano OS od nowa.
Z takim radykalnym stwierdzeniem się nie spotkałem, ale praktyka tego
co się z JSR-121, czy MVM dziej też pokazuje, że branża wielkiego
zapotrzebowania na dzisiaj nie ma. Może też i problemy od których
rozpoczęliśmy tę całą dyskusję o bezpieczeństwie wątków nie są na
dzisiaj aż tak palące ? A może inne techniki - analiza statyczna,
bardziej rygorystyczne testy, czy dedykowane OS ;-) - są prostszym
pomysłem na rozwiązanie tego problemu...
Co do pomysłu który podajesz, to cóż żaden z tych OS nie rozumie JVM i
jej struktur (patrz Twoja własna wypowiedź trochę wyżej, na temat
zarządzania zasobami). Nie widać też pomysłu, jak w praktyce
przekonać deweloperów MS, czy jądra Linux'a, żeby takie wsparcie
wprowadzili. Może spić Linusa, Mortona czy GKH. Chyba, że Michał masz
jakiś pomysł ?
> A taki OS wymaga bardzo duzych nakladow finansowych i czasowych na
> osiagniecie odpowiedniego poziomu dojrzalosci.
Bingo ! Chyba, że skorzystasz z dobrodziejstw wirtualizacji i
hypervisorów. Przypomnę, że w jednym z postów wcześniej
demonstrowałem przykład 10-cio linijkowego "kernela OS" (pochodzący z
książki "Definitive Guide to the Xen Hypervisor") - podobnie, było to
pierwsze moje demo podczas pokazu JRockit VE na GeeCon 2009 w
Krakowie (notabene, slajdy z tej i innych prezentacji są tutaj:
http://www.geecon.org/site/materials). Celem tej demonstracji było
właśnie uświadomienie jak mocno hypervisor upraszcza zrobienie
dedykowanego OS. W każdym razie, to chyba prostsze (choć znacznie
mniej przyjemne) niż upijanie Linusa i jego ekipy ;-)
> >> > Co do śledzenia zasobów, to oczywiście - aby móc
> >> > je posprzątać, trzeba je śledzić. Wracając do tezy o tym co jest
> >> > główną przeszkodą, że dzisiejsze JVM tego nie robią - to kosztuje to
> >> > wydajność i pamięć.
> >> > Co do zwalniania blokad, to w tych podejściach które opisywałem -
> >> > zwłaszcza 1 i 2 - chodzi o to, aby wątek sam się zakończył
> >> > ("kooperatywnie wyskoczył z metody run()") - ten kod "wyjścia z run"
> >> > też można wygenerować i wstawić w bytecode/kod maszynowy metody
> >> > "run".
>
> >> Polecam jednak przeczytanie dlaczego _obydwie_ metody Thread.destroy() i
> >> Thread.stop() sa "deprecated". Po prostu nie mozna bezpiecznie ani
> >> zwolnic wszystkich blokad, ani ich zostawic.
> >> I nie ma znaczenia, ze kod zatrzymywania watku jest wstawiany przez jakis
> >> generator, bo ten wygenerowany kod musi przyjac strategie taka, jak w
> >> Thread.destroy(), albo taka jak w Thread.stop().
>
> > W opcji 1 i 2 chodzi o trochę inne "wyjście" z wątku, niż to o którym
> > piszesz. Ten kod zatrzymywania wątku nie musi używać metod stop/
> > destroy - może być wstawiony do metody run() i pozwolić bezpiecznie z
> > niej wyjść - tym samym pozwalniać blokady, itd. Bezpiecznie, czyli
> > tak, jakby po prostu metoda run() się skończyła.
>
> Czy rozumiesz, ze ten wstawiony kod musi albo:
> a) zwolnic wszystkie blokady
> b) nie zwalniac blokad
> Obydwie opcje powoduja problemy.
Michał - wczytaj się w rozwiązanie które opisuję. Wątek ZAKOŃCZY swoje
działanie. Z punktu widzenia JVM to zakończenie będzie normalne
(=wyjście z metody run() wątku). Z punktu widzenia aplikacji,
oczywiście niekoniecznie (bo dla przykładu: kod w pętli zamiast
wykonać się 3 mld razy, wykona się 1500 razy).
//KONCEPT:
//TUTAJ (TJ. NA KOŃCU PĘTLI FOR) ZOSTANIE WSTAWIONY BYTECODE
SPRAWDZAJĄCY FLAGĘ 'zatrzymania tego wątku',
//USTAWIONEJ PRZEZ INNY WĄTEK LUB JVM. FLAGA MOŻE BYĆ PER JVM, PER
APLIKACJA, PER WĄTEK, PER GRUPA WĄTKÓW, ITD.
//NAIWNY PRZYKŁAD TEGO BYTECODE'U:
if(flaga)
return;
}
}
To jest OCZYWIŚCIE naiwna implementacja, ale chodzi o koncept.
Implementacje tego konceptu mogą (powinny) być bardziej złożone -
sprawdzanie uprawnień do zatrzymania wątku, itd. Takich sprawdzeń
flagi trzeba w aplikacji OCZYWIŚCIE wstawić znacznie więcej - tyle,
żeby po ustawieniu flaga na 'true' w którymś tam momencie zakończyć
działanie metody run() tego wątku (liczba i miejsce tych wstawień oraz
sama realizacja flagi i jej sprawdzania mogą zależeć od
implementacji). Przy zatrzymywaniu powinny być też wykonane dodatkowe
'sprzątnięcia'. Nie widzę problemu, żeby deweloper nie mógł
zarejestrować swojego własnego kodu 'sprzątającego', który byłby
wywoływany jako callback.
No i jeszcze raz podkreślam, że: Thread.stop, czy Thread.interrupt nie
są używane. Natomiast warto, aby zmienić ich implementację na taką,
która będzie ustawiać 'flagę' na 'true' (znowu upraszczam oczywiście).
Przy opcji 2 z wcześniejszych postów zamiast bytecode'u wstawiany
byłby kod maszynowy.
Trochę offtopic: Wiem, że to powyższe to tylko kod poglądowy, ale
jeśli taki kod pokryje się testami (unit/integration/performance/
stress czy jak inaczej zwał), to błąd będzie stosunkowo łatwo wykryć
jeszcze przed deployment'em (tak trochę wracając do tego, że serwery
aplikacyjne z założenia mają wykonywać trochę bardziej zaufany kod.
Tu: zaufany = przetestowany).
> > Ten przykład z TLA miał służyć pokazaniu tego, że
> > narzut na takie śledzenie wykorzystania pamięci przez wątki można
> > bardzo mocno ograniczyć. Zdecydowana większość alokacji wątku będzie
> > się toczyła w ramach jego TLA. Niewielka liczba współdzielonych
> > obiektów będzie specjalnie traktowana (m.in. kosztem dodatkowych
> > struktur pamięci i czasu CPU).
> > Memory leak JVM czy kontenera są nieporównanie rzadsze niż memory leak
> > aplikacji. Dobre praktyki deweloperskie i narzędzia (zarówno analiza
> > kodu, jak i runtime'owe) pozwalają sobie z tym problemem dosyć dobrze
> > radzić...
>
> Aha - z tego wynika, ze serwer aplikacji nadaje sie tylko do uruchamiania
> aplikacji nie zawierajacych bledow. Powiedzialbym, ze dosyc ograniczony
> obszar zastosowan.
Nadinterpretujesz (aka: semantycznie nadużywasz) ;-). Są rzadsze w JVM/
AS, bo znacznie więcej uwagi tu się im poświęca (wygrzewasz swoje
aplikacje na kilkuset kombinacjach sprzętowych/OSowo/JVMowych przez
np. 3 tygodnie ?). Oczywiście - serwer aplikacyjny to aplikacja Java,
więc szanse na zrobienie błędu prowadzącego do memory leak są takie
same. Idąc tokiem Twojego rozumowania tutaj, śpieszę też zaznaczyć, że
dewelopera serwera aplikacyjnego nie uważam za lepszego (=robiącego
mniej błędów) niż dewelopera aplikacji.
Pozdrawiam,
Waldek Kot
Michal Kleczek
[ciach]
Zrozum - to nie jest rozwiazanie, bo to tylko zatrzymuje watek bez
zapewnienia zachowania niezmiennikow!!! Problem jest taki, ze _inne_ watki
widza niespojny stan systemu.
To jest koncepcyjnie to samo, co Thread.stop() i to co opisal Filip
Sielimowicz(jedyna roznica to to, ze Thread.stop() rzuca
ThreadDeatchException zamiast robic return).
--
Michal
Michal Kleczek
[ciach]
>> Sorry za zlosliwosc, ale to, ze specyfikacja nie zabrania zrealizowac
>> koncepcji Isolate przy pomocy watkow nie oznacza, ze to sie _da_
>> zrealizowac przy pomocy watkow.
>
> Implementacja MVM prezentowanego przez Czajkowskiego działa na wątkach
> OS. Innych implementacji MVM nie znam. Sorry Michał, ale taki
> autorytet jak Czajkowski pisze w pracy naukowej, że się da, to hmm...
> myślę, że się da (co więcej nie tylko napisał w pracy naukowej, ale
> zrobił działającą implementację MVM).
Moze sie zle wyrazilem - pojecie watku jest _niewystarczajace_ do
implementacji MVM (stad wprowadzenie pojecia Isolate). To, ze
wielowatkowosc jest niezbedna do implementacji MVM to jest - ze tak
powiem - oczywista oczywistosc.
--
Michal
Waldek Kot
OK - już chyba wiem o co Ci chodzi. Chciałbyś, żeby zatrzymanie tego
wątku zapewniło zachowanie niezmienników tej klasy, czyli (to co
napisałeś w komentarzu na początku klasy):
//zalozmy dla celow dyskusji
//ze niezmiennikiem jest
//ze tablica "odwrotnie" zawiera
//elementy tablicy "oryginal" w
//odwrotnym porzadku
W tym sensie, to oczywiście ten wątek nie będzie zatrzymany
"bezpiecznie". Ale w tej dyskusji poruszaliśmy chyba trochę inne
zagadnienia, między innymi (upraszczając):
- wątek czy proces
- inherentność problemu bezpiecznego zatrzymywania wątków w _JVM_
- możliwości zatrzymania błędnie działającego wątku, tak, aby nie
trzeba było restartować procesu JVM
Przyznam że nie znam systemu który by potrafił to, co Ty rozumiesz za
"bezpieczne" (zatrzymanie procesu też nie da gwarancji, że niezmiennik
tej klasy będzie zachowany). Zauważ też, że niezmiennik tej klasy
jest, hmm, wyrażony w komentarzu (i tak lepiej niż w głowie
programisty). Jakże więc to biedne środowisko wykonawcze (JVM, .NET,
czy inne) ma zrozumieć intencję programisty i domyśleć się o jakie
niezmienniki chodzi ? Jak przekazać mu jaka jest specyfikacja tej
klasy obiektów ? Można by zapewne napisać kod, który stwierdzałby czy
aktualnie obiekt zachowuje swoje niezmienniki, ale pewnie też trzeba
by napisać kod, który opisywałby co się ma dziać jeśli aktualnie
jeszcze nie spełnia. I wtedy co - odwołując się do Twojego przypadku -
miałby jeszcze wykonać parę iteracji pętli ? Załóżmy, że
doprowadziłoby to obiekt do stanu poprawnego (=zgodnego ze
specyfikacją). To już wystarczy, żeby mieć pewność, że program działa
dobrze ??? Bez złośliwości - ale skąd wiadomo, że ten Twój kod jest
niepoprawny ? Może właśnie o takie jego zachowanie chodziło
programiście ? Maszyna ma się domyślać ?
Ale załóżmy, że byłoby to OK - czemu nie miałbyś podać - na zasadzie
callback'u - własnego kodu sprawdzającego niezmienniki ? Tak, aby
dopóki ten kod nie zwróci 'true' przerwanie działania wątku się nie
odbywało (mogę sobie nawet wyobrazić jakiś timeout albo inny
ogranicznik, po którym JVM nie uwzględniałby już tego callback'a). Nie
rozwiąże to takiego problemu, jak ten podany w Twoim przykładzie, ale
cóż - chyba nic innego też go nie rozwiąże (automatyczne dowodzenie
poprawności programów ? testowanie ? modlitwa ?).
Widzisz, to co ja rozumiałem jako bezpieczne zatrzymanie wątku, to
takie, które nie narusza żadnej reguły wynikającej ze specyfikacji
JVM, JLS, modelu pamięci Java, itd. Takiego zatrzymania wątku, które
gwarantuje poprawność aplikacji nie zakładałem, bo to trochę science
fiction...
W tym sensie przytoczone przeze mnie rozwiązanie jest bezpieczne.
Notabene - udało mi się dogrzebać do dokumentu z którego przytoczona
przeze mnie opcja nr 1 pochodzi (dosyć dawno ten dokument czytałem, a
z racji masy treści które codziennie czytamy, trudno jest precyzyjnie
podać źródło danej wiedzy):
"Termination in Language-Based Systems", ALGIS RUDYS and DAN S.
WALLACH, Department of Computer Science, Rice University, 2002.
Można ten dokument ściągnąć z acm.org. W każdym razie panowie naukowcy
przeprowadzają FORMALNĄ (=matematyczną) analizę zagadnienia i jego
DOWÓD. Nie mam niestety takich zdolności do analizy formalnej, aby
zweryfikować poprawność tego co zrobili, ale ufam, że ich konkluzja,
czyli że przedstawione rozwiązanie zapewnia bezpieczne (cytuję: "safe
termination of misbehaving or malicious codelets". Tu przez "codelet"
rozumie się kawałek kodu w Java. Cytat: "When we say "codelet," we
refer to a small program meant to be executed in conjunction with or
as an internal component of a larger program."). Oprócz tego, że
zrobili (i formalnie udowodnili) koncept, stworzyli także
implementację działającą na Sun HotSpot JVM na Solarisie na Sparc-u.
W tym sensie nie zgodzę się z _inherentnością_ tego problemu w JVM...
Pozdrawiam,
Waldek Kot
Michal Kleczek
Nie chodzi o zatrzymanie _watku_ . Chodzi o wylaczenie blednie dzialajacego
_programu_ w taki sposob, zeby nie wplywac na inne - niezalezne - programy.
Bez wprowadzenia pojecia "procesu" (lub odpowiednika np. isolate) - czyli
(nieformalnie) "instancji programu" - nie da sie tego zrobic.
> Przyznam że nie znam systemu który by potrafił to, co Ty rozumiesz za
> "bezpieczne" (zatrzymanie procesu też nie da gwarancji, że niezmiennik
> tej klasy będzie zachowany).
Zatrzymanie procesu powoduje, ze instancja klasy przestaje istniec. Mozna te
instancje zniszczyc, bo jest pewnosc, ze nie jest ona wspoldzielona z
innymi procesami. To jest podstawowa roznica miedzy _watkiem_ a _procesem_
(lub isolate w MVM).
> Zauważ też, że niezmiennik tej klasy
> jest, hmm, wyrażony w komentarzu (i tak lepiej niż w głowie
> programisty). Jakże więc to biedne środowisko wykonawcze (JVM, .NET,
> czy inne) ma zrozumieć intencję programisty i domyśleć się o jakie
> niezmienniki chodzi ? Jak przekazać mu jaka jest specyfikacja tej
> klasy obiektów ? Można by zapewne napisać kod, który stwierdzałby czy
> aktualnie obiekt zachowuje swoje niezmienniki, ale pewnie też trzeba
> by napisać kod, który opisywałby co się ma dziać jeśli aktualnie
> jeszcze nie spełnia. I wtedy co - odwołując się do Twojego przypadku -
> miałby jeszcze wykonać parę iteracji pętli ? Załóżmy, że
> doprowadziłoby to obiekt do stanu poprawnego (=zgodnego ze
> specyfikacją). To już wystarczy, żeby mieć pewność, że program działa
> dobrze ??? Bez złośliwości - ale skąd wiadomo, że ten Twój kod jest
> niepoprawny ? Może właśnie o takie jego zachowanie chodziło
> programiście ? Maszyna ma się domyślać ?
>
Nie bardzo rozumiem do czego zmierzasz. Ja nie twierdze, ze maszyna ma sie
domyslac, kiedy program jest w stanie poprawnym. Ja tylko twierdze, ze
program-nadzorca musi umozliwiac wylaczenie dowolnego programu, ktory
nadzoruje bez "psucia" innych programow. Jakie sa powody tego wylaczenia i
czy program-nadzorca implementuje jakies heurystyki, zeby stwierdzic czy
wylaczyc dany program czy nie - jest zupelnie inna sprawa.
> Ale załóżmy, że byłoby to OK - czemu nie miałbyś podać - na zasadzie
> callback'u - własnego kodu sprawdzającego niezmienniki ? Tak, aby
> dopóki ten kod nie zwróci 'true' przerwanie działania wątku się nie
> odbywało (mogę sobie nawet wyobrazić jakiś timeout albo inny
> ogranicznik, po którym JVM nie uwzględniałby już tego callback'a).
Z bardzo prostego powodu - nie da sie napisac programu, ktory bylby w stanie
stwierdzic, czy jego wlasny stan jest poprawny, czy nie (bo jezeli jego
stan jest niepoprawny, to program nie jest w stanie udzielic prawdziwej
odpowiedzi na jakiekolwiek pytanie, gdyz odpowiedz zalezy od stanu
programu).
> Nie
> rozwiąże to takiego problemu, jak ten podany w Twoim przykładzie, ale
> cóż - chyba nic innego też go nie rozwiąże (automatyczne dowodzenie
> poprawności programów ? testowanie ? modlitwa ?).
>
> Widzisz, to co ja rozumiałem jako bezpieczne zatrzymanie wątku, to
> takie, które nie narusza żadnej reguły wynikającej ze specyfikacji
> JVM, JLS, modelu pamięci Java, itd. Takiego zatrzymania wątku, które
> gwarantuje poprawność aplikacji nie zakładałem, bo to trochę science
> fiction...
Sek w tym, ze taka poprawnosc jest niewystarczajaca. Popatrz na przyklad,
ktory podalem. Wylaczajac watek wiszacy na setOriginal() i zostawiajac
obiekt w stanie potencjalnie niespojnym system musialby
a) wylaczyc _wszystkie_ watki, ktore od tego momentu probuja wykonac
jakakolwiek operacje na tym obiekcie (potencjalnie zostawiajac w stanie
niespojnym inne obiekty).
b) oznaczyc obiekt jako "niepoprawny" i nastepnie rzucac wyjatkiem np.
IllegalStateException przy kazdej probie wykonania operacji na obiekcie.
Tyle ze to w praktyce prowadzi do a), bo programisci musieliby spodziewac
sie IllegalStateException przy kazdym wywolaniu metody.
Wprowadzenie pojecia "procesu" rozwiazuje ten problem w taki sposob, ze
dzieli system na niezaleznie dzialajace jednostki nie dzielace (logicznie)
pomiedzy soba zadnych zasobow i dlatego wlasnie nie mogace psuc nawzajem
swojego stanu.
--
Michal
Waldek Kot
> Nie chodzi o zatrzymanie _watku_ . Chodzi o wylaczenie blednie dzialajacego
> _programu_ w taki sposob, zeby nie wplywac na inne - niezalezne - programy.
> Bez wprowadzenia pojecia "procesu" (lub odpowiednika np. isolate) - czyli
> (nieformalnie) "instancji programu" - nie da sie tego zrobic.
A gdyby przyjąć kilka dodatkowych założeń (które wydają się sensowne
np. dla aplikacji Java EE), np. takich, że wraz z błędnie działającym
wątkiem wyłączane są też wszystkie "związane z nim" wątki (w każdym
razie wątki aplikacyjne, nie te wątki, które są związane z działaniem
serwera aplikacyjnego, czy JVM) ? "Związane" czyli np. te które
obsługują to samo zadanie (np. zadanie = pojedynczy request do
aplikacji webowej). Albo w bardziej katastroficznym przypadku -
wyłączane są wszystkie wątki (aplikacyjne) których aktualnie używa
dana aplikacja serwerowa (np. webowa, czy cały EAR) ?
Aplikacje Java EE mają też dosyć precyzyjnie określone reguły
classloading'u, współdzielenia danych, a i mechanizmy zarządzania
wątkami są w takich aplikacjach także bardziej kontrolowalne
(=ograniczone) niż to, na co pozwala Java SE. W razie prób robienia w
aplikacji trików (np. z wątkami, współdzieleniem stanu, czy własnym
classloadingiem) kontener/JVM mogą to wykryć i przyjąć bardziej
agresywną strategię wyłączania wątków takiej aplikacji (najprościej,
to mogą też takiej aplikacji nie pozwolić się uruchomić).
Efekt, o którym piszesz, będzie więc osiągnięty. A nie są to jakieś
szczególnie nowe dla deweloperów aplikacji J2EE/Java EE.
> > Widzisz, to co ja rozumiałem jako bezpieczne zatrzymanie wątku, to
> > takie, które nie narusza żadnej reguły wynikającej ze specyfikacji
> > JVM, JLS, modelu pamięci Java, itd. Takiego zatrzymania wątku, które
> > gwarantuje poprawność aplikacji nie zakładałem, bo to trochę science
> > fiction...
>
> Sek w tym, ze taka poprawnosc jest niewystarczajaca. Popatrz na przyklad,
> ktory podalem. Wylaczajac watek wiszacy na setOriginal() i zostawiajac
> obiekt w stanie potencjalnie niespojnym system musialby
> a) wylaczyc _wszystkie_ watki, ktore od tego momentu probuja wykonac
> jakakolwiek operacje na tym obiekcie (potencjalnie zostawiajac w stanie
> niespojnym inne obiekty).
> b) oznaczyc obiekt jako "niepoprawny" i nastepnie rzucac wyjatkiem np.
> IllegalStateException przy kazdej probie wykonania operacji na obiekcie.
> Tyle ze to w praktyce prowadzi do a), bo programisci musieliby spodziewac
> sie IllegalStateException przy kazdym wywolaniu metody.
Czyli dotarliśmy do tego samego punktu.
> Wprowadzenie pojecia "procesu" rozwiazuje ten problem w taki sposob, ze
> dzieli system na niezaleznie dzialajace jednostki nie dzielace (logicznie)
> pomiedzy soba zadnych zasobow i dlatego wlasnie nie mogace psuc nawzajem
> swojego stanu.
Z tym, że w przypadku wątków też nie jest trudno taki stan
niewspółdzielenia zasobów osiągnąć (a w przypadku aplikacji Java EE -
a od nich w sumie cała ta dyskusja się zaczęła - powiedziałbym, że
nawet łatwo to osiągnąć). A jeśli mają współdzielić, to wyłączanie
wszystkich wątków, które te zasoby współdzielą da tu ten sam efekt co
wyłączenie całego procesu.
Jeśli program ma składać się z wielu kooperujących procesów, to myślę,
że też nie ma gwarancji, że stan programu będzie poprawny. Skala inna,
ale problemy z zasobami i komunikacją podobne. Przykład: uruchomienie
przez jedną jednostkę (proces) długotrwającego zadania (innego
procesu), a następnie wysypanie się tego zadania w sytuacji, gdy inne
jednostki uzależniają swoje działanie od tego zadania, też będzie
wymagało podjęcia podobnych akcji, jak te, które przytoczyłeś: a.
zakończenia wszystkich procesów, b. oznaczenia procesu zadania jako
niepoprawny.
Zysku nie zbyt więc widać, a koszty (procesy vs. wątki) większe.
Notabene - można by tu użyć podobnych opcji automatycznego przerywania
pracy wszystkich procesów składających się na aplikację, ale rolę
nadzorcy musiałby tu przyjąć albo specjalny proces nadzorcy albo sam
OS (gdy wszystkie procesy działają w ramach jednego OS). W pewnym
sensie rolę tę można by powierzyć też hypervisorowi (gdyby procesy
programu miały działać w ramach maszyn wirtualnych na jednym
hypervisorze) albo i nawet oprogramowaniu monitorującemu hypervisory
(gdy procesy mogłyby działać na różnych fizycznych maszynach). Z tego
co wiem, to software do wirtualizacji trochę w tę stronę też idzie i
może monitorować nie tylko poprawne działanie maszyn wirtualnych, czy
fizycznych, ale także procesów wewnątrz maszyn wirtualnych...
Pozdrawiam,
Waldek Kot
Filip Sielimowicz
> Nie chodzi o zatrzymanie _watku_ . Chodzi o wylaczenie blednie
> dzialajacego
> _programu_ w taki sposob, zeby nie wplywac na inne - niezalezne -
> programy.
> Bez wprowadzenia pojecia "procesu" (lub odpowiednika np. isolate) - czyli
> (nieformalnie) "instancji programu" - nie da sie tego zrobic.
...
> Zatrzymanie procesu powoduje, ze instancja klasy przestaje istniec. Mozna
> te
> instancje zniszczyc, bo jest pewnosc, ze nie jest ona wspoldzielona z
> innymi procesami. To jest podstawowa roznica miedzy _watkiem_ a _procesem_
> (lub isolate w MVM).
Tylko widzisz, na mój gust tworzysz tu trochę sprzeczne wymaganie ...
Mówisz o NIEZALEŻNOŚCI programów, a kiedy jest mowa o zachowaniu
niezmienników, to pokazujesz programy ZALEŻNE. Tak przynajmniej ja to widzę.
Rozumiem, że problem nie leży w wątkach i procesach, ale w ŚWIADOMYM
tworzeniu zależności ? A dokładniej: uważasz, że proces ma tę przewagę nad
wątkiem, że uniemożliwia 'nieświadome' tworzenie zależności między
procesami.
W środowisku wielowątkowym zaś, ze względu na założoną 'bliskość' i szerokie
stosowanie danych/funkcji(obiektów) współdzielonych, nawet, jeśli programy
koncepcyjnie są niezależne, to niewłaściwe stosowanie technik
projektowo-implementacyjnych spowoduje, że staną się one zależne i błędy
będą
się 'dystrybuować' na inne programy.
Innymi słowy: jesteś za tym, by nie wprowadzać wątków tylko procesy tam,
gdzie nie jest
to wyraźnie uzasadnione - czyli optujesz za dwupoziomową kategoryzacją
procesów
(procesy+wątki) zamiast jednopoziomowej(tylko wątki).
Jeśli o to chodzi w tym sporze, to oczywiście jest w tym trochę racji. Z tym
jednak,
że trudno prowadzić tu merytoryczną dyskusję bez konkretnych danych o
ryzykach.
Bo środowisko czysto javowo-wątkowe ma swoje zalety, wynikające właśnie z
tego
zbliżenia i współdzielenia danych/usług/... Trzeba by więc oszacować realnie
jakie
są koszty wynikajace ze zwiększonego ryzyka 'błednej
architektury/implementacji'
i 'migracji błedów' w środowisku czysto-wątkowym, a jakie w porównaniu z tym
są koszty 'myślenia procesowego' i np wynikajacych z tego równiez błędów
'architektoniczno-implementacyjnych', które spowoduje, że procesy, które
mają się
komunikować, będą to robić w sposób 'naokoło', 'w różnych technologiach',
'przez pliki', zamiast wykorzystać siłę wątków i współdzielenia danych/usług
;)
Michal Kleczek
> On May 20, 7:05 pm, Michal Kleczek <klek...@gmail.com> wrote:
>
>
>> Wprowadzenie pojecia "procesu" rozwiazuje ten problem w taki sposob, ze
>> dzieli system na niezaleznie dzialajace jednostki nie dzielace
>> (logicznie) pomiedzy soba zadnych zasobow i dlatego wlasnie nie mogace
>> psuc nawzajem swojego stanu.
>
> Z tym, że w przypadku wątków też nie jest trudno taki stan
> niewspółdzielenia zasobów osiągnąć (a w przypadku aplikacji Java EE -
> a od nich w sumie cała ta dyskusja się zaczęła - powiedziałbym, że
> nawet łatwo to osiągnąć).
Chyba jednak trudno. Sprobuje wyjasnic na przykladzie.
Mamy moduly A, B, C (powiedzmy - zeby bylo bardziej osadzone w
rzeczywistosci - A i B to sa _niezalezne_ aplikacje J2EE korzystajace z
roznych baz danych, do ktorych dostep zapewniony jest przez C - adapter
JCA).
Zalozmy, ze z jakiegos powodu chcemy natychmiast wylaczyc modul A (czyli
zatrzymac wszystkie watki obslugujace w tej chwili zadania do A) -
powiedzmy dlatego, ze zajmuje zbyt duzo zasobow (np. pamieci). Mamy
problem, bo watek obslugujacy zadanie do A moze w danej chwili "byc w
module C". Mozemy:
a) czekac az watek wyjdzie z C (tu mamy klopot, bo nigdy nie wiemy, czy
przetwarzanie tego zadania w C sie kiedykolwiek skonczy)
b) zatrzymac watek (co powoduje koniecznosc wylaczenia modulu C, bo
zatrzymujac watek mozemy zepsuc stan C)
Widac wyraznie, ze istnieje (calkiem na pierwszy rzut oka niewidoczna)
zaleznosc od C do A (czyli ze wylaczenie A prowadzi do wylaczenia C, co
znowu wplywa na dzialanie B). A przeciez chcemy, zeby A dalo sie wylaczyc
nie wplywajac na B i C!!! Ta zaleznosc wynika tylko i wylacznie z
konstrukcji JVM i serwera aplikacyjnego.
Jedynym rozwiazaniem jest, by wszystkie trzy moduly byly obslugiwane przez
niezalezne watki, zas komunikacja miedzy nimi odbywala sie poprzez
przekazywanie komunikatow w sposob asynchroniczny. Czyli - defacto -
zaimplementowanie tego czegos, co nazywamy procesem i IPC w OS (lub isolate
w MVM).
Druga kwestia jest wspoldzielenie przez moduly stanu wynikajace z uzywania
wspolnych bibliotek dostarczanych przez runtime Javy i serwer aplikacyjny
(takie wspoldzielenie stanu nie wystepuje pomiedzy procesami OS) - a to
rowniez jest niebanalny problem.
--
Michal
Michal Kleczek
>
> Użytkownik "Michal Kleczek" <kle...@gmail.com> napisał w wiadomości
> news:gv1ds9$q9$1...@mx1.internetia.pl...
>
>> Nie chodzi o zatrzymanie _watku_ . Chodzi o wylaczenie blednie
>> dzialajacego
>> _programu_ w taki sposob, zeby nie wplywac na inne - niezalezne -
>> programy.
>> Bez wprowadzenia pojecia "procesu" (lub odpowiednika np. isolate) - czyli
>> (nieformalnie) "instancji programu" - nie da sie tego zrobic.
> ...
>> Zatrzymanie procesu powoduje, ze instancja klasy przestaje istniec. Mozna
>> te
>> instancje zniszczyc, bo jest pewnosc, ze nie jest ona wspoldzielona z
>> innymi procesami. To jest podstawowa roznica miedzy _watkiem_ a
>> _procesem_ (lub isolate w MVM).
>
> Tylko widzisz, na mój gust tworzysz tu trochę sprzeczne wymaganie ...
> Mówisz o NIEZALEŻNOŚCI programów, a kiedy jest mowa o zachowaniu
> niezmienników, to pokazujesz programy ZALEŻNE. Tak przynajmniej ja to
> widzę.
>
Niezalezne to nie znaczy, ze sie ze soba niekomunikujace.
> Rozumiem, że problem nie leży w wątkach i procesach, ale w ŚWIADOMYM
> tworzeniu zależności ? A dokładniej: uważasz, że proces ma tę przewagę nad
> wątkiem, że uniemożliwia 'nieświadome' tworzenie zależności między
> procesami.
Dokladnie.
> Jeśli o to chodzi w tym sporze, to oczywiście jest w tym trochę racji. Z
> tym jednak,
> że trudno prowadzić tu merytoryczną dyskusję bez konkretnych danych o
> ryzykach.
> Bo środowisko czysto javowo-wątkowe ma swoje zalety, wynikające właśnie z
> tego
> zbliżenia i współdzielenia danych/usług/...
Ja bym nie nazwal tego zaleta, tylko po prostu "cecha". JVM (takie jakie
jest w tej chwili) nadaje sie do uruchomienia _jednego_ programu. Wcale nie
uwazam tego za wade. Natomiast cala dyskusja wziela sie z pytania, czy
stos:
hypervisor+JRockitVE+JRockitJVM+serwer J2EE
nadaje sie do uruchamiania wielu _niezaleznych_ programow (aplikacji Java) -
czyli czy - innymi slowy - serwer J2EE moze zastapic system operacyjny.
Z mojego doswiadczenia (nie lubie tego sformulowania, ale co zrobic ;) )
wynika, ze w praktyce robi sie tak, ze jedna instancja serwera J2EE sluzy
do uruchomienia _jednej_ aplikacji (aplikacje rozumiem tutaj jako zbior
modulow J2EE na tyle ze soba powiazanych, ze uruchomienie oddzielne jego
wlasciwego podzbioru nie ma sensu).
Z czego ja wyciagam wniosek, ze nie ma sensu "wirtualizacja JVM", bo i tak
trzeba odpalic wiele instancji serwerow J2EE, a to mozna taniej zrobic
uruchamiajac wiele JVM w ramach jednego "normalnego" OS.
--
Michal
Waldek Kot
No właśnie - ja tu widzę trzy zagadnienia:
1. czy podane opcje przerwania wątków są jedyne
2. czy te zależności wynikają z konstrukcji JVM i serwera
aplikacyjnego
3. czy możliwość asynchronicznej komunikacji poprzez komunikaty
wymusza użycie procesów
Ad 1
Zarówno opcję a, jak i opcję b z tych które podałeś uważam za możliwe.
Sądzę jednak, że nie są to jedyne opcje, a co ważniejsze - zanim
byłaby potrzeba do nich sięgnąć, to jest cały zestaw lżejszych
(=bardziej precyzyjnych) opcji wyłączenia błędnie działających wątków.
Opcję a i b uznałbym za przypadki "katastroficzne" (odnosząc się do
mojego poprzedniego postu).
Otóż, wyłączeniu mogą podlegać wszystkie te wątki, które są związane z
KONKRETNYM zadaniem, np. pojedynczym żądaniem do konkretnej aplikacji
Java EE. Jak pamiętasz WĄTEK wykonujący tę pętlę przekroczy ustalony
limit czasu działania i zostanie oznaczony jako zablokowany (stucked).
Właśnie dzięki temu, że struktura zależności aplikacji Java EE jest
serwerowi aplikacyjnemu dobrze znana (m.in. z adnotacji i deployment
deskryptorów), to wiadomo (tj. wie to serwer aplikacyjny), które wątki
są ze sobą skorelowane (=wykonują to samo zadanie, np. obsługują ten
sam request). Czyli wie, które ma przerwać - poczynając od wątku
oznaczonego jako 'stucked', ma przerwać te działające jeszcze wątki,
które obsługują dane zadanie/żądanie. Zgodnie z dyskusją we
wcześniejszych postach - technicznie, to oczywiście te wątki byłyby
przerywane przez JVM.
Nie mówię tutaj zresztą o czymś czego nie ma, bo możliwość korelacji
wątków i "wzbogacania" ich kontekstu o informacje dotyczące zadania/
request'u, to są rzeczy, które można dzisiaj zastosować w praktyce.
Co więcej mogą one "wykraczać" poza JVM - korelacja może dotyczyć
wątków z różnych procesów, w tym na różnych maszynach (np. wątki
serwera aplikacyjnego z wątkami/procesami bazy danych, czy
zewnętrznych systemów). Temat Work Context'ów (Work Area) i JSR-149
(niestety nieaktywnego już) był już na tej grupie poruszany. Skoro ta
informacja jest zawarta w kontekście zadania (=wątku/procesu/
tasku/...), to "nadzorca-ubijacz" potrafiący do tej informacji sięgnąć
mógłby całkiem precyzyjnie przerywać nawet zdania składające się z
etapów wykonywanych w rozproszonym środowisku - potencjalnie etapów
zrealizowanych w bardzo różnych technologiach. Co miałoby być tym
nadzorcą ? Od najniższego poziomu zaczynająć: hypervisor, OS,
dedykowany proces (agent) w OS, JVM/CLR/itp, middleware, ...
Oczywiście - przynajmniej dla aplikacji serwerowych Java EE - jedynym
warunkiem, aby można było zrobić takie "precyzyjne przerwanie", to
trzymanie się - rekomendowanych już od dawna - zasad. Na przykład
tej, że jeśli komponent serwerowy (servlet/EJB/RA/...) powołuje
"swoje" wątki (np. adapter JCA tworzy nowe wątki do obsługi
komunikacji ze zdalnym systemem), to do tego celu komponent powinien
skorzystać z mechanizmów oferowanych przez serwer aplikacyjny (np.
przywoływane już kilkakrotnie na tej grupie CommonJ Work Manager API
- notabene mechanizm, który ma być dostępny w ramach standardowej
specyfikacji Java EE 6 - JSR-237 i związany z nim JSR-236). Nad takimi
wątkami, serwer aplikacyjny _ma_ kontrolę. Tam gdzie tych mechanizmów
się nie używa (lub wprowadza się np. 'trikowy' kod natywny pozostający
poza kontrolą JVM), to pozostają rozwiązania bardziej
"katastroficzne" - jak to ubijanie całego modułu/aplikacji (włącznie z
opcją odmowy uruchomienia takiej aplikacji/komponentu przez serwer
aplikacyjny) lub - tak jak to dyskutowaliśmy było dyskutowane we
wcześniejszych postach - odwołanie się do wsparcia ze strony JVM/OS.
W podanej przez Ciebie opcji a, dużo oczywiście zależy od tego kiedy
wątek (będąc w A i/lub C) będzie uznany za 'stucked'. Tu
odpowiedzialność powinna spoczywać na programiście/administratorze,
którzy powinni ustalić jakąś wartość dla aplikacji/komponentu (np.
maksymalny czas wykonywania wątku w A to x sekund). W każdym razie,
możemy nad tym panować po jakim czasie przerywać działanie wątku.
W opcji b - podobnie: możliwe jest ubicie tylko określonego wątku (lub
wątków), wykonującego kod w C - zanim użyta będzie opcja wyłączenia
całego modułu C. Co do możliwości zakłócenia stanu modułu, to
specyfikacje Java EE narzucają tu pewne ograniczenia, choćby
wynikające z podziału komponentów na bezstanowe i stanowe. Świadomie
to obejść nie jest tak łatwo.
Co może ważniejsze - ryzyka w obu opcjach dotyczą w takim samym
zakresie wątków, jak i procesów. W Twoim przykładzie, jeśli A, B i C
będą procesami (a potrzeba wydajności wymusi, że dla każdego modułu
będą to raczej grupy procesów w pulach, z inter-process communication,
itd), to też można sobie wyobrazić takie "złe" scenariusze. Złe
zależności, czy złe zarządzanie stanem modułu, programista może
wprowadzić i tu, i tu. Ryzyka procesów i wątków są więc podobne.
Koszty (np. wydajność/skalowalność) jednak inne...
Ad 2
Po pierwsze, jak zawsze przy tego rodzaju zagadnieniach - wszystko
zależy od implementacji JVM i serwera aplikacyjnego (nie inaczej jest
w przypadku OS: Windows 95 i Linux to jednak dwie różne implementacje
tej samej koncepcji) - MVM jest też dobrym tego przykładem (MVM jest
zmodyfikowanym HotSpot JVM).
Po drugie, czasy w których modularyzacja aplikacji Java EE była
prostacka (np. możliwość deployment'u tylko jednej wersji modułu)
trochę mijają. Nadzieją jest tu OSGi, ale na upowszechnienie się OSGi
w Java EE wciąż trzeba poczekać (no i w zakresie zarządzania stanem,
to OSGi też specjalnie wiele nie wnosi). Można też skorzystać z innych
pomysłów, np. specyficznych rozszerzeń serwerów aplikacyjnych (i
poczekać na OSGi).
Po trzecie, _szczególnie_ jeśli chodzi o serwery aplikacyjne Java EE,
to narzucają one sporo dodatkowych restrykcji na mające w nich działać
aplikacje. Stanu JVM, czy kontenera z poziomu aplikacji Java EE
_bezpośrednio_ nie widać...
Ad 3
Sytuacja którą opisujesz - czyli różne moduły obsługiwane przez
niezależne wątki z przekazywaniem komunikatów nie jest w aplikacjach
Java EE rzadkością. Z powodów wydajnościowych serwer aplikacyjnych
stara się wykonać pojedyncze zadanie (np. request) przy użyciu TEGO
SAMEGO wątku (czyli np. kod servletu, EJB i wywołania JCA, bądź bazy
danych, będą _raczej_ wykonane przez ten sam wątek). Z drugiej strony,
wątek to zasób (serwera aplikacyjnego), więc - z tych samych powodów
wydajnościowych - jeśli możliwy jest podział zadania (=requestu) na
etapy wykonywane przez różne wątki, tak, aby uniknąć zbyt długiego
przetrzymywania tego zasobu przez jedno zadanie, to współczesne
serwery aplikacyjne to robią (w podanym powyżej przykładzie,
odpowiedź z JCA/RDBMS może być wykonywana na innym wątku niż request).
Wciąż - tak jak to opisałem w Ad 1 - możliwe jest przerywanie
działania KONKRETNYCH wątków (np. należących do danego zadania/
request'u). Zatem - nie trzeba sięgać aż po procesy...
Na marginesie: co do isolate w MVM, to tak jak to opisywałem wcześniej
- implementacja Czajkowskiego (a nie słyszałem o innej implmentacji
MVM) do realizacji isolates używała wątków OS (tam był to konkretnie
Solaris/SPARC).
> Druga kwestia jest wspoldzielenie przez moduly stanu wynikajace z uzywania
> wspolnych bibliotek dostarczanych przez runtime Javy i serwer aplikacyjny
> (takie wspoldzielenie stanu nie wystepuje pomiedzy procesami OS) - a to
> rowniez jest niebanalny problem.
Trochę się do tego odniosłem powyżej, ale:
- uważam, że specjalnych różnic znowu nie ma - procesy OS też
korzystają ze wspólnych zasobów (swoich - via IPC - i OS), bibliotek
OS i kernela. W obu przypadkach trzeba się podobnie "napracować", aby
akurat stan tych elementów zepsuć. Uważam nawet, że programiście
APLIKACJI _nieświadomie_ zepsuć ten stan jest nawet trudniej w
serwerze aplikacyjnym Java EE, bo zestaw 'narzędzi' (=API) jakimi
może się ten programista tu posługiwać, jest znacznie bardziej
ograniczony (potwierdza to choćby ten przykład z własnym zarządzaniem
wątkami w komponentach Java EE, gdzie aplikacja ma do dyspozycji w
zasadzie wyłącznie wątki z puli serwera aplikacyjnego). JVM także
wnosi tu dodatkową warstwę "zabezpieczającą". Dopiero następna w
kolejności tej ochrony jest warstwa OS.
- aplikacje Java, znowu: w _szczególności_ aplikacje Java EE - mają
specyficzne reguły widoczności i współdzielenia modułów
(classloading). Domyślne reguły narzucane tu przez specyfikację Java
EE i serwer aplikacyjny są dosyć restrykcyjne. Oczywiście, można je
_świadomie_ obejść, ale _świadomie_ można to też zrobić z procesami.
_Świadomie_ zakłada też, że ma się do tego uprawnienia - co dotyczy
tak samo procesów OS, jak i aplikacji na JVM/AppServer. Tu też JVM/
AppServer, będąc w stosie powyżej OS dodają "ochrony".
Pozdrawiam,
Waldek Kot
Waldek Kot
> Natomiast cala dyskusja wziela sie z pytania, czy stos:
> hypervisor+JRockitVE+JRockitJVM+serwer J2EE
> nadaje sie do uruchamiania wielu _niezaleznych_ programow (aplikacji Java) -
> czyli czy - innymi slowy - serwer J2EE moze zastapic system operacyjny.
No, to chyba trochę zbyt daleko wyciągnięty wniosek :-). Ta część
dyskusji w dużym stopniu dotyczyła tezy, iż JVM _inherentnie_ nie może
dać takiego poziomu separacji aplikacji, jaki daje procesom OS.
Pojawiły się pomysły jak JVM (ewentualnie JVM + dedykowany dla niej
OS) mogłyby go dać, w tym bazując na wykonanych implementacjach takich
JVM (MVM, JSR-121). Brak specjalnego zainteresowania tymi pomysłami
(przynajmniej na dzisiaj), może świadczyć o tym, że - zwłaszcza dla
aplikacji Java EE - ten poziom separacji jaki dają serwery aplikacyjne
jest dla dzisiejszego rynku wystarczający. Tylko więc dla aplikacji
Java EE można by rozważać, że serwer aplikacyjny w zakresie izolacji
aplikacji zastępuje/mógłby zastępować system operacyjny.
> Z czego ja wyciagam wniosek, ze nie ma sensu "wirtualizacja JVM", bo i tak
> trzeba odpalic wiele instancji serwerow J2EE, a to mozna taniej zrobic
> uruchamiajac wiele JVM w ramach jednego "normalnego" OS.
W jednym z wcześniejszych postów odpisałem, że takie porównanie maszyn
wirtualnych i procesów OS nie ma sensu (bo to porównywanie "jabłek do
gruszek"). Wirtualizacja w tej dyskusji NIE JEST czymś opcjonalnym.
Bez wirtualizacji (=hypervisora) NIE MA JRockit VE. Dyskusja o takim
dedykowanym dla JVM "OS" jakim jest JRockit VE i porównywanie go z
normalnym OS ma sens TYLKO, gdy zakładamy, że pod spodem jest
środowisko hypervisor'a.
Co do przydatności wirtualizacji w ogóle, to jest inna dyskusja.
Pewnych rzeczy bez wirtualizacji zrobić jest trudno. Przypadki, kiedy
wirtualizacja nie ma sensu (lub kosztuje zbyt dużo w stosunku do
korzyści) są raczej znane (i były przytaczane w jednym z postów
wcześniej).
Przy tym założeniu - odnosząc się do "taniej zrobić", to pytanie
brzmi:
czy taniej NA HYPERVISORZE odpalać aplikację Java (EE):
X maszyn wirtualnych (guest'ów) w których jest: normalny OS + JVM +
AS,
czy też taniej odpalać:
X guest'ów w których jest: dedykowany "OS" (JRockit VE) + JVM + AS ?
Ja starałem się przytaczać argumenty, że to drugie - nie tylko w
kontekście separacji aplikacji.
Pozdrawiam,
Waldek Kot