Wyniki wyszukiwania - BazTech

Ograniczanie wyników

Znaleziono wyników: 1

Liczba wyników na stronie

Wyniki wyszukiwania

Wyszukiwano:
w słowach kluczowych: dynamic resources allocation

Sortuj według:

Ogranicz wyniki do:

Automatic adjustment of the settings of workload manager for adaptive performance management

Młyński M.

Theoretical and Applied Informatics

2009

Vol. 21, No. 1

37-56

These days, in real live complex computer environments, some applications must be executed more quickly than others. The problem how to execute more important applications quicker and how to change an application efficiency dynamically according to user requirements is difficult. In this article a proposition how to resolve the problem has been presented; a prototype of application for automatic workload manager adjustment and result of experiments has been presented as well.

W artykule przedstawiony został problem zarządzania wydajnością w złożonych systemach komputerowych. Wykorzystany w doświadczeniach system operacyjny nie dostarcza narzędzia, które zarządzałoby wydajnością zdefiniowaną przez użytkownika końcowego, jako czas odpowiedzi aplikacji, bądź też jako ilość danych przetworzonych w z góry określonym czasie. Podsystem Workload Manager w wykorzystanym systemie operacyjnym AIX jest zorientowany na zasoby. Oznacza to, że możemy jedynie wskazać, ile zasobów obliczeniowych przez wskazaną aplikację będzie mogło zostać wykorzystane. Przykładowo może to być: 50% mocy obliczeniowej procesorów, 20% kanałów wejścia/wyjścia lub też 65% zajętości całej pamięci operacyjnej w serwerze. W podsystemie Workload Manager, brakuje natomiast orientacji na cel, czyli możliwości wskazania, jaka ma być docelowa wydajność aplikacji. Celem badań, było zbudowanie prototypu i znalezienia metod dla zarządzania zasobami na poziomie docelowej wydajności, tak, aby można było wprowadzić do systemu informacje o oczekiwanej wydajności aplikacji, a system sam, w celu osiągnięcia zamierzonego celu, dobrałby im odpowiednie wartości oraz dynamicznie je zmieniał w czasie pracy. Doświadczenia pokazują, że nie jest to problem trywialny, gdyż w wielu przypadkach trzeba się opierać na informacji niepełnej oraz polegać na nieprecyzyjnych i niestabilnych wynikach testów. W zaproponowanym kryterium oceny efektywności, oprócz czasu odpowiedzi aplikacji jest także wykorzystanie serwera w jak największym stopniu. Praca może zatem, przynieść wymierne korzyści po wdrożeniu jej idei w środowisku produkcyjnym. Przedstawiony w rozdziale czwartym prototyp rozwiązania (Rys. 10) bazuje na wiedzy zdobytej w procesie uczenia. Proces ten musi być przeprowadzony w całości przed ostatecznym uruchomieniem aplikacji. Moduły prototypu to: punkty pomiaru wydajności, analizator, baza wiedzy oraz executor, który odpowiada za parametryzację klas podsystemu Workload Manager. Zaprezentowany prototyp rozwiązania oraz wyniki badań oparte zostały na: . popularnym w zastosowaniach komercyjnych systemie operacyjnym AIX (Advanced Interactive eXecutive) firmy IBM, . narzędziu Workload Manager – wbudowanym mechanizmie systemu operacyjnego, . bazie danych MySQL wykorzystywanej do przechowywania i obsługi bazy wiedzy, . oprogramowaniu XLC++ oraz systemowych narzędziach programistycznych. Badania przedstawione w artykule dotyczą typowego środowiska, często spotykanego w systemach komputerowych t.j. aplikacji „krytycznej”, której czas odpowiedzi jest bardzo ważny z punktu widzenia działalności firmy, nazywanej w doświadczeniach jako prod24, oraz dwu klas aplikacji „niekrytycznych” prod oraz app. Przykładem obu rodzajów aplikacji mogą być systemy bankowe, gdzie aktualne operacje na koncie są krytyczne, podczas gdy aplikacje analityczne do takich nie należą. Propozycja rozwiązania zaprezentowana w artykule i przetestowana na prototypie polega na tym, aby w jak najkrótszym czasie znaleźć i zmienić dynamicznie parametry systemu tak, aby wskazana aplikacja charakteryzowała się oczekiwanym czasem odpowiedzi. Znaczącym problemem, jaki występuje podczas dynamicznej realokacji zasobów obliczeniowych jest to, że oprócz zasobów przydzielonych bezpośrednio do aplikacji poprzez reguły klasyfikacyjne, w systemie operacyjnym istnieje jeszcze szereg obszarów, którymi zarządzanie jest utrudnione. Są to strony pamięci operacyjnej, które są na stałe powiązane z określonymi adresami i nie mogą być z nich przemieszczone (ang. Pinned memory). Takie strony pamięci są wykorzystywane przez serwery asynchroniczne (ang. Asynchronous I/O servers), oraz przez niektóre struktury wirtualnego zarządcy pamięcią, który odpowiada za buforowanie systemu plików. Do obszarów niedostępnych dla Workload Manager w systemie operacyjnym AIX należą również biblioteki współdzielone programów oraz część procesów systemowych takich jak, procesy zarządzające pamięcią. Zaprezentowane w artykule wyniki badań składają się z trzech części: . wyników przedstawiających sposób działania podsystemu Workload Manager w systemie operacyjnym AIX - rysunek 1 pokazuje ogólną koncepcję tego narzędzia, natomiast rysunki 3 i 4 pokazują wydajność systemu z działającymi współbieżnie trzema klasami zasobów, . wyników przedstawiających działanie podsystemu Workload Manager w warunkach dynamicznych zmian (Rys. 5, 6, 7, 8, 9), . wyników działania zaproponowanego prototypu (Tab. 1). Na rysunkach 5, 6, 7, 8 i 9 przedstawione zostały doświadczenia z parametryzacją Workload Managera typu ad-hoc, dlatego parametry wejściowe zostały tam wstępnie ustalone. Na rysunkach tych pokazane są różnice pomiędzy wstawioną wartością do Workload Managera a rzeczywistą ich wartością z pomiaru. Potwierdza to rysunek 7, gdyż o godz. 23:17 zajętość klasy powinna wynosić około 15% całego serwera, natomiast zmierzona wartość mówiła, że ta klasa aktualnie nie wykorzystuje żadnych zasobów obliczeniowych. Tabela 1 pokazuje wyniki doświadczeń z wykorzystaniem zbudowanego prototypu. Jak widać na zaprezentowanych w tabeli rezultatach, wynikowa wartość wydajności aplikacji jest często różna od wydajności oczekiwanej, ale mieszcząca się w przyjętych granicach błędu. Elementem, który został wskazany przez autora jako wciąż wymagający ulepszenia, jest proces budowania bazy wiedzy. W przyjętym rozwiązaniu baza wiedzy jest tworzona poprzez uruchomienie aplikacji z wszystkimi kombinacjami ustawień podsystemu Workload Manager. Dla rozpatrywanego środowiska, gdzie były zdefiniowane tylko trzy klasy zasobów, proces ten zajął około 5 dni. Podstawowym parametrem, jaki podlegał rozważaniu w każdej z klas, było maksymalna zajętość procesorów. W pracy przedstawiony został również przegląd opublikowanych badań prowadzonych w dziedzinie zarządzania zasobami.