Podręcznik użytkownika

Pula połączeń

Serwery DB2 Connect Enterprise Edition bardzo często dostarczają połączeń z bazami danych dla tysięcy równoczesnych żądań pochodzących od klientów. Ustanawianie i obsługa połączeń z serwerem bazy danych może być procesem obciążającym zasoby w bardzo istotny sposób, co wpływa zarówno na wydajność serwera bazy danych jak i na wydajność serwera DB2 Connect. Jest to szczególnie widoczne w środowisku sieci WWW, w którym każda wizyta na stronie sieci WWW może wymagać tworzenia nowego połączenia z serwerem bazy danych, wykonania zapytania, a następnie zakończenia połączenia. Aby zmniejszyć ten nakład pracy, DB2 Connect Enterprise Edition wykorzystuje pulę połączeń w celu obsługi otwartych połączeń z bazą danych w łatwo dostępnej puli.

Jak działa pula połączeń

Pula połączeń jest przezroczysta dla aplikacji łączących się z hostem za pośrednictwem DB2 Connect. Gdy aplikacja żąda odłączenia od serwera, DB2 Connect usuwa połączenie przychodzące dla aplikacji, ale utrzymuje w puli połączenie wychodzące dla hosta. Gdy nowa aplikacja żąda ustanowienia połączenia, DB2 Connect używa jednego z połączeń z puli. Użycie istniejącego połączenia skraca ogólny czas nawiązywania połączeń i zmniejsza wysoki koszt połączenia dla procesora w hoście.

Aby korzystać z puli połączeń, należy do DB2 for OS/390 wersja 6.1 zastosować następujący APAR:

     APAR PQ33473

Agenci DB2 Connect mogą być w jednym z dwóch stanów: w stanie bezczynności lub w stanie aktywnym. Agent jest w stanie aktywnym, gdy wykonuje pracę dla aplikacji. Po zakończeniu tej pracy agent przechodzi w stan bezczynności i oczekuje na dalszą pracę, zleconą przez tę samą lub inną aplikację. Wszyscy bezczynni agenci zebrani są w tak zwanej puli bezczynnych agentów. Można konfigurować wielkość tej puli za pomocą parametru konfiguracyjnego NUM_POOLAGENTS. Parametr ten jest równy maksymalnej liczbie bezczynnych agentów, jaką system ma obsługiwać. Ustawienie tego parametru na wartość równą zeru oznacza wyłączenie funkcji puli połączeń.

Produkt DB2 Connect nie ustanawia połączeń z bazą danych przed otrzymaniem pierwszego żądania od klienta. Można jednak wypełnić pulę bezczynnych agentów jeszcze przed otrzymaniem żądań od klientów. Pula może być wypełniona za pomocą parametru konfiguracyjnego NUM_INITAGENTS podczas uruchamiania. Parametr ten określa ilu bezczynnych agentów powinno zostać utworzonych podczas uruchamiania. Utworzeni w ten sposób bezczynni agenci nie będą mieć na początku żadnych połączeń z serwerem bazy danych hosta.

Gdy klient zażąda połączenia z hostem, DB2 Connect podejmie próbę uzyskania agenta spośród tych agentów znajdujących się w puli, którzy mają połączenie z serwerem bazy danych hosta. Jeśli próba ta się nie powiedzie, klient spróbuje znaleźć dostępnego agenta w puli bezczynnych agentów. Jeśli pula jest pusta, DB2 Connect utworzy nowego agenta.

Można kontrolować maksymalną liczbę agentów, którzy mogą być równocześnie aktywni, używając do tego celu parametru konfiguracyjnego MAX_COORDAGENTS. Gdy liczba ta zostanie osiągnięta, nowe połączenie wygeneruje błąd o kodzie równym SQL1226. (Kod ten oznacza, że przekroczona została maksymalna liczba równoczesnych połączeń wychodzących.)

Zmienna DB2CONNECT_IN_APP_PROCESS rejestru db2 umożliwia aplikacjom uruchomionym na tym samym komputerze co DB2 Connect EE, albo na uruchomienie DB2 Connect wewnątrz procesu aplikacji, albo na połączenie aplikacji z serwerem DB2 Connect EE Server, a następnie uruchomienie połączenia z hostem wewnątrz agenta. Aby aplikacja mogła korzystać z puli połączeń, połączenia z hostem muszą być ustanowione z agentów serwera DB2 Connect EE Server i dlatego też parametr konfiguracyjny DB2CONNECT_IN_APP_PROCESS musi być ustawiony na NO.

