A DB2 Connect Enterprise Edition kiszolgálók gyakran több ezer egyidejű ügyfélkérelemhez szolgáltatnak adatbázis-kapcsolatot. Az adatbáziskapcsolatok létrehozása és fenntartása nagyon erőforrás-igényes feladattá válhat, ami hátrányos hatással lehet mind az adatbázis-kiszolgáló, mind a DB2 Connect kiszolgáló teljesítményére. Ez különösen kézzelfogható webes környezetekben, ahol minden egyes web-oldalra irányuló látogatás megkövetelheti a kapcsolat felépítését az adatbázis-kiszolgálóval, a lekérdezés végrehajtását, majd a kapcsolat bontását. Ennek az időveszteségnek a csökkentéséhez a DB2 Connect Enterprise Edition előre létrehozott kapcsolatokat használ, azaz egy csomagban gyorsan elérhető már megnyitott kapcsolatokat tárol az adatbázishoz.
Az előre létrehozott kapcsolatok nem láthatók a gazdagéphez DB2 Connecten keresztül kapcsolódó alkalmazások számára. Amikor az ügyfelek az összeköttetés bontását kérik a kiszolgálótól, az átjáró eldobja az ügyféllel létesített bemenő összeköttetést, de a kimenő összeköttetéseket csapatban tartja. Amikor egy új alkalmazás kér egy kapcsolatot, a DB2 Connect a meglevő csapatból használ egyet. Már létező összeköttetések használata egyaránt csökkenti a teljes kapcsolódás idejét és a gazdagépen a kapcsolódások magas CPU terhelését.
Az előre létrehozott kapcsolatok használatához a következő APAR-t kell alkalmazni a DB2 for OS/390 Version 6.1-hez:
APAR PQ33473
A DB2 Connect ügynökök a következő két állapot egyikében lehetnek: tétlen vagy aktív. Egy ügynök akkor aktív, amikor egy alkalmazás számára munkát hajt végre. Amint ez a munka befejeződött, az ügynök tétlen állapotba kerül, és további munkára vár ugyanattól, vagy egy másik alkalmazástól. A tétlen ügynök együtt tárolódik az úgynevezett tétlen ügynökcsapatban. Ennek a csapatnak a méretét a NUM_POOLAGENTS konfigurációs paraméter segítségével lehet beállítani. Ez a paraméter egyenlő a rendszer által fenntartott tétlen ügynökök maximális számával. Ennek a paraméternek a nullára állítása azzal egyenértékű, mintha kikapcsolná az előre létrehozott kapcsolatok szolgáltatását.
Az első ügyfélkérelem fogadása előtt a DB2 Connect nem létesít adatbázis-kapcsolatokat. Azonban ha kívánja, feltöltheti a tétlen ügynökök csapatát, mielőtt egyetlen ügyfélkérelem is érkezne. A csapat a NUM_INITAGENTS konfigurációs paraméter segítségével rendszerindításkor feltölthető. Ez a paraméter meghatározza, hogy rendszerindításkor hány tétlen ügynök jöjjön létre. Ezek a tétlen ügynökök kezdetben nem rendelkeznek kapcsolattal a gazda adatbázis-kiszolgálóhoz.
Amikor egy ügyfél kapcsolatot kérelmez a gazdagéphez, a DB2 Connect megpróbál kiválasztani egy olyan ügynököt a csapatból, amelynek van kapcsolata a gazda adatbázis-kiszolgálóval. Ha ez nem sikerül, akkor a tétlen ügynökcsapatból próbál meg találni egy ügynököt. Ha ez a csapat üres, akkor a DB2 Connect létrehoz egy új ügynököt.
A MAX_COORDAGENTS konfigurációs paraméterrel szabályozhatja az egyidejűleg aktív ügynök maximális számát. Ezen szám túllépésekor az újabb kapcsolatok sqlcode SQL1226-os hibával meghiúsulnak. (Ez a kód azt jelenti, hogy a rendszer túllépte az egyidejű kifelé tartó kapcsolatok maximális számát.)
A DB2CONNECT_IN_APP_PROCESS DB2 nyilvántartás-változó lehetővé teszi a DB2 Connect Enterprise Editionnel azonos gépen futó alkalmazások számára, hogy vagy futtassák a DB2 Connectet az alkalmazás folyamatán belül, ami az alapértelmezett viselkedés, vagy csatlakozzanak a DB2 Connect EE kiszolgálóhoz gazdakapcsolatot egy ügynökön futtatva. Ahhoz, hogy egy alkalmazás az előre létrehozott kapcsolatokat használja, a gazdagép-kapcsolatot a DB2 Connect Enterprise Edition ügynökein keresztül kell létrehoznia, ennek érdekében a DB2CONNECT_IN_APP_PROCESS változó értéke NO kell, hogy legyen.
A DB2 Connect kapcsolat-összesítő technológiája lehetővé teszi DB2 Connect Enterprise Edition kiszolgálók számára, hogy több ezer párhuzamosan üzleti tranzakciókat végrehajtó felhasználót támogassanak, messzemenően csökkentve ennek során az S/390-es gazda- vagy AS/400-as adatbázis-kiszolgálókon igénybe vett erőforrásokat. Ezt úgy éri el, hogy az összes alkalmazás munkaterhelését sokkal kisebb számú S/390-es gazda- vagy AS/400-as adatbázis-kiszolgáló kapcsolatba vonja össze. Habár ez az eljárás hasonlónak tűnhet a fent ismertetett előre létrehozott kapcsolatokhoz, valójában ez a nagy mennyiségű OLTP (Online Tranzakció-feldolgozás) alkalmazás erőforrásfogyasztás-csökkentésének sokkal kifinomultabb megközelítése.
Az előre létrehozott kapcsolatokkal meg lehet takarítani az új kapcsolatok létrehozásának a költségét, amikor egy éppen befejeződő alkalmazásnak már nincs szüksége egy kapcsolatra. Másképp fogalmazva: egy alkalmazásnak szét kell kapcsolódnia a kiszolgálóval, mielőtt egy másik újra felhasználhatná a kapcsolatot.
A kapcsolat-összesítő viszont azt teszi lehetővé, hogy a DB2 Connect egy alkalmazás számára felhasználhatóvá tegyen egy kapcsolatot, mihelyt azon keresztül egy másik alkalmazás befejezett egy tranzakciót, és eközben nem kell annak a másik alkalmazásnak szétkapcsolódnia. A dolog lényege: egy alkalmazás egy adatbázis-kiszolgáló kapcsolatot a hozzárendelt gazda és DB2 Connect erőforrásokkal együtt csak az aktív tranzakciók ideje alatt használ. Amint a tranzakció befejeződik, a kapcsolat és a hozzárendelt erőforrások rendelkezésre állnak bármely más alkalmazás számára, amely tranzakciót hajtana végre.
A DB2 Connect előző verzióiban minden aktív alkalmazáshoz tartozott egy Alrendszer által Irányított Egység (Engine Dispatchable Unit, EDU), ami kezelte az adatbázis-kapcsolatot és az alkalmazások kérelmeit. Ezt az EDU-t általában koordinátor ügynöknek hívták. Minden egyes koordinátor ügynök nyomon követte az alkalmazás, valamint az EDU állapotát és környezetét. A kapcsolatok számának növekedésével minden egyes EDU jelentős memóriamennyiséget foglal le, és ehhez járul még az ügynökök közötti környezetváltás miatti további késleltetés.
A fenti felépítésben egy-egy megfeleltetés volt a kapcsolatok és az EDU-k között. A kapcsolat-összesítő azonban megengedi, hogy több kapcsolathoz ugyanaz az EDU tartozzon. Azaz a kapcsolatok (X) és az EDU-k (Y) viszonya most X >= Y.
A Kapcsolat-összesítő két részre bontja az ügynököt, egy logikai ügynökre, és egy dolgozó ügynökre. A logikai ügynökök egy alkalmazást jelölnek, de egy konkrét EDU-ra való hivatkozás nélkül. A logikai ügynök tartalmaz minden szükséges információt és vezérlőtömböt, amire az alkalmazásnak szüksége van. Ha n alkalmazás csatlakozott a kiszolgálóhoz, akkor n logikai ügynök lesz a kiszolgálón. A dolgozó ügynökök fizikai EDU-k, amelyek végrehajtják az alkalmazások kérelmeit, de amelyeknek nincs állandó csatolásuk egyetlen alkalmazáshoz sem. A dolgozó ügynökök társulnak a logikai ügynökökökkel a tranzakciók végrehajtására, a tranzakció végeztével pedig befejezik a társulást, és visszatérnek a szabadon felhasználható csapatba.
Az úgynevezett logikai ügynök ütemező rendeli a dolgozó ügynököket a logikai ügynökökhöz. Bizonyos platformokon a megnyitott fájlhivatkozások számának korlátozása azt eredményezheti, hogy egynél több logikai ügynök ütemező fog futni, amennyiben a logikai ügynökök száma meghaladja a fájlhivatkozás-korlátot.
A Kapcsolat-összesítő használatához a következő APAR-t kell alkalmazni DB2 for OS/390 Version 6.1 esetén:
APAR PQ33473
A MAX_LOGICAGENTS adatbáziskezelői konfigurációs paraméter állítja be a logikai ügynökök maximális számát. A MAX_LOGICAGENTS változó értékét bármely, az alapértelmezésnél nagyobb értékre állítva aktívvá teheti az összesítőt. A MAX_LOGICAGENTS alapértelmezett értéke egyenlő a MAX_COORDAGENTS értékével. Mivel minden alkalmazáshoz tartozik egy logikai ügynök, MAX_LOGICAGENTS valójában az adatbázis példányhoz csatlakoztatható alkalmazások számát határozza meg, miközben a MAX_COORDAGENTS azt szabályozza, hogy a mindenkori bejövő kapcsolatok közül hány lehet egyszerre aktív. A MAX_LOGICAGENTS változó a MAX_COORDAGENTS és 64.000 közötti tartományban tetszőleges numerikus értéket felvehet. A logikai ügynökök alapértelmezett száma egyenlő a MAX_COORDAGENTS változóval.
Számos létező konfigurációs paraméter segítségével konfigurálhatóak az ügynökök. Ezek a paraméterek a következőek:
A Kapcsolat-összesítő felépítése lehetővé teszi, hogy a DB2 Connect szorosan csatolt XA tranzakció kezelést nyújtson OS/390-es valamint AS/400-as DB2-höz. Az összesítő egyetlen ügynököt társít egy adott XA tranzakcióhoz (egyetlen XID), mint ahogy ezt bármely más tranzakcióval is tenné. Azonban ha az XA tranzakció xa_end() (elágazás határa) hívással ér véget, a dolgozó ügynök nem fog visszatérni az általános csapatba. Ehelyett az ügynök az adott XA tranzakcióhoz marad hozzárendelve. Amikor egy másik alkalmazás társul ugyanahhoz az XA tranzakcióhoz, a dolgozó ügynök ahhoz az alkalmazáshoz csatolódik.
Az ügynök minden tranzakció határvonal hívás után visszakerül a csapatba. Például az xa_prepare() csak olvashatóként kiadva, az xa_rollback(), xa_recover(), xa_forget(), xa_commit(), vagy bármely XA hiba, amely visszagörgetést okoz, visszaküldi az ügynököt a normál csapatba. Xa_end() önmagában csak a tranzakció ágat fejezi be, és ez nem elégséges ahhoz, hogy megszűnjön a társítása az XID-vel.
Elképzelhető, hogy a DB2 Connect kiszolgáló nem tud 4.000 egyidejű kapcsolatot fenntartani az adatbázis-kiszolgálóval. A legtöbb esetben az egy időpillanatban történő tranzakciók száma jóval kevesebb, mint a párhuzamos kapcsolatok száma. A rendszergazda ekkor az adatbázis-konfigurációs paraméterek következő beállításával maximalizálhatja a rendszer hatékonyságát:
MAX_LOGICAGENTS = 4.000 MAX_AGENTS = 1.000 MAX_COORDAGENTS = 1.000 NUM_POOLAGENTS = 1.000
Az összesítő így akár 4.000 párhuzamos szekciót is nyitva tarthat, bár az átjáró egyszerre csak 1.000 tranzakciót kezel.
Az XA tranzakciók esete valamennyire különböző. A példa kedvéért tegyük fel, hogy egy TP megfigyelőt használunk DB2 Connect átjáróval és egy OS/390-es vagy AS/400-as adatbázist. Amikor egy alkalmazás összeköttetést kérelmez, a kapcsolat-összesítő egy (eddig) inaktív ügynökkkel szolgálja ki a kérést vagy létrehoz egy új dolgozó ügynököt. Tegyük fel, hogy az alkalmazás egy XA tranzakciót kér. Egy XID jön létre a tranzakcióhoz, és hozzárendelődik a dolgozó ügynök.
Amikor az alkalmazás - kérésének kiszolgálása után - kiad egy xa_end() utasítást, elengedi a dolgozó ügynököt. A dolgozó ügynök továbbra is ugyanahhoz az XID-hez marad hozzárendelve. Most már csak az ilyen XID-nek megfelelő tranzakciók kéréseit tudja kiszolgálni.
Ekkor - tegyük fel - egy másik alkalmazás kérelmez egy nem XA tranzakciót. Ha nincs más rendelkezésre álló dolgozó ügynök, az XID-hez rendelt ügynök akkor sem lesz elérhető e második alkalmazás számára. Aktívnak tekintődik. A második alkalmazás számára új ügynök készül. Amikor a második alkalmazás befejezi a tranzakcióját, az ügynöke visszatér a szabadon felhasználható csapatba.
Ezalatt más alkalmazások, amelyek az első ügynökhöz rendelt XID-vel rendelkező tranzakciót kérelmeznek, csatlakozhatnak és lekapcsolódhatnak az első ügynökről, amely végrehajtja a számára kijelölt XA tranzakciót. Bármely alkalmazás, amely azt az adott tranzakciót kéri, ehhez az ügynökhöz kerül, ha ez éppen szabad.
A dolgozó ügynök nem tér vissza az általános csapatba, ameddig egy alkalmazás ki nem ad egy tranzakció határvonal hívást (ez nem az xa_end() hívás). Egy alkalmazás például befejezheti a tranzakcióját egy xa_commit() hívással, és ekkor a dolgozó ügynök eldobja a társítását az XID-vel, és visszatér a felhasználható csapatba. Ezután bármely alkalmazás igénybe veheti az ügynököt akár XA, akár nem XA tranzakcióra.
Számos fontos korlátozás létezik az átjáró összesítő használatával kapcsolatban. Mielőtt megkísérelné a Kapcsolat-összesítő használatát az adott rendszeren, tekintse át teljes egészében az alábbi tájékoztatót!
A rendszerteljesítményre hatással van a gazdagép vagy AS/400 adatbázis-kiszolgáló adatbázis teljesítménye.
A különböző adatbáziskezelő rendszereknek különböző teljesítményjellemzőik vannak. Például az egyes rendszerek SQL optimalizálói ugyanazon alkalmazás esetén különbözőképpen viselkedhetnek. További információért olvassa el a gazdagép vagy AS/400 adatbázis-kiszolgáló rendszerteljesítmény dokumentációját!
A DB2 Universal Database for AS/400 esetén javíthat a teljesítményen, ha a véglegesítés nélküli olvasás (uncommitted read, UR) vagy a nincs véglegesítés (no commit, NC) összerendelési beállítások segítségével elkerüli a naplózást.
Megjegyzés: | UR használata esetén azonban a nem naplózott adatokat csak olvasni lehet, frissíteni nem, és azt is csak akkor, ha a blokk-kezelés ALL-ra van állítva. |
Az alkalmazás-kiszolgálótól és a támogatott zárolási fokozatoktól függően a lekérdezés vagy alkalmazás elszigetelési szintje jelentős hatással lehet a teljesítményre.
Az adatbázisnak a normalizálás megfelelő szintjén kell lennie, hatékonyan kell használnia az indexeket és rendelkeznie kell megfelelő lefoglalt adatbázis-területtel. A teljesítményt a használt adattípusok is befolyásolhatják, a következő részekben leírtaknak megfelelően.
Az OS/390 V1R3 a minimális követelmény a TCP/IP támogatáshoz. Erősen javasolt az OS/390 V2R5 vagy ennél újabb verziója.
Az Elosztott adat szolgáltatás (Distributed Data Facility, DDF) felelős az elosztott alkalmazások DB2 for OS/390 termékhez történő kapcsolásáért. A DDF-et alkalmazáskiszolgálónak kell beállítani. Ehhez vagy be kell illeszteni a távoli rendszer LU nevét a SYSIBM.LUNAMES táblába, vagy be kell illeszteni a LUNAME, SYSMODENAME, USERSECURITY, ENCRYPTPSWDS, MODESELECT és USERNAMES értékeket a SYSIBM.SYSLUNAME táblába. Ezután végezzen DDF frissítést a rendszerbetöltő adathalmazon (Boot Strap Data Set, BSDS), például az az alábbiak szerint:
DDF LOCATION=LOC1,LUNAME=LU1,PORT=8000,RESPORT=8001
A legjobb teljesítményhez a javasolt DDF címtartomány sorrendezést (COMPAT mód esetén a DBM1-gyel egyenlő vagy kissé alacsonyabb érték) tanácsos használnia. VLF-ben használja a jogosultságok RACF gyorsítótárban való tartását, és lehetőség esetén használjon V5-ös csomag-jogosultság gyorsítótárat! A CACHEPAC=32768 beállítás elegendő a legtöbb művelet esetén.
Mivel a DDF megpróbál a VTAM-hoz kapcsolódni, a VTAM-nak aktívnak kell lennie a DDF indításakor. Íme egy VTAM APPL definíció:
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
Az OS/390-ben optimalizálhatja az inaktív szálak feldolgozását. A V3-ban legfeljebb 10,000 párhuzamosan csatlakozott ügyfél lehetséges, míg a V4-ben és V5-ben 25.000. A párhuzamosan aktív kapcsolatok legnagyobb száma azonban minden esetben 1999. Minden munkaállomás ügyfél csatlakozva maradhat, amikor inaktív; a hozzátartozó szál inaktív láncba kerül minden véglegesítéskor.
A CMTSTAT, CONDBAT és MAXDBAT DSNZPARM paraméterek befolyásolják a szálak feldolgozását. A legjobb teljesítmény elérése érdekében állítsa a CMTSTAT értékét INACTIVE-ra, igazítsa a CONDBAT értékét a bekapcsolódott DBAT-ok maximális számához úgy, hogy az jó teljesítményt adjon, a MAXDBAT értékét pedig állítsa a maximálisan elfogadható DBAT-ok számára!
A DB2 for OS/390 DRDA hálózatba való csatlakoztatásának teljes leírását (beleértve a VTAM konfigurálást is) lásd: Kapcsolódási kiegészítés.
Adatok egyik környezetből a másikba való átvitelekor átalakításra lehet szükség. Ez az átalakítás hatással lehet a teljesítményre.
A következő környezeteket kell figyelembe vennie:
valamint a következő numerikus adattípusokat:
A táblázat 8 alatt látható, hogy mikor van szükség átalakításra.
|
Intel |
IEEE |
S/370 & S/390 |
OS/400 |
---|---|---|---|---|
Tömörített decimális szám | ||||
Intel IEEE S/370/390 OS/400 |
Nem Nem Nem Nem |
Nem Nem Nem Nem |
Nem Nem Nem Nem |
Nem Nem Nem Nem |
Tizedes tört adattípus | ||||
Intel IEEE S/370/390 OS/400 |
Nem Nem Igen Igen |
Nem Nem Igen Igen |
Igen Igen Nem Nem |
Igen Igen Nem Nem |
Egész szám adattípus | ||||
Intel IEEE S/370/390 OS/400 |
Nem Igen Igen Igen |
Igen Nem Nem Nem |
Igen Nem Nem Nem |
Igen Nem Nem Nem |
Lebegőpontos adattípus | ||||
Intel IEEE S/370/390 OS/400 |
Nem Igen Igen Igen |
Igen Nem Igen Nem |
Igen Igen Nem Igen |
Igen Nem Igen Nem |
Az egybájtos karakteres adatátalakítás erőforrásigénye általában kisebb, mint a numerikus adatátalakításé (ahol adatátalakítás szükséges).
A DATE/TIME/TIMESTAMP adatok átalakítási erőforrásigénye majdnem ugyanannyi, mint az egybájtos CHAR típusé. A lebegőpontos adatok átalakítása veszi igénybe a legtöbb erőforrást. DB2 Connect alkalmazás készítésekor az alkalmazástervezőnek célszerű figyelembe vennie ezeket a tényezőket.
Ha az adatbázis táblában van 'FOR BIT DATA' oszlop, akkor az alkalmazás és az adatbázis közötti karakteres adatátvitelhez semmiféle átalakítás nem szükséges. Ez a gazdagépen vagy AS/400 adatbázis-kiszolgálón történő adatarchiváláskor használható.
A karakteres adatok CHAR vagy VARCHAR típusúak lehetnek. A mezőben lévő adatok tipikus méretétől függ, hogy a kettő közül melyik a hatékonyabb.
Elosztott adatbázis környezetben az általános teljesítményjavítás legjobb módja a hálózatból fakadó késleltetések kiküszöbölése. A hálózati rendszergazdák gyakran akkor tekintik a hálózatot hatékonynak, ha a lehető legtöbb adatot gyűjti össze az átvitelek között. Ez a megközelítés nem működik az elosztott adatbázisokhoz hasonló alkalmazások esetén, mivel az késleltetést épít a hálózatba. A végfelhasználó nem látja a hálózat hatékonyságát, csak a késleltetéseket.
A legtöbb hálózati eszköz késleltetési paraméterekkel rendelkezik, és a legtöbbnek olyan az alapértelmezése, amely nagyon rossz hatású elosztott adatbázisok esetén. A teljesítmény javításának érdekében tanácsos megkeresnie ezeket a paramétereket, és ha lehetséges nullára állítani azokat. Ezen kívül biztosítania kell, hogy az eszközökön lévő pufferméret elég nagy legyen ahhoz, hogy elkerülje az adatok újraküldését az adatok elveszte miatt. Például UNIX rendszerek esetén a küldési vagy vételi várakozási sor mélységének alapértéke 32. Jobb eredményt kap, ha a várakozási sor mélységét 150-re állítja. Az ehhez tartozó paraméter a DLC beállításokban a vételi mélység (Receive Depth), amelyet szintén 150-re kell állítani.
Az IOBUF paraméter a legtöbb esetben túl alacsony értékre van beállítva. Általában 500-ra van állítva, de a tapasztalat azt mutatja, hogy a 3992-es érték adja a legjobb teljesítményt nagy adatmennyiségek mozgatásakor, különösen csatorna összeköttetések, például ESCON vagy 3172 esetén.
SNA összeköttetések esetén tanácsos minden munkaállomás szoftver módprofil (Mode Profile) értékét 63-ra állítani. A vételi lépéstartás értékeket általában tanácsos a legnagyobb értékekre állítani, így a DB2 APPL utasításban illetve a munkaállomás PU/LU esetén a VPACING és PACING paramétereket, 63-ra kell állítani kapcsolt fő módban. Ez azt fogja eredményezni, hogy jelentősen megnövekedhet az üzenetváltások mennyisége, mielőtt a küldőnek a válaszra várakoznia kellene.
LAN rendszerben a DLC vagy LLC küldési és vételi ablakméretnek meghatározó hatása lehet a teljesítményre. A küldési értéket tanácsos hétre vagy ennél nagyobbra állítani, a legtöbb konfiguráció esetén pedig a négyes vagy kisebb vételi érték működik a legjobban.
Ha Ethernet hálózatot használ, a TCP szegmensméretet 1500 bájtra kell állítania. Token ring vagy FDDI hálózat esetén ezt az értéket 4400 bájtra érdemes állítani, míg ha ESCON kártyát használ TCP/IP-vel, mindig 4096-ra állítsa a szegmensméretet!
Végül TCP/IP hálózat esetén a TCP küldési és vételi pufferméreteknek 32768-nál nagyobbnak kell lenniük. A 65536-os érték általában a legjobb.
Megjegyzés: | Az átjáróról a kiszolgálóra kapcsolatot létesíteni (kimenő összeköttetés)
sokkal költségesebb, mint az ügyfélről az átjáróra (bemenő
összeköttetés). Olyan környezetben, ahol az ügyfelek ezrei gyakran
kapcsolódnak le és fel a kiszolgálóra az átjárón keresztül, jelentős
mennyiségű idő telik el a kimenő összeköttetések létesítésével. A DB2
Connect TCP/IP-ben összeköttetés-csapatokat kínál. Amikor az ügyfelek
az összeköttetés bontását kérik a kiszolgálótól, az átjáró eldobja az
ügyféllel létesített bemenő összeköttetést, de a kimenő összeköttetéseket
csapatban tartja. Amikor új ügyfél érkezik az átjáróhoz összeköttetési
kéréssel, az átjáró egy meglévőt ad a csapatból, ezzel csökkentve a teljes
összeköttetési időt és megkíméli a CPU-t az összeköttetések létrehozásának
magas költségétől.
Ha további tájékoztatásra van szüksége a DB2 alatti csapatokkal kapcsolatban, tekintse át az Administration Guide kézikönyvet! |
Az alábbi táblázat összefoglalja a hálózati teljesítményhangolási
módszereket.
Mit keressen | Példa | Beállítás | Megjegyzések |
---|---|---|---|
Szándékos késleltetések | Késleltetési paraméterek hálózati eszközökön | Állítsa 0-ra! | Az alapértelmezések általában magasabbak. |
Pufferek | IOBUF paraméter | Állítsa 3992-re! | Különösen hasznos ESCON vagy más csatorna kártya esetén! |
RUSIZE | 4096 az optimális méret | Az RUSIZE és RQRIOBLK ugyanakkora méretre való állítása adja a legjobb teljesítményt. | |
Lépéstartás | VPACING, PACING és a módprofilokat 63-ra kell állítani. | Lehetőleg használjon adaptív lépéstartást! | |
Kártyabeállítások | Küldési/vételi várakozási sor mélység | 150 a javasolt érték. | Az alapértelmezés általában 32. |
DLC ablakozás SNA esetén | Állítsa a küldési ablakméretet magasra (>7)! Állítsa az ablakméretet alacsonyra (pl. 1-re), próbálja ki és növelje addig, amíg megtalálja az ideális értéket! | Minden logikai egységnek van késleltetése. A lehető legegyszerűbb hálózati topológiát használja! | |
TCP beállítások | Szegmensméretek | 1500 Ethernet, 4400 token ring és FDDI esetén. | TCP/IP-hez használt ESCON kártyák esetén mindig 4096-ra kell állítani. |
Küldési/vételi területméretek | Mindkettőnek 64K-nak kell lennie. | Windows esetén 8192 az alapérték. A Windows nyilvántartásban lehet beállítani. |
A hardverrel kapcsolatosan a következő tényezőket kell figyelembe venni:
A teljesítmény javul gyorsabb átviteli közeg esetén. A következők például jellemző nyersadat-átviteli sebességek:
Az adatátviteli sebességet a gazdagép vagy AS/400 adatbázis-kiszolgálóhoz vezető láncban lévő leglassabb átviteli közeg korlátozza.
A hálózati kártya és a kommunikációs vezérlő memóriafelhasználását gondosan meg kell tervezni. Továbbá célszerű hálózati szakember véleményét kérnie, hogy a vezérlő képes-e kezelni a DB2 Connect által okozott többletforgalmat.
Ha az adatok LAN-ok között, vagy egy SNA hálózatból egy másik SNA hálózatba áramlanak, figyelembe kell venni az átviteli időt. A hidak, útvonalválasztók és átjárók növelik az eltelt időt. Például a hidak számának csökkentése csökkenti az egyes kérelmekhez szükséges ugrások számát.
A csomópontok közti fizikai távolságot is figyelembe kell venni. Még ha az üzenetet műholdon keresztül kerül is továbbításra, az átviteli sebességet a fénysebesség (3 * 10**8 m/s) és a feladó és a vevő közötti körutazás távolsága korlátozza.
Ha a hálózat sávszélessége teljesen ki van használva, az alkalmazásnak mind a válaszideje, mind az adatátviteli sebessége lecsökken.
Torlódás fordulhat elő a hálózaton, amennyiben a hálózat bizonyos részén felgyülemlenek az adatok, például egy alacsony pufferméretű régi NCP-nél.
Ha a hálózat hibaaránya magas, az átviteli teljesítmény lecsökken, ami gyenge teljesítményt okoz a szükséges újraküldések miatt.
A teljesítmény lecsökkenhet, ha túl sok feladat verseng a rendszer erőforrásaiért. Gondolja át a következő kérdéseket:
Ha a DB2 Connect felhasználók hosszú válaszidőt tapasztalnak a gazdagép vagy AS/400 kiszolgálóról érkező nagy lekérdezések esetén, a teljesítményprobléma lehetséges okának kiderítése érdekében a következő területeket kell megvizsgálni:
db2 update database manager configuration using RQRIOBLK 32767