Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 2

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  workload management
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
EN
An accurate use of the ability to steer computer efficiency is essential from the database point of view. Effective resource allocation is dependent on the performance indicators gathered from running systems. There must be an appropriate balance between accurate measurements, performance indicators and speed of the reallocation algorithms of the computing resources. The extended measurement of efficiency which the authors propose for applications is: the average number of queries within a time unit for particular groups of users. This paper presents an analysis of using the Workload Manager utility in the AIX 5L operating system to improve the efficiency of applications in the MySQL database environment, and an analysis of methods which allows the use of Workload Manager for steering efficiency dynamically.
PL
Właściwe wykorzystanie zdolności do sterowania wydajnością systemu komputerowego jest niezbędna z punktu widzenia odbiorcy usług informatycznych. Efektywna alokacja zasobów obliczeniowych jest uzależniona od zebranych metryk wydajności. Należy, więc zachować właściwą równowagę pomiędzy dokładnością pomiarów, oraz szybkością algorytmów służących do realokacji zasobów obliczeniowych rozważanego systemu komputerowego. Proponowany przez autorów rozszerzony pomiar efektywności dla aplikacji to średnia liczba zapytań w jednostce czasu dla poszczególnych grup użytkowników. Taka metryka jest celem do zrealizowania w badanym systemie komputerowym. W artykule przedstawiono analizę wykorzystania zarządcy obciążeniem w systemie operacyjnym AIX 5L do poprawy wydajności aplikacji w środowisku bazy danych MySQL. Zaprezentowano również analizę metod, które pozwalają na korzystanie z zarządcy obciążeniem do dynamicznego sterowania wydajnością. Autorzy analizują zachowanie się systemów nieregularnych. Takie systemy charakteryzują się dość wysokim niedeterminizmem, objawia się to tym, że wielokrotne wykonanie pomiaru obciążenia przy jednakowych warunkach, może dać różne rezultaty. Takie zachowanie systemu jest powodowane magazynowaniem danych w podręcznych strukturach pamięci oraz działaniem systemowych algorytmów przydzielania i zwalniania zasobów informatycznych. Autorzy wykorzystują do badań samodzielnie przygotowane programy i procedury testujące. Program BaseAttack napisany został w języku Java, co sprawia, że testowane środowisko jest zbliżone do stosowanych obecnie w przedsiębiorstwach nowoczesnych systemów komputerowych. Testowane środowisko zostało podzielone na podklasy. Procesy systemowe o większym znaczeniu dla użytkownika są w innych klasach niż procesy mniej znaczące. Wyniki eksperymentów pokazują, że możliwe było zwiększenie wydajności wybranych podklas niemal dwukrotnie bez ingerencji w ustawienia wewnętrznych parametrów bazy danych.
EN
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.
PL
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.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.