Koncentrator połączeń DB2 Connect

Technologia koncentratora połączeń produktu DB2 Connect umożliwia serwerom DB2 Connect Enterprise Edition zapewnianie obsługi tysiącom użytkowników, którzy jednocześnie wykonują transakcje biznesowe, zmniejszając w ogromnym stopniu wymagania serwerów baz danych hosta lub systemu AS/400 dotyczące zasobów. Technologia ta osiąga swój cel, koncentrując obciążenia pochodzące z różnych aplikacji w dużo mniejszą liczbę połączeń z serwerem bazy danych hosta lub systemu AS/400. Chociaż mechanizm ten wygląda podobnie do opisanej powyżej funkcji puli połączeń, jest to jednak w rzeczywistości o wiele bardziej wysublimowane podejście do zmniejszania obciążenia zasobów przez aplikacje o wysokim poziomie przetwarzania transakcyjnego w trybie online (OLTP - Online Transaction Processing).

Pula połączeń zmniejsza koszty ustanawiania połączenia, gdy połączenie takie nie jest już potrzebne aplikacji, która zostaje zakończona. Mówiąc innymi słowy, jedna aplikacja musi się odłączyć, aby inna mogła użyć połączenia znajdującego się w puli połączeń.

Z drugiej strony, koncentrator połączeń pozwala produktowi DB2 Connect na utworzenie połączenia dostępnego dla aplikacji w momencie, gdy inna aplikacja zakończy transakcję; nie wymaga to, aby połączenie dla tej aplikacji kończącej transakcję zostało przerwane. W zasadzie połączenie serwera bazy danych oraz stowarzyszone z nim zasoby hosta lub systemu AS/400 są używane przez aplikację tylko wtedy, gdy ma ona aktywną transakcję. Natychmiast po zakończeniu transakcji połączenie oraz stowarzyszone z nim zasoby mogą być wykorzystane przez inne aplikacje, które muszą wykonać transakcję.

W jaki sposób zaimplementowany jest koncentrator połączeń

W poprzednich wersjach produktu DB2 Connect każda aktywna aplikacja miała jednostkę Engine Dispatchable Unit (EDU), która zarządzała połączeniem bazy danych jak również wszystkimi żądaniami aplikacji. Taka jednostka EDU nazywana była zwykle agentem koordynacji. Każdy agent koordynacji śledził stan lub kontekst aplikacji i EDU. Jeśli liczba połączeń wzrastała, każda jednostka EDU zajmowała coraz większą ilość pamięci, a ponadto przełączanie kontekstu między agentami powodowało dodatkowy nakład pracy.

W przedstawionej powyżej architekturze, między połączeniami i jednostkami EDU istnieje relacja jeden do jednego. Jednak koncentrator połączeń pozwala na powstawanie między połączeniami i jednostkami EDU relacji jeden do wielu. Oznacza to, że relację między połączeniami (X) i jednostkami EDU (Y) można przedstawić teraz jako X >= Y.

Koncentrator połączeń dzieli agenta na dwie jednostki: agenta logicznego i agenta pracującego. Agenci logiczni reprezentują aplikację, lecz nie mają odniesienia do konkretnej jednostki EDU. Agent logiczny zawiera wszystkie informacje i bloki kontrolne wymagane przez aplikację. Jeśli jest n aplikacji połączonych z serwerem, to muszą być n na serwerze agenci logiczni. Agent pracujący jest to fizyczna jednostka EDU, która wykonuje żądania aplikacji, lecz która nie ma trwałego połączenia z daną aplikacją. Agenci pracujący wiążą się z agentami logicznymi w celu wykonywania transakcji i po zakończeniu transakcji kończą powiązanie i wracają do puli dostępnej.

Jednostka znana jako program planujący dla agentów logicznych przydziela agentów pracujących agentom logicznym. Ograniczenie liczby otwartych uchwytów plików, obecne na niektórych platformach komputerowych, może powodować tworzenie wielu instancji programu planującego, jeśli liczba agentów logicznych przekroczy limit dla uchwytów plików.

Uaktywnianie koncentratora

Aby korzystać z koncentratora połączeń, należy do DB2 for OS/390 wersja 6.1 zastosować następujący APAR:

     APAR PQ33473

