Java Cluster - implementacja, zastosowanie oraz zagadnienia wydajno´sciowe Piotr Pawlowski Instytut Informatyki Wydzial Elektroniki i Technik Informacyjnych Politechnika Warszawska e-mail:
[email protected]
Streszczenie—Artukul podzielony jest na trzy zasadnicze cze´ sci, kt´ orych celem jest kompleksowe opisanie , rozwiazania jakim jest Java Cluster. Pierwsza z nich , dotyczy implementacji samego rozwiazania i stanowi , wstep, k´ o ry pozwala na lepsze zrozumienie materia lu , znajdujacego sie, w dalszych cze´ sciach. Znajduje sie, , , te˙z tam opis wielu poprawek dotyczacych koncepcji , samego problemu w stosunku do projektu pierwotnego. Kolejna, zasadnicza, cze´ scia, kt´ ora, omawia artukul sa, , kwestie zwiazane z zastosowaniem stworzonego rozwiazania. Skupiono sie, tutaj gl´ ownie na tych proble, mach obliczeniowych dla kt´ orych Java Cluster powinien da´ c dobre wyniki wydajno´ sciowe. Om´ owiona jest te˙z charakterystyka problem´ ow, dla kt´ orych proponowane rozwiazanie sie, nie sprawdza. Na bazie analizy tych , zalo˙ze´ n stworzona jest cze´ s´ c trzecia, kt´ ora omawia , problemy wydajno´ sciowe, zasygnalizowane zostana, te˙z mo˙zliwosci potencjalnych poprawek, kt´ orych autor w 1 tej wersji rozwiazania nie zrealizowa l. ,
I. Wstep , Java Cluster powstaje jako rozwiazanie majace na celu , , ulatwienie oblicze´ n r´ ownoleglych. W wielu dziedzinach nauki i techniki coraz cze´sciej spotykamy sie, z du˙zymi, bad´ wielkimi problemami obliczeniowymi. Coraz , z wrecz , wieksza ilo´ s ci danych do przetworzenia, sprawia z˙ e musimy , cze´ s ciowo zmieni´ c swoje podej´scie do wielu zagadnie´ n , algorytmicznych. Jednocze´snie pojawianie sie, wielordzeniowych procesor´ ow powoduje z˙ e algorytmy sekwencyjne wcze´sniej czy p´ o´zniej bed owno, a, przepisywane na wersje r´ legle, tak aby zapewni´c maksymalne wykorzystanie procesora.Wynika z tego z˙ e wiele problem´ ow obliczeniowych be, dzie przystosowanych do architektur r´ ownoleglych. Przystosowanie to za´s nie jest trywialne, bowiem w wielu przypadkach wymaga zmiany podej´scia do problemu, innej organizacji struktur danych i samych algorytm´ ow.
Java Cluster jest rozwiazaniem, kt´ ore ma pozwoli´c na , tworzenie algorytm´ ow obliczeniowych w taki spos´ob jak by´smy pisali je na procesory wielordzeniowe, z ta, ro˙znica, 1 Praca ta powstala w ramach seminarium dyplomowego na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej w 2008 r.
z˙ e cale obliczenia bed , a, wykonane w ramach odzielnych maszyn skladajacych si e, na klaster. Jednym z gl´owych zalo˙ze´ n , podczas projektowania bylo stworzenie mechanizmu pozwalajacego na latwe pisanie kodu aplikacja, mechanizmu, , kt´ory pozwoli sie, skupi´c programi´scie gl´ownie na koncepcji samego rozwiazania oraz implementacji w przyjemnym i , bezpiecznym ´srodowisku programistycznym. Zupelnie niezasadne wydaje sie, z˙ e w wielu rozwiazaniach tego typu , programista musi jawnie dba´c o komunikacje, , pomiedzy , procesorami ( tak um´ownie nazwijmy maszyny liczace , nasze zadanie obliczeniowe ). Taki podej´scie nie tylko powoduje spore za´smiecanie kodu zbednymi wywolaniami , ale nara˙za nas na wprowadzanie bled´ o w. Jednocze´snie , pelna automatyzacja i zabranie u˙zytkownikowi mo˙zliwo´sci ingerencji w pewne zagadnienia techniczne te˙z nie jest dobrym pomyslem, gl´ownie dlatego z˙ e czesto odbija sie, , to na wydajno´sci rozwiazania, a ta w tym przypadku , jest rzecza, kluczowa., W zwiazku z tym podczas tworzenia , Java Cluster skupiono sie, gl´ownie na tym aby stworzy´c rozwiazanie, kt´ore bedzie kompromisem je˙zeli chodzi o , , powy˙zsze parametry. Zrezygnowano z konieczno´sci podawania wprost gdzie i kiedy ma zachodzi´c komunikacja, jednak pozostawiono mo˙zliwo´s´c definiowania co ma by´c synchronizowane oraz co ma by´c migrowane na inny weze , l. Aby osiagn , a´ ,c powy˙zej opisane cele konieczna byla modyfikacja JDK na poziomie jadra maszyny wirtualnej oraz , bibliotek standardowych, co odpowiada drugiej i trzeciej warstwie od dolu na rysunku numer jeden. Java Cluster jest rozwiazaniem, kt´ore powstalo w opar, ciu o Java 6 SE. Wyb´or ten byl motywowany tym i˙z po pierwsze istniala potrzeba stworzenia takiego rozwiazania , dla jezyka Java, kt´ore bedzie dedykowane do oblicze´ n , , r´ownoleglych i mniej og´olne ni˙z Java RMI, oraz tym z˙ e Sun zdecydowal sie, na publikacje, kodu ´zr´odlowego calej platformy na licencji JRL ( Java Research License ). II. Java Cluster - projekt i implementacja Architektura Java Cluster jest rozwiazaniem, kt´ore pracuje w archi, tekturze klient - serwer. Klientem jest maszyna, kt´ ora inicjalizuje obliczenia, serwerem za´s maszyna, kt´ ora te obliczenia bedzie realizowala.Serwery tworza, strukture, grafu, ,
klanym. Migracja odbywa sie, poprzez umieszczenie kodu algorytmu w ciele gl´ownej metody watku. Watek jest pod, , stawowym bytem szeregowanym przez maszyne wirtualna,, pozwalajacym na wsp´olbie˙zno´s´c w przypadku wykonania , algorytmu na jednym procesorze oraz r´ownoleglo´s´c w momencie kiedy pracujemy w ´srodowisku klastra. Watki, , kt´ore maja, podlega´c migracji musza, dziedziczy´c po klasie RemoteThread. Architektura klient - serwer jest intuicyjna i porzadkuje rozwiazanie pod wzgledem wykonywanych , , , czynno´sci. Java Cluster jedak dzili sie, jeszcze na JC-API ( Java Cluster - API ) i JC-NODE ( Java Cluster - NODE ),dwie dodatkowe warstwy, kt´ore wynikaja, z implementacji samego rozwiazanie.Mo˙ zna powiedzie´ , , c z˙ e podzial na klient - serwer jest pionowy, za´s na JC-NODE i JC-API poziomy. Konsekwencja, tego jest to z˙ e zar´owno klient jak i serwer posiadaja, te dwie warstwy i z nich korzystaja.,
Rysunek 1.
JDK 6 - architektura systemu
Rysunek 2.
Architektura
klient musi umie´c polaczy´ c sie, tylko z jednym serwerem , aby pozna´c strukture, reszty sieci. Serwery mo˙zna w tym rozwiazaniu por´ owna´c do zdal, nych procesor´ ow zdalnych i to okre´slenie bedzie u˙zywane , w dalszej cze´ s ci opracowania. Nie wszystkie obliczenia , klienta musza, by´c migrowane, to programista decyduje co ma sie, wykona´c na zdalnym procesorze a co na lo-
JC-API (Java Cluster - API) JC-API jest to zbi´or sl´ow kluczowych oraz klas jezyka , Java, kt´ore sa, udostepnione programiscie aby m´ ogl on w , spos´ob ´swiadomy tworzy´c swoje algorytmy. Kluczowym zalo˙zeniem przy tworzeniu JC-API bylo to aby do maksimum wykorzysta´c ju˙z istniejace Java rozwiazania , w jezyku , , i co wa˙zne zachowa´c ich znaczenie. Dzieki takiemu podej, ´sciu mo˙zliwe jest te˙z du˙zo latwiejsze przeprojektowywanie algorytm´ow, kt´ore sa, ju˙z napisane w Javie pod nowe rozwiazanie.Kluczowymi elementami jezyka, kt´ore skladaja, , , sie, na JC-API sa:, • synchronized • transient synchronized jest slowem kluczowym, kt´orego u˙zycie zapewnia synchornizacje, watk´ , ow w ramach calego klastra. Tak jak w przypadku wersji standardowej maszynu wirtualnej gdzie synchronizowane byly lokalne watki, sekcja , krytyczna jest pozyskiwana w kontek´scie jakiego´s obiektu, monitora. Sekcja krytyczna jest te˙z mechanizmem, kt´ ory zapewnia nam sp´ojno´s´c danych na kt´orych pracujemy, czyli przy zalo˙zeniu z˙ e algorytm jest poprawnie napisany pracujemy zawsze na aktualnych danych. Aby zrozumie´c dlaczego tak sie, dzieje nale˙zy sie, wgledbi´ c w to w jakis , spos´ob Java Cluster operuje na danych. Wiadomo bowiem z˙ e w ´srodowisku klastrowym je˙zeli chcemy pracowa´c na wsp´olnych danych to odwolywanie sie, do jednej wsp´ olnej kopii jest pomyslem do´s´c kiepiskim. Jest tak tylko i wylacznie ze wzgledu na zagadnienia wydajno´sciowe, , , wiadomo bowiem z˙ e odowlanie do loklanej pamieci jest , du˙zo szybsze ni˙z do pamieci, kt´ o ra jest na innym kompu, terze. Z tego powodu zdecydowano sie, na replikacje, danych podczas migracji. Zalo˙zono z˙ e ka˙zdy zdalny watek pracuje , na swojej kopii danych i ta kopia zawsze jest aktualna. Aktualno´s´c tej kopii zapewnia wla´snie sekcja krytyczna, kt´ora dba aby w momencie kiedy wchodzimy do niej zaciagn , a´ ,c aktualne wersje danych ( w tym te˙z obiektu na kt´orym sie, synchronizujemy ) oraz aby podczas wychodzenia z owej sekcji wysla´c zaktualizowane dane.Ka˙zdy obiekt posiada sw´oj identyfikator, kt´ory jest nadawany przez
klienta, aktualizacja danych zachodzi tylko w przypadku kiedy wersja, obietku sciagni etego jest wieksza ni˙z wersja , , , obiektu bie˙zacego. Operacja ta jest realizowana na pozio, mie deserializacji. Wynika z tego z˙ e wymiana danych w obrebie jednego watku zachodzi dwa razy tyle ile jest sekcji , , krytycznych. Kolejnym slowem kluczowym jest transient, kt´ ore pozwala na zadeklarowanie czy dany atrybut klasy ma by´c serializowany czy nie. Serializacja jak wiadomo jest procesem zamiany jakiego´s zbioru danych, obiekt´ow w taka, forme, z kt´ orej mo˙zna je odtworzy´c i przywr´ oci´c stan obiektu. Nie zawsze jednak piszac nasz algorytm chcemy , aby wszystkie zmienne byly serializowane i sila, rzeczy migrowane na inny procesor. Dzieki temu mechanizmowi , mo˙zna w znaczacy spos´ o b przy´ s pieszy´ c wymiane, danych. , Kolejnym wa˙znym elementem JC-API jest zestaw klas, kt´ ore pozwalaja, na tworzenie aplikacji r´ ownoleglych.Z punktu widzenia programisty jedyna, godna, uwagi klasa, jest RemoteThread. Klasa ta reprezentuje migrowany wa, tek i tylko watki, kt´ orych klasy dziedzicza, z tej klasy sa, , migrowane. Aby wydajnie i ´swiadomie konstruowa´c algorytmy r´ ownolegle istotna jest dla nas informacja na temat tego na ile procesor´ ow mo˙zemy wysla´c nasze obliczenia. Informacja ta musi by´c podawana w spos´ ob dynamiczny i bazowa´c na aktualnym stanie sieci. Aby zapewni´c ta, funkcjonalno´s´c do klasy java.lang.System dodano metode, getNodeCount(). Wywolanie tej metody powoduje synchroniczne odpytanie serwera/procesora o to z iloma innymi wez warto´s´c zwracana jest , lami ma polaczenie, , to wlasnie ta liczba plus jeden. Dodatkowa, informacja,, kt´ ora, mo˙zemy uzyska´c jest weze , l/procesor. Dostep , do tego parametru uzyskujemy dzieki metodzie System.getNode( , int nodeNumber ). Wynikiem tej metody jest identyfikator wez ory mo˙ze nam po´slu˙zy´c jako parametr klasy Remo, la, k´ teThread, co bedzie oznaczalo z˙ e watek zostanie zmigro, , wany wla´snie do tego wez la. W przypadku niepowodzenia , migracji, cale obliczenia rozpoczynaja, sie, od poczatku. , Wa˙zne jest zauwa˙zenie tutaj z˙ e migracja watk´ , ow mo˙ze odbywa´c sie, wedlug dw´ och strategii, pierwsza z nich polega na losowym romieszczeniu watk´ oz˙ nych proceso, ow na r´ rach, a to na jakie procesory obliczenia trafia, nie jest istotne z punktu widzenia algorytmu. Druga za´s metoda pozwala na dokladne wskazanie procesora na kt´ orym dane obliczenia bed ocz , a, wykonywane. Informacja o we´ , zle opr´ lokalizacji wez srednim obcia, la zawiera informacje, o jego ´ , z˙ eniu. Pozwala to tw´ orcy algorytmu na stosowanie r´oz˙ nych wsp´ olczynnik´ ow i finalnie profilowanie swojego algorytmu pod kontem systemu. JC-NODE (Java Cluster - NODE) JC-NODE jest to zestaw klas, kt´ ore skladaja, sie, na konstrukcje, serwera oraz klienta. Jest to warstwa, kt´ ora znajduje sie, poni˙zej JC-API. To wla´snie wykorzystujac , JC-API wykonywany program komunikuje sie, z JC-NODE. Podstawowym elementem JC-NODE po stronie klienta jest ThreadClient. Jest to element, kt´ ory laczy sie, ze , zdalnym procesorem, czyli naszym serwerem i rozpoczyna
Rysunek 3.
Java Cluster - komunikacja
migracje.Ka˙ zdy klient ma uniklany identyfikator w , sieci.W momencie kiedy migracja jest mo˙zliwa przesylany jest obiekt watku i uruchamiany na zdalnym procesorze. , Drugim niezwykle istotnym mechanizmem je˙zeli chodzi o cze´ c kliencka, jest serwer sekcji krytycznej. Warto , s´ zauwa˙zy´c z˙ e je˙zeli chodzi o synchronizacje, to wla´snie klient, weze jest serwerem. A wiec scie , l zlecajacy , , ka˙zde wej´ do sekcji krytycznej powoduje odwolanie do serwera sekcji krytycznej. Serwer ten pozwala na zachowanie wielowej´sciowo´sci, tzn. je˙zeli dany watek posiada sekcje , krytyczna, i chce do niej wej´s´c to mu sie, to uda ( w przypadku zwyklego mutexu doszlo by do zakleszczenia ).Cze´ c kliencka posiada zawsze najaktualniejsze dane , s´ i to z niej sa, one ´sciagane przez procesor zdalny , w momencie wchodzenia do sekcji krytycznej oraz wgrywane w momencie wychodzenia z sekcji krytycznej.W momencie tworzenia nowego obiektu jest nadawany mu jednoznaczny identyfikator bed kolejnym numerem , acy , z sekwencji.Numer ten jest wsp´olny dla calej instancji maszyny wirtualnej po stronie klienckiej i jest nadawany w czasie wywolywania operatora tworzacego instancje, , obiektu. Strona serwerowa JC-NODE jest to w zasadzie sie´c powiazanych ze soba, procesor´ow, reprezentowanych , przez klase, ThreadServer. Zalo˙zeniem tej sieci jest to z˙ e ka˙zdy serwer zna lokacje, oraz ´srednie obciazenie , wszystkich swoich sasiad´ ow. Stan sieci jest aktualizowany , w czasie pracy w spos´ob dynamiczny, co powoduje z˙ e laczac smy w stanie , sie, do dowolnego serwera jeste´ obserowa´c jej obcia˙ z enie oraz dzia laj ace watki.Serwer , , , jest jednostka, autonomiczna,, do jego dzialania nie jest
potrzebny z˙ aden klient, serwer te˙z nie zleca sobie z˙ adnych zada´ n. Serwer pelni funkcje, uslugowa, wzgledem klienta , i stara sie, aby zadanie mu powierzone bylo wykonane w spos´ ob optymalny. Optymalno´s´c oznacza z˙ e serwer nie podejmie sie, wykonywania z˙ adnych oblicze´ n je˙zeli w jego otoczeniu sa, serwery mniej obciazone. Obci a˙ , ,zenie serwera jest liczone jako suma czas´ ow wykonywanych watk´ , ow przez przez ilo´s´c procesor´ ow. Im mniejszy wsp´ olczynnik tym serwer jest mniej obcia˙ ,zony. Miara ta jest stosunkow prosta, mo˙zliwe jest z˙ e w przyszlo´sci zostanie uzupelniona. W przypadku nie podjecia sie, oblicze´ , , n, sa, one delegowane do najmniej obica˙ z onego w danej chwili serwera. , Delegacja jest procesem jednorazowym. Obsluga sytuacji wyjatkowych je˙zeli chodzi o JC-NODE nie jest w tej , wersji systemu specjalnie zawansowana. W przypadku gdy od systemu odlaczy sie, klient i po pewnym czasie nie , nawia˙ z e z nami po l aczenia wszystkie obliczenia zostaja, , , zaprzestane. Jest to zrozumiale gdy˙z skoro nie istnieje zleceniodawca dla kt´ orego realizujemy dane zadanie, to jak jest sens kontynuowania go. W przypadku gdy podczas oblicze´ n oka˙ze sie, z˙ e nie ma komunikacji z serwerem wszystkie obliczenia sa, ponawiane. Aby przesyla´c dane pomiedzy klientem a serwerem , konieczne jest zapisanie ich w zrozumialym dla nich formacie. Proces ten nazywa sie, serializacja, i pozwala na odtworzenie stanu obiektu z chwili zapisania, zserializowania go.W przypadku rozwiazania , Java Cluster zdecydowano sie, na skorzystanie ze standardowego mechanizmu serializacji klas do warto´si binarnych.Wybrano takie podej´scie poniewa˙z serializacja binarna jest stosunkowo szybka a co wa˙zne jest silnie zintegorwana z sama, maszyna., Wymusza to tylko jedna, niedogodno´s´c dla programisty, je˙zeli nie oznacza obiekt´ow jako transient to musza, one implementowa´c interfejs Serializable.
III. Java Cluster - zastosowanie Java Cluster jest rozwiazaniem, kt´ ore zostalo stworzone , z my´sla, o obliczeniach r´ ownoleglych. Obliczenia r´ ownolegle maja, zastosowanie w wielu dziedzinach nauki i techniki. Potrzeba zr´ ownolegalania niekt´ orych algorytm´ow jest zwiazana z ch eci a a niekiedy konieczno´ scia, przy´spieszenia , , , oblicze´ n. Przykladowo proces wyliczania, analizy danych statystycznych do prognozowania pogody na nastepny , dzie´ n nie mo˙ze zwyczajnie trwa´c dlu˙zej ni˙z dwadziescia cztery godziny. Oczywi´scie nale˙zy pamieta´ , c z˙ e samo uruchomienie algorytmu w ´srodowisku klastrowym nie oznacza gwaltownego przy´spieszenia, co wiecej mo˙ze spowodo, wa´c z˙ e pojawia, sie, spore op´ o´znienia. Warto zauwa˙zy´c z˙ e zgodnie z prawem Amdahla je˙zeli nasz algorytm posiada znaczac s´c miejsc, kt´ orych zr´ ownolegli´c sie, nie da, , a, ilo´ to samo dokladanie nowych procesor´ ow nie spowoduje
a˙z tak wielkiego wzrostu wydajno´sci, gdy˙z te wlasnie miejsca bed gardlem. Przykladowo gdy jaka´s , a, waskim , cze´ s ´ c oblicze´ n , kt´ o re s a ownoleglone zajmuje t × 100%, , , zr´ zostanie przy´spieszona n krotnie, to caly proces zostanie 1 c co z przy´spieszony tylko o (1−t)+ t razy. Aby zobrazowa´ n tego prawa wynika warto jest rozwiaza´ c przyk ladowe zada, nie. Zal´oz˙ my z˙ e mamy algorytm w kt´orym 90% operacji da sie, zr´ownolegli´c, za´s 10Przy´spieszmy teraz te operacje dziesieciokrotenie, dokladaja´c nowych 10 procesor´ ow. , W tym przypadku caly program przyspieszy dokladnie 1 1 = 0.19 = 5.26 razy. Gdy bedziemy pr´ obowali , (1−0.9)+ 0.9 10 dolo˙zy´c sto procesor´ow przy´spieszenie wyniesie 9.17 raza.Wynika z tego jednoznacznie z˙ e je˙zeli chcemy mysle´c o obliczeniach r´ownoleglych to musimy znieni´c konstrukcje, naszych algorytm´ow, samo dokladanie nowych jednostek obliczeniowych nie spowoduje gwaltownego wzrostu wydajno´sci.Kluczowym slowem jest tutaj dekompozycja problemu, czyli takie przeksztalcenie algorytmu aby mo˙zna bylo go podzieli´c na du˙ze niezale˙zne od siebie elementy. Dobrym przykladem, co prawda do´s´c trywialnym jest dodawanie macierzy. Warto zauwazy´ , c z˙ e sam problem w zasadzie jest zdekomponowany od poczatku, bowiem polaga na tym i˙z wynikowa macierze jest tworzona poprzez wykonywanie niezale˙znych wzgledem siebie dodawa´ n. Taka, , operacje, mo˙zna przykladowo zdekomponowa´c wzgledem , wierszy, bad´ , z grup wierszy. Je˙zeli macierz podzielimy na p´ol i do ka˙zdego z dw´och porcesor´ow wy´slemy odpowiednia, pol´owke, spieszenie oblicze´ n powinno wyno´si´c , to przy´ w przybli˙zeniu sto procent. Wszystkie ewentualne straty beda wynikaly z koszt´ow komunikacji miedzy maszynami. , , Problem ten jest wrecz idelany je˙ z eli chodzi o obliczenia, , bowiem nie ma z˙ adnej synchronizacji oblicze´ n, co wiecej , dane sa, przesylane tylko na poczatku i podczas zbierania , wynik´ow. Niestety w przypadku bardziej zaawansowanych algorytm´ow, problem nie jest a˙z tak trywialny i sama dekompozycja jest do´s´c skomplikowanym zadaniem. Obliczenia r´ownolegle sa, dziedzina, informatyki, kt´ ora jest w dzisiejszych czasach do´s´c rozwinieta, istnieje wiele , centr´ow naukowych, kt´ore sie, w nich specjalizuja., Obowia, zujacym standardem bibliotek do oblicze´ n r´ownoleglych , w dzisiejszych czasach wydaje sie, by´c MPI ( Message Passing Interface ). Jest to rozwiazanie zaawansowane i , popularne w ´srodowisku naukowym. Java Cluster stara sie, stworzy´c ´srodowisko pracy pozwalajace realizowa´c po, dobne zadanie jednak bez wnikania w zbedne szczeg´ oly, , co wiecej z za lo˙ z enia uruchomienie i konfiguracja klastra , ma by´c blyskawiczna i wrecz natychmiastowa. To co jest , istotna, zaleta, rozwiazania jest to z˙ e w gruncie rzeczy , jeste´smy w du˙zej mierze niezale˙zni od architektury sprze, tu na kt´orym uruchamiamy nasza, aplikacje, r´ownolegla., Mo˙ze to by´c maszyna z procesorem Intela i systemem Windows XP ale te˙z nic nie stoi na przeszkodzie z˙ eby byl to Sun Solaris z procesorami SPARC. Co wiecej wszystkie , te architektury moga, by´c polaczone w jeden klaster i ,
Rysunek 4.
Java Cluster - ´srodowisko pracy
wsp´ olpracowa´c ze soba., Uzycie okre´slenie klaster nie jest przypadkowe i nie jest te˙z bledne. O klastrach zwyklo , sie, m´ owi´c z˙ e, sa, to systemy homogeniczne, za´s gdzie w przypadku Intelowego komputera z Windows XP i Solarisa mo˙zna m´ owi´c o klastrze, bardziej prezentuje sie, to jako grid obliczeniowy. Nale˙zy jednak zwr´ oci´c uwage, z˙ e klaster tworzy tutaj ´srodowisko Java kt´ ore przykrywa wiele r´oz˙ nic miedzy tymi systemami. Przestaja, nas interesowa´c kwestie , dotyczace architektury systemu i ´srodowiska na jakim , on pracuje, wa˙zne sie, staje tylko to z˙ e jest to aplikacja Javowa. Dzieki c ka˙zda, maszyne, , temu mo˙zemy wykorzysta´ , kt´ ora, mamy pod rek a do oblicze´ n r´ o wnoleg lych. Jedyne co , , nas interesuje to poprawne skonstruowanie algorytmu. Java Cluster jest rozwiazaniem dedykowanym do ob, licze´ n r´ ownoleglych, uruchamianie na platformie r´ownoleglej algorytm´ ow, kt´ ore wymagaja, bardzo czestej syn, chronizacji, kt´ ora stanowi waskie gardlo nie jest wskazane , przy tym rozwiazaniu. W przypadku takich problem´ow o , wiele lepszym pomyslem jest napisanie algorytmu sekwencyjnego ni˙z my´slenie o r´ ownoleglo´sci. Nale˙zy pamieta´ , c z˙ e sam proces synchronizacji jest do´s´c kosztowny je˙zeli chodzi o wydajno´s´c, co wiecej powoduje z˙ e wszystkie procesory , moga, czeka´c i w danym momencie wykonuje sie, tylko jedno zadanie. Tak jak to wynika z prawa Amdahla, nawet dokladaja´ maszyn, samo przy´spieszenie mo˙ze by´c ,c wiecej , malo znaczace. Co wiecej prawo Amdahla pomija kosz, , ty jakie sa, ponoszone przy komunikacji. Koszty te przy bardzo du˙zych zadaniach, gdzie musimy przesyla´c spore ilo´scu danych moga, by´c znaczace. Nale˙zy wiec , , najpierws skrupulatnie przeliczy´c i przeanalizowa´c algorytm pod kontem element´ ow blokujacych zanim zadecydujemy sie, , na realizacje, go w ´srodowisku r´ ownoleglym, takim jak Java Cluster.
Wa˙znym elementem w przypadku konstruowania algorytmu jest te˙z zastanowienie sie, nad tym w jaki spos´ob pobieramy dane do oblicze´ n. Bardzo czest , a, praktyka, progrmiast´ow, kt´ora jest jak najbardziej godna pochwaly jest otwieranie strumienia danych i zaczytywanie z niego kolejnych warto´sci. O ile takie podej´scie jest zasadne w przypadku pracy na loklanej maszynie, gdzie odczyt ze strumienia jest stosunkowo szybki, to w przypadku ´srodowiska r´ownoleglego, nale˙zy pamieta´ , c z˙ e odzczyt z tego strumienia mo˙ze by´c wolny, gdy˙z ´zr´odlo z kt´ orego czytamy nie znajduje sie, na loklanej maszynie. Problem zaczyna sie, robi´c w momencie kiedy istnieje proces, kt´ ory pisze do tego strumienia z kt´orego my czytamy. Wtedy oczywi´scie procesy czytajace, musza, czeka´c na zako´ nczenie , zapisu, je˙zeli chcemy liczy´c na to z˙ e nasz algorytm da poprawne wyniki. Powowduje to z˙ e w pewien ukryty, bad´ , z nie, spos´ob musimy sie, synchronizowa´c na zasobie jakim jest strumie´ n. Zdecydowanie nie jest to najlepszy pomysl, gdy˙z mo˙ze wprowadzi´c znaczne op´o´znienia. Aby rozwiaza´ , c ten problem dobrym pomyslem jest buforowanie danych do przeliczenia. Przykladowo je˙zeli mamy do przeliczenia ogromny, zb´or danych, kt´ore nie maja, szans zmie´sci´c sie, w pamieci, to wtedy dzielimy dane na te segmenty, kt´ ore w , pamieci mog a si e zmie´ s ci´ c . Te w la´ s nie segmenty stanowi a, , , , podstawe, do oblicze´ n na zdalnym procesorze. Co wiecej w , momencie kiedy dane te zostana, wyslane mo˙zemy pamie´ ,c przez nie zaalokowana, wykorzysta´c do zaciagni ecia danych , , potrzebnych dla nastepnego procesora. Podobny schemat , ma miejsce w momencie zbierania wynik´ow. Jedyna wada tego rozwiazania to sekwencyjne wysylanie danych do , liczenia i delegowanie zada´ n. Nie jest to jednak powa˙zny problem bowiem je˙zeli zadanie liczone na zdalnym procesorze jest du˙zo dlu˙zsze ni˙z sama komunikacja, co jest warunkiem koniecznym aby stosowa´c Java Cluster, to wtedy z du˙zym prawdopodobie´ nstwem wyniki zaczna, wraca´c w tej samej kolejno´sci co byly wysylane ( czyli procesor, kt´ory pierwszy otrzymal dane sko´ nczy wcze´sniej ) i straty wydajno´sciowe nie powinny by´c du˙ze. scie , Oczywi´ je˙zeli pierwszy procesor jest dziesie´ c razy wolniejszy ni˙z , drugi to prawidlowo´s´c nie zajdzie w takim stopniu w jakim zostala opisana powy˙zej. Nie jest to jednak problem kluczowy bowiem nawet w pesymistycznym przypadku samo przesylanie powinno stanowi´c stosunkowo maly procent czasu potrzebnego na obliczenie problemu. ´ rozwiazania IV. Java Cluster - wydajno´ sc , Aby rozpocza´ c rozwa˙ z ania dotycz ace wydajnos´ci roz, , wiazania nale˙zy najpierw om´owi´c kwestie wydajno´sciowe , zwiazane z samym ´srodowiskiem w jakim system zostal , stworzony.Powszechnie panujacym przekonaniem w´sr´ od , programist´ow, projektant´ow system´ow informatycznych jest to z˙ e Java jako ´srodowisko jest wolna. Opinia ta wywodzi sie, w gl´ownej mierze z pierwszych lat istnienia rozwiazania Suna na rynku informatycznym. Nikt nie za, mierza sie, sprzecza´c z tym z˙ e pierwsze wersje, gl´ownie 1.0,
1.1 nie nale˙zaly do demon´ ow szybko´sci. Gl´ owna, przyczyna, tego stanu rzeczy bylo zastosowanie interpretacji jako gl´ ownego mechanizmu przetwarzania kodu. Oczywistym jest z˙ e intepretacja sama w sobie jest malo wydajna, gdy˙z obcia˙ ,za procesor w zbytnim stopniu ni˙z to jest potrzebne, gl´ ownie dlatego z˙ e konieczne jest ciag , le tlumaczenie kawalk´ ow kodu na istrukcje procesora nawet je˙zeli te instrukcje byly ju˙z wcze´sniej wykonywane. Sam proces tluaczenia te˙z mo˙ze, by´c zrealizowany na wiele sposob´ow. W dzisiejszej wersji maszyny wirtualnej stosowany jest tzw. just in time compiler. Kod programu napisany w javie jest kompilowany do wersji po´sredniej zwanej bajtkodem. Sam bajtkod jest to kod natywny javy. Mo˙zna go por´owna´c do kodu maszynowego, jednak nale˙zy pamieta´ , c z˙ e zawiera on wiele do´s´c wysokopoziomowych instrukcji, odwola´ n. Bajtkod jest tym co przetwarza maszyna wirtualna, przy czym samo przetwarzanie dziala w do´s´c specyficzny spos´ ob, bowiem konkretne instrukcje bajtkodu, sa, tlumaczone na natywny kod procesora. Tlumaczenie odbywa sie, dokladnie raz i w momencie ponownego odwolania do konkretnej instrukcji bajtkodu, jest automatycznie brana jej natywna reprezentacja.Dzieki temu sam proces prze, twarzania programu jest o wiele szybszy, szczg´olnie z˙ e z biegiem dzialania aplikacji r´ oz˙ nice miedzy programem , napisanym w jezyku ni˙ z eszgo poziomu, jakim jest C/C++ , sie, zmniejszaja., Kolejnym zaskoczeniem je˙zeli chodzi o sama, maszyne, wirtualna, jest to z˙ e alokacja pamieci nie , koniecznie musi by´c wolniejsza ni˙z w przypadku wywola´ n systemowych. Oczywi´scie jednokrotne wywolanie alokacji jest wolniejsze, tutaj nie ma watpliwo´ sci. Je˙zeli we´zmie sie, , jednak pod uwage, program, kt´ ory dziala przez pewien czas to statystycznie alokacja i zwalnianie pamieci potrafi by´c , nawet szybsza ni˙z przy konwencjonalnych rozwiazaniach, , nie m´ owiac , ju˙z o tym z˙ e o wiele bezpieczniejsza. To co jest faktycznie wolniejsze w przypadku Javy, to operacje wej´scia - wyj´scia, wedlug wylicze´ n potrafia, by´c one do trzech, czterech razy wolniejsze. Jednak operacje te przy´spieszaja, z wersji na wersje. , Nie nale˙zy te˙z ukrywa´c z˙ e operacje graficzne, jako w pewnym sensie wariant I/O sa, te˙z wolniejsze, czego przykladem mo˙ze by´c Java Swing ( mimo i˙z w ostatnich latach dzieki usilnym staraniom developer´ ow Suna, przy´spieszy, la ona wielokrortnie, glownie dzieki silnemu wsparciu ze , strony maszyny wirtualnej ).
W przypadku oblicze´ n r´ ownoleglych wydajno´s´c ma bardzo du˙ze znaczenie. Nale˙zy jednak potraktowa´c kwestie wydajno´sciowe w troche, inny spos´ ob. Szybko´s´c z jaka, sa, wykonywane dodawania i mno˙zenia jest istotna, jednak nie jest moim zdaniem kwestia najwa˙zniejsza, szczeg´ olnie z˙ e w dzisiejszych czasach r´ oz˙ nice miedzy natywnymi platforma, mi a maszynami wirtualnymi sie, zacieraja., Najistotniejsze jest to aby dokona´c takiego rozkladu problemu, z˙ eby obliczenia mialy szanse wykobywa´c sie, r´ ownolegle w prawdziwym tego slowa znaczeniu. Java Cluster nie jest jeszcze
Rysunek 5.
Rysunek 6.
Por´ ownanie I/O dla Java 1.5 i Java 1.6
Jezyki programowania - por´ ownanie wydajno´sciowe ,
rozwiazainem przetestowanym, wiele eksperyment´ ow musi , jeszcze by´c wykonanych aby mo˙zna bylo dokona´c pelnego por´ownania z innymi istniejacymi rozwiazaniami. Jednak , , to czego mo˙zna sie, spodziewa´c nie powinno znaczaco , odbiega´c od istniejacych rozwiaza´ , , n. Oczywistym jest z˙ e w stosunku do platform natywnych dla danej architektury bed oz˙ nice wydajno´sciowe, gl´ownie spowodowa, a, pewne r´ ne przez sama, architekture, maszyny wirtualnej. Jednak tak jak w ka˙zdym rozwiazaniu technologicznym istnieje , kwestia kompromisu. Nawet je˙zeli tracimy troche, na wydajno´sci, kt´ora to strata bedzie gl´ownie dotyczyla, operacji , wykonywanch sporadycznie, to zyskujemy na przeno´sno´ci i bezpiecze´ nstwie kodu, kt´ory tworzymy. Je˙zeli we´zmiemy pod uwage, z˙ e Sun pracuje teraz nad wersja siedem maszyny wirtualnej, kt´ora bedzie wyko, rzytywala wielordzeniowe procesory, to mo˙zemy liczy´c na powa˙zne przyspieszenie oblicze´ n na architekturach klastrowych wykorzytujace te jednostki. , V. Podsumowanie Java Cluster to bardzo mlode rozwiazanie, nie bed , , ace , jeszcze w pelni uko´ nczone. Jest to pewnego rodzaju proff of concept na bazie k´orego mo˙ze uda sie, kiedy´s wytworzy´c co´s co bedzie rozwiazaniem docelowym.Kilka rzeczy , , bedzie jeszcze wymaga lo dopracowania, co wiadomo ju˙z , dzi´s. Jedna, z podstawowych bolaczek, zakladajac z˙ e ,
´srodowisko pracy, w k´ orym obliczenia bed , a, wykonywane nie jest stabilne, jest to z˙ e odlaczenie sie, dowolnego , z wez l´ o w, na kt´ o rym jest wykonywana cz e´ c oblicze´ n, , , s´ powoduje anulowanie pracy reszty wez l´ o w i rozpocz ecie , , wykonywania algorytmu od poczatku. Aby tego unikna´ , ,c trzeba by zrealizowa´c co´s w stylu dzinnika log´ ow, kt´ory bedzie pozwalal na wr´ ocenie sie, do tego momentu oblicze´ n , gdzie wszystko jeszcze przebiegalo dobrze i rozpoczecie , ich na innej maszynie. Takie podej´scie jest jednak pracochlonne i warto sie, zastanowi´c kiedy ma ono sens. Moim zdaniem w ´srodowiskach w kt´ orych to rozwiazanie , bedzie wykorzytywane, czyli sie´ c LAN, stan sieci i maszyn , jest stosunkowo stabilny i potencjalne awarie powinny sie, zdarza´c sporadycznie. Kolejna, optymalizacja, nad kt´ ora, warto pomy´sle´c jest przesylanie tylko zmienionych danych. W obecnym rozwiazaniu gdy wchodzimy do sekcji krytycznej sciagamy , , wszystkie dane, w momencie wyj´scia wysylamy wszystkie. O wiele wydajniej by bylo gdyby wysyla´c tylko to co sie, zmienilo.Oczywi´scie przy zalo˙zeniu z˙ e migracja danych powinna zachodzi´c stosunkowo rzadko, w stosunku do wszystkich oblicze´ n bed cialem algorytmu nie , acych , jest to wielki problem. Rozwiazanie takie jest mo˙zliwe , do realizacji poniewa˙z ju˙z w obecnej wersji systemu ka˙zdy obiekt musi by´c jednoznacznie identyfikowany w kontek´scie klienta, gl´ ownie dla cel´ ow synchronizacyjnych oraz dlatego aby istaniala mo˙zliwo´s´c stwierdzenia, kt´ory obiekt jest starszy a kt´ ory nowszy. W zwiazku z tym , istnieje mo˙zliwo´s´c wykrycia jakie dane sie, zmienily podczas wykonywania algorytmu i przeslania tylko ich. Kolejnym krokiem jaki musi zosta´c podjety aby , jednoznacznie stwierdzi´c czy rozwiazanie to spe lnia , wszystkie postawione przed nim zalo˙zenia, kt´ ore byly postulowane, sa, testy i praktyczne wykorzystanie tego mechanizmu. Na dzie´ n dzi´siejszy przewidywane testy maja, tylko sprawdzi´c poprawno´s´c implementacji oraz pewnych zalo˙ze´ n techniczych. W nastepnej kolejno´sci , przewidziane jest badanie wydajnosci i dokonywanie optymalizacji. Literatura [1] A. S. Tanenbaum and M. van Steen, Distributed Systems: Principles and Paradigms (2nd Edition). Upper Saddle River, NJ, USA: Prentice-Hall, Inc., 2006. [2] T. Lindholm and F. Yellin, Java Virtual Machine Specification. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1999. [3] W. Zhu, C.-L. Wang, and F. C. M. Lau, “Jessica2: A distributed java virtual machine with transparent thread migration support,” in IEEE Fourth International Conference on Cluster Computing, Chicago, USA, September 2002. [Online]. Available: citeseer.ist.psu.edu/zhu02jessica.html [4] T. Sakamoto, T. Sekiguchi, and A. Yonezawa, “Bytecode transformation for portable thread migration in java,” in ASA/MA, 2000, pp. 16–28. [Online]. Available: citeseer.ist.psu.edu/sakamoto00bytecode.html
[5] S. Bouchenak, “Pickling threads state in the java system,” 1999. [Online]. Available: citeseer.ist.psu.edu/bouchenak00pickling.html [6] E. Truyen, B. Robben, B. Vanhaute, T. Coninx, W. Joosen, and P. Verbaeten, “Portable support for transparent thread migration in java,” in ASA/MA, 2000, pp. 29–43. [Online]. Available: citeseer.ist.psu.edu/truyen00portable.html