Parametr konfiguracyjny MAX_LOGICAGENTS menedżera baz danych określa maksymalną liczbę agentów logicznych. Można uaktywnić funkcję koncentratora, ustawiając wartość MAX_LOGICAGENTS na dowolną wartość, większą od wartości domyślnej. Wartość domyślna parametru MAX_LOGICAGENTS jest równoważna wartości MAX_COORDAGENTS. Ponieważ każda aplikacja musi mieć jednego agenta logicznego, parametr MAX_LOGICAGENTS kontroluje w rzeczywistości liczbę aplikacji, które mogą być połączone z instancją bazy danych, podczas gdy parametr MAX_COORDAGENTS kontroluje liczbę połączeń wchodzących, które mogą być uaktywnione w dowolnej chwili. Parametr MAX_LOGICAGENTS może być wartością liczbową z zakresu od MAX_COORDAGENTS aż do 64,000. Domyślna liczba agentów logicznych jest równa MAX_COORDAGENTS.

Do konfigurowania agentów używa się kilku istniejących parametrów konfiguracyjnych. Są to następujące parametry:

MAXAGENTS
Maksymalna liczba agentów pracujących.

MAX_COORDAGENTS
Maksymalna liczba aktywnych agentów koordynatora.

NUM_POOLAGENTS
Wielkość puli agentów. Pula agentów składa się z agentów nieaktywnych i z agentów bezczynnych.

NUM_INITAGENTS
Początkowa liczba agentów pracujących, znajdujących się w puli. Mogą to być agenci bezczynni.

Obsługa transakcji XA

Architektura koncentratora połączeń umożliwia produktowi DB2 Connect zapewnianie obsługi mocno związanych transakcji XA w DB2 for OS/390 i DB2 for AS/400. Koncentrator połączy agenta pracującego z konkretną transakcją XA (pojedynczym XID) tak, jak dla każdej innej transakcji. Jeśli jednak transakcja XA kończy się przez xa_end() (granica gałęzi), agent pracujący nie zostanie zwrócony do puli ogólnej. Zamiast tego, agent pracujący pozostanie stowarzyszony z tą konkretną transakcją XA. Gdy inna aplikacja przyłączy się do tej samej transakcji XA, agent pracujący zostanie podłączony do tej aplikacji.

Każde wywołanie granicy transakcji zwróci agenta do puli. Na przykład wywołania xa_prepare() w trybie tylko do odczytu, xa_rollback(), xa_recover(), xa_forget(), xa_commit() lub dowolny błąd XA, który spowoduje wycofanie zmian, zwrócą agenta do zwykłej puli. Samo Xa_end() kończy tylko gałąź transakcji i nie wystarczy, aby zakończyć powiązanie transakcji z XID.

Przykłady

  1. Wyobraźmy sobie środowisko, w którym potrzebnych jest 4000 połączeń lub więcej. Takie potrzeby może mieć serwer sieci WWW, który korzysta z aplikacji CGI lub system biurowy, do którego podłączonych jest wielu użytkowników. W takich przypadkach, względy wydajności wymagają zwykle, aby produkt DB2 Connect pracował jako autonomiczna brama; co oznacza, że baza danych i system DB2 Connect muszą znajdować się na oddzielnych komputerach.

    System serwera DB2 Connect może nie być w stanie obsłużyć równocześnie 4000 otwartych połączeń z komputerem bazy danych. W większości przypadków liczba transakcji przeprowadzanych w danym momencie będzie znacznie mniejsza niż liczba współbieżnych połączeń. Administrator systemu może wtedy zwiększyć wydajność systemu, ustawiając w sposób następujący parametry konfiguracyjne bazy danych:

         MAX_LOGICAGENTS =  4000
         MAX_AGENTS      =  1000
         MAX_COORDAGENTS =  1000
         NUM_POOLAGENTS  =  1000
    

    Koncentrator może utrzymać do 4000 otwartych, jednocześnie działających sesji, nawet jeśli brama może równocześnie obsługiwać tylko 1000 transakcji.

  2. W powyższym przykładzie agenci pracujący będą nieustannie tworzyć i usuwać powiązania z agentami logicznymi. Ci agenci, którzy nie są bezczynni, mogą obsługiwać połączenia z bazą danych, lecz nie biorą udziału w żadnej konkretnej transakcji, dlatego też są dostępni dla dowolnego agenta logicznego (aplikacji), który żąda połączenia.

    Przypadek dotyczący transakcji XA jest trochę inny. W tym przykładzie przyjmiemy, że z bramą DB2 Connect i bazą danych OS/390 lub AS/400 używany jest monitor TP. Gdy aplikacja żąda połączenia, koncentrator może odwrócić stan nieaktywnego agenta, aby ten obsłużył żądanie lub utworzyć nowego agenta pracującego. Załóżmy, że aplikacja żąda transakcji XA. Dla tej transakcji tworzony jest XID i zostaje z nim powiązany agent pracujący.

    Gdy żądanie aplikacji zostanie obsłużone, wywołuje ona funkcję xa_end() i odłącza się od agenta pracującego. Agent pracujący pozostaje powiązany z XID transakcji. Może on teraz obsługiwać tylko żądania transakcji z powiązanym z nim identyfikatorem XID.

    W tym momencie inna aplikacja może zgłosić żądanie transakcji innej niż XA. Nawet jeśli nie będzie żadnych innych wolnych agentów pracujących, agent powiązany z identyfikatorem XID nie będzie dostępny dla drugiej aplikacji. Uważany jest on za agenta aktywnego. Dla drugiej aplikacji musi zostać utworzony nowy agent pracujący. Gdy druga aplikacja zakończy swoją transakcję, związany z nią agent pracujący zostanie zwrócony do puli dostępnych agentów.

    W międzyczasie inne aplikacje żądające transakcji powiązanych z identyfikatorem XID pierwszego agenta mogą podłączać się do tego agenta oraz odłączać się od niego, co spowoduje wykonanie dla nich dedykowanej transakcji XA. Każda aplikacja żądająca tej konkretnej transakcji zostanie wysłana do tego agenta pracującego, jeśli będzie on wolny.

    Agent pracujący nie zostanie zwolniony do puli ogólnej dopóty, dopóki aplikacja nie zgłosi wywołania granicy transakcji (nie xa_end()). Na przykład aplikacja może zakończyć transakcję wywołaniem xa_commit() i w tym miejscu agent pracujący usunie powiązanie z identyfikatorem XID i wróci do puli dostępnych agentów. Każda aplikacja zgłaszająca żądanie może wtedy użyć go zarówno do innej transakcji XA, jak też do transakcji innego typu niż XA.

Ograniczenia

Z wykorzystaniem koncentratora bramy związanych jest kilka ważnych ograniczeń. Przed podjęciem próby skorzystania z koncentratora we własnym systemie, należy przejrzeć w całości następujące informacje.

Strojenie bazy danych

Wydajność systemu zależy od wydajności bazy danych serwera baz danych hosta lub AS/400.

Różne systemy zarządzania bazami danych mają różne opcje wydajności. Optymalizatory języka SQL w różnych systemach mogą zachowywać się w różny sposób w przypadku tej samej aplikacji. Więcej informacji można znaleźć w dokumentacji dotyczącej wydajności serwera baz danych hosta lub AS/400.

W przypadku DB2 Universal Database for AS/400 można poprawić wydajność, używając niezatwierdzonego odczytu (UR) lub opcji powiązania niezatwierdzonego (NC), aby uniknąć zapisywania w dzienniku.

Uwaga:W przypadku użycia niezatwierdzonego odczytu (UR) niezapisane do dziennika dane można tylko odczytywać, nie można ich aktualizować i można to robić tylko w przypadku, gdy łączenie danych w bloki jest ustawione na ALL.

W zależności od serwera aplikacji i dostarczonej przez niego granulacji blokowania, poziom wyodrębnienia używany dla zapytania lub aplikacji może mieć znaczący wpływ na wydajność.

Baza danych powinna mieć odpowiedni poziom normalizacji, skuteczne wykorzystanie indeksów i odpowiednio przydzielaną przestrzeń bazy danych. Na wydajność mogą mieć również wpływ typy danych, co zostało opisane poniżej.

Strojenie DB2 for OS/390

Dla obsługi protokołu TCP/IP minimalnym wymaganiem jest OS/390 V1R3. Bardzo zalecane jest używanie OS/390 V2R5 lub wersji późniejszej.

Narzędzie Distributed Data Facility (DDF) jest odpowiedzialne za połączenie aplikacji rozproszonych z DB2 for OS/390. Narzędzie DDF powinno zostać skonfigurowane jako serwer aplikacji. Aby to zrobić, należy wstawić nazwę jednostki logicznej (LU) systemu zdalnego do tabeli SYSIBM.LUNAMES albo wstawić wartości LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT i USERNAMES do tabeli SYSIBM.SYSLUNAME. Następnie należy wykonać aktualizację DDF dla Boot Strap Data Set (BSDS). Na przykład:

   DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001

Aby osiągnąć jak największą wydajność, należy użyć zalecanego priorytetu przestrzeni adresowej DDF (nieco niższe lub równe DBM1, jeśli używany jest tryb COMPAT). Należy użyć pamięci podręcznej RACF dla autoryzacji w VLF i pamięci podręcznej autoryzacji do pakietów V5, jeśli jest to możliwe. W większości operacji wystarczająca jest wartość CACHEPAC=32768.

Ponieważ narzędzie DDF będzie próbowało połączyć się z VTAM, należy go wcześniej uruchomić. Poniżej przedstawiono przykładową definicję VTAM APPL:

SYD51TC* APPL  AUTH=(ACQ),                                      X
               PARSESS=YES,                                     X
               HAVAIL=YES,                                      X
               EAS=1600,                                        X
               APPC=YES,                                        X
               DSESLIM=1024,                                    X
               DMINWNL=512,                                     X
               DMINWNR=512,                                     X
               AUTOSES=1,                                       X
               SECACPT=ALREADYV,                                X
               SRBEXIT=YES,                                     X
               SYNCLVL=SYNCPT,                                  X
               MODETAB=DB2MODET,                                X
               VPACING=63                                       X

W OS/390 można zoptymalizować przetwarzanie nieaktywnych wątków. W wersji 3 dopuszczalnych jest 10 000 jednocześnie połączonych klientów, a w wersji 4 i 5 do 25 000. We wszystkich przypadkach maksymalna liczba jednocześnie aktywnych klientów wynosi 1999. Każdy klient stacji roboczej może być przyłączony również wtedy, gdy jest nieaktywny; wątek takiego klienta jest umieszczany w łańcuchu nieaktywnym przy każdym zatwierdzaniu.

Parametry DSNZPARM: CMTSTAT, CONDBAT i MAXDBAT wpływają na przetwarzanie wątków. Aby wydajność była największa, należy ustawić parametr CMTSTAT na INACTIVE, dopasować CONDBAT do maksymalnej liczby połączonych DBAT zapewniającej wysoką wydajność i ustawić parametr MAXDBAT na największą akceptowalną liczbę aktywnych DBAT.

Pełne omówienie połączenia DB2 for OS/390 w sieci DRDA, łącznie z konfigurowaniem VTAM można znaleźć w podręczniku Połączenia z DB2 - suplement.

Konwersja danych

Dane po przesłaniu z jednego środowiska do drugiego mogą zostać poddane konwersji. Konwersja ta może mieć wpływ na wydajność.

Rozważmy następujące platformy:

i następujące typy danych numerycznych:

Tabela 8 przedstawia sytuację, kiedy jest wykonywana konwersja.

Tabela 8. Konwersja danych

 


Intel


IEEE


S/370 & S/390


OS/400


Dane upakowane dziesiętne


Intel
IEEE
S/370/390
OS/400


Nie
Nie
Nie
Nie


Nie
Nie
Nie
Nie


Nie
Nie
Nie
Nie


Nie
Nie
Nie
Nie


Dane nieupakowane dziesiętne


Intel
IEEE
S/370/390
OS/400


Nie
Nie
Tak
Tak


Nie
Nie
Tak
Tak


Tak
Tak
Nie
Nie


Tak
Tak
Nie
Nie


Dane całkowite


Intel
IEEE
S/370/390
OS/400


Nie
Tak
Tak
Tak


Tak
Nie
Nie
Nie


Tak
Nie
Nie
Nie


Tak
Nie
Nie
Nie


Dane zmiennopozycyjne


Intel
IEEE
S/370/390
OS/400


Nie
Tak
Tak
Tak


Tak
Nie
Tak
Nie


Tak
Tak
Nie
Tak


Tak
Nie
Tak
Nie

Koszt jednostki centralnej związany z konwersją znaków jednobajtowych jest generalnie mniejszy niż koszt konwersji danych numerycznych (gdzie konwersja danych jest wymagana).

Koszt konwersji danych DATE/TIME/TIMESTAMP jest prawie taki sam, jak koszt konwersji danych jednobajtowych CHAR. Najdroższa jest konwersja danych zmiennopozycyjnych FLOATING. Projektując aplikacje bazujące na DB2 Connect, można wykorzystać powyższe informacje.

Jeśli tabela bazy danych ma kolumnę zdefiniowaną 'FOR BIT DATA', nie jest wymagane wykonywanie konwersji danych znakowych przekazywanych między aplikacją i bazą danych. Jest to wykorzystywane podczas archiwizacji danych na serwerze baz danych hosta lub AS/400.

Typy danych znakowych

Dane znakowe mogą być typu CHAR lub VARCHAR. Wydajność obsługi danych zależy od typowej długości danych w polu:

Strojenie sieci

Najlepszym sposobem zwiększenia ogólnej wydajności w środowisku rozproszonej bazy danych jest usunięcie opóźnień powstających w sieci. Administratorzy sieci często zauważają, że praca w sieci jest wydajniejsza, jeśli między transmisjami zostaje zgromadzonych tak dużo danych, jak to tylko możliwe. Tego podejścia nie da się zastosować dla aplikacji, takich jak rozproszone bazy danych, ponieważ to one generują opóźnienia w sieci. Użytkownik końcowy nie dostrzega wydajności sieci, jedynie opóźnienia.

Większość urządzeń sieciowych ma parametry opóźnienia i ustawione wartości domyślne, które są nieodpowiednie dla rozproszonych baz danych. Aby zwiększyć wydajność, należy odnaleźć te parametry i, o ile to możliwe, ustawić je na wartość zero. Ponadto należy sprawdzić, czy wielkość buforu urządzenia jest wystarczająca, aby zapobiec retransmisjom spowodowanym przez utratę danych. Na przykład w systemach UNIX głębokość kolejki wejściowej lub wyjściowej domyślnie wynosi 32. Aby zwiększyć wydajność, należy ustawić głębokość kolejki na 150. W ustawieniach sterowania łączem danych odpowiednim parametrem jest Receive Depth, który również powinien wynosić 150.

W większości miejsc parametr IOBUF ma za małą wartość. Jest on zazwyczaj ustawiony na 500, ale doświadczenie pokazuje, że wartość 3992 jest odpowiedniejsza, jeśli przenoszone są duże ilości danych, szczególnie dla połączeń kanałem, takich jak ESCON lub 3172.

Dla połączeń SNA należy ustawić profil trybu (Mode Profile) całego oprogramowania stacji roboczej na wartość 63. Ogólnie wartości pacingu odbierania w sieci powinny być ustawione na największe dopuszczalne wartości. W ten sposób powinny być ustawione parametry VPACING i PACING w instrukcji DB2 APPL i PU/LU dla stacji roboczej w głównym trybie komutowanym powinien być ustawiony na 63. Ma to na celu umożliwienie stopniowego wzrostu przepływu ilości komunikatów, zanim nadawca będzie zmuszony do oczekiwania na odpowiedź.

W systemie LAN wielkości okien transmisji i odbierania sterowania łączem danych lub sterowania łączem logicznym mogą mieć ogromny wpływ na wydajność. Wartość wysyłania powinna być ustawiona na wartość 7 lub większą. Dla większości konfiguracji najlepsza wartość odbioru wynosi 4 lub mniej.

Jeśli wykorzystywany jest Ethernet, należy ustawić wielkość segmentu TCP na 1500 bajtów. W sieci Token Ring lub FDDI wartość ta powinna być ustawiona na 4400 bajtów, a jeśli używany jest adapter ESCON z TCP/IP, wielkość segmentu powinna zawsze wynosić 4096.

Dla sieci TCP/IP wielkości buforów TCP Send i Receive powinny być ustawione na wartość większą niż 32768. Ogólnie najlepszą wartością jest 65536.
Uwaga:Ustanowienie połączenia od bramy do serwera (połączenie wychodzące) jest znacznie kosztowniejsze niż ustanowienie połączenia od klienta do bramy (połączenie przychodzące). W środowisku, w którym tysiące klientów często łączy (i rozłącza) się z serwerem przez bramę, ustanawianie połączeń wychodzących stanowi znaczną część czasu przetwarzania. DB2 Connect umożliwia kolejkowanie połączeń przez TCP/IP. Gdy klient żąda odłączenia od serwera, brama usuwa połączenie przychodzące z klientem, ale utrzymuje w puli połączenie wychodzące z serwerem. Gdy nowy klient pojawia się w bramie żądając połączenia, brama udostępnia istniejące połączenie z puli, ograniczając w ten sposób całkowity czas połączenia i oszczędzając wysoki koszt połączenia CPU na serwerze.

Więcej informacji na temat puli połączeń w DB2 można znaleźć w podręczniku Administration Guide.

W następującej tabeli przedstawiono podsumowanie metod strojenia wydajności sieci.
Czego należy szukać Przykład Ustawienia Uwagi
Umyślne opóźnienia Parametry opóźnienia dla urządzeń sieciowych Ustawić na 0. Ustawienia domyślne mają zwykle większe wartości.
Bufory Parametr IOBUF Ustawić na 3992. Ustawienie szczególnie przydatne dla ESCON lub innego adaptera kanału.
RUSIZE Optymalna wielkość to 4096. Największą wydajność można osiągnąć, ustawiając parametry RUSIZE i RQRIOBLK na tę samą wielkość.
Pacing VPACING, PACING i Mode Profiles należy ustawić na 63. Jeśli można, należy zastosować pacing dostosowujący.
Ustawienia adaptera Głębokość kolejki wyjściowej/wejściowej Zalecana wartość to 150. Wartość domyślna zazwyczaj wynosi 32.
DLC Windowing w SNA Należy ustawić dużą wielkość okna przesyłania (>7). Należy ustawić małą wielkość okna odbioru (na przykład na 1), przetestować i zwiększać ją, aż do znalezienia idealnej wartości. Każde urządzenie logiczne powoduje opóźnienia. Należy uprościć topologię sieci tak bardzo, jak to możliwe.
Ustawienia TCP Wielkości segmentów 1500 w sieci Ethernet, 4400 w sieciach Token Ring i FDDI. Adaptery ESCON używane dla TCP/IP powinny być zawsze ustawione na wartość 4096.
Wielkości przestrzeni wyjściowej/wejściowej 64 kB dla obydwu parametrów. Wartość domyślna dla Windows wynosi tylko 8192. Można ją ustawić w rejestrze Windows.

Sprzęt sieciowy

Następujące informacje dotyczą sprzętu:

Rywalizacja o zasoby systemowe

Wydajność zmniejsza się także, jeśli wiele zadań rywalizuje o zasoby systemu. Należy rozważyć następujące kwestie:

Rozwiązywanie problemów dotyczących wydajności

Jeśli użytkownicy DB2 Connect długo czekają na wykonanie dużych zapytań z hostów lub serwerów AS/400, powinni prześledzić poniższe obszary, aby znaleźć przyczynę występowania problemu związanego z wydajnością:

  1. W przypadku zapytań, które zwracają duże bloki danych z hosta lub serwera AS/400 (zazwyczaj po 32 kB lub więcej), należy sprawdzić, czy parametr konfiguracyjny menedżera baz danych RQRIOBLK został ustawiony na 32767. Można to zrobić, używając Procesora wiersza komend (CLP) w następujący sposób:
       db2 update database manager configuration using RQRIOBLK 32767
    
  2. Jeśli VTAM jest używany w połączeniu z hostem lub serwerem AS/400, należy sprawdzić konfigurację "switched major node (głównego węzła komutowanego)" dla wartości parametru PACING. Na stacji roboczej DB2 Connect należy prześledzić ustawienie komunikacji "LU 6.2 Mode Profile" dla definicji trybu IBMRDB. W tej definicji należy sprawdzić, czy wartość parametru "Receive pacing window" jest mniejsza lub równa wartości PACING zdefiniowanej w VTAM. Częstą wartością dla "Receive pacing window" na stacji roboczej DB2 Connect i "PACING" na VTAM jest 8.
  3. Należy sprawdzić, czy maksymalna wielkość RU w definicji trybu IBMRDB została ustawiona na odpowiednią wartość. Dla połączeń używających sprzętu Token Ring zalecana jest wartość nie mniejsza niż 4 K. Dla połączeń używających sprzętu Ethernet czynnikiem ograniczającym może być maksymalna wielkość ramki równa 1536 bajtom.
  4. Należy zapytać administratora VTAM dla danego środowiska, aby sprawdzić, czy VTAM używa "adaptive pacing (pacingu dostosowującego)" w sesjach LU-LU ze stacją roboczą DB2 Connect.


[ Początek strony | Poprzednia strona | Następna strona | Spis treści | Indeks ]