Teljesítményhangolás az Informaticában: Teljes oktatóanyag

⚡ Okos összefoglaló

Az Informaticában a teljesítményhangolás rétegenként távolítja el a munkamenet leglassabb linkjét, a céltól a forráson, a térképen keresztül visszafelé haladva.ping, a munkamenetet és végül az operációs rendszert.

🎯 Fix sorrend: Az Informatica azt javasolja, hogy a szűk keresztmetszeteket először célként, majd forrásként, végül pedig térképként keresse meg.ping, majd munkamenet, végül rendszer.
🧵 A téma statisztikái elárulják a történetet: Az olvasói, átalakulási és írói szálak közül a legelfoglaltabb megnevezi azt a réteget, amelyen dolgozni kell.
🚿 Korai szűrés: A Forrásminősítőben eldobott sorok soha nem kerülnek be a folyamatba, így a későbbiekben semmilyen költséggel nem járnak.
🗄️ Munka feltöltése az adatbázisba: Az illesztések, rendezések és szűrések általában gyorsabban futnak SQL-ben, mint transzformációkban.
🧊 Gyorsítótár-fegyelem: Kevesebb port és kevesebb keresőoszlop kisebb gyorsítótárat és kevesebb lemezlapozást jelent.
🇧🇷 A munkamenet beállításai számítanak: A DTM pufferméret, a pufferblokkméret, a véglegesítési intervallum és a pushdown optimalizálás a map után kerül finomhangolásra.ping tiszta.

További információk

Mi a teljesítményhangolás az informatikában?

Az Informaticában a teljesítményhangolás azt a gyakorlatot jelenti, amelynek során megtaláljuk azt az egyetlen komponenst, amely korlátozza egy munkamenet futási sebességét, eltávolítjuk ezt a korlátot, majd megismételjük a gyakorlatot a következő leglassabb komponensen. Egy munkamenet csak olyan gyors, mint a leglassabb rétege, így egy olyan transzformáció hangolása, amely soha nem volt probléma, nem hoz mérhető nyereséget.

Az Informatica öt olyan helyet azonosít, ahol szűk keresztmetszet alakulhat ki, és azt javasolja, hogy ezeket egy meghatározott sorrendben ellenőrizzék.

Megrendelés	réteg	Tipikus ok
1	Target	Lassú írási műveletek, kis ellenőrzőpont-intervallumok, kis adatbázis-hálózati csomagméretek
2	Forrás	Lassú lekérdezés, hiányzó indexek, felesleges oszlopok beolvasása
3	Térképping	Drága vagy rosszul elhelyezett transzformációk, túlméretezett gyorsítótárak
4	Ülés	Buffer memória, véglegesítési intervallum, particionálás, betöltési típus
5	rendszer	CPU-telítettség, I/O-várakozások, lapozás az Integration Service gépen

A sorrend szándékos. Egy olyan cél, amelyik nem tudja elég gyorsan elnyelni a sorokat, minden felsőbb réteget lassúnak fog mutatni, ezért először ezt ellenőrizzük. A teljes metódus a dokumentációban található. PowerCenter teljesítményhangolási útmutató.

Hogyan azonosítsuk a teljesítménybeli szűk keresztmetszeteket

Több időt veszítünk azzal, ha találgatunk, melyik réteg a lassú, mint azzal, hogy megmérjük. Négy technika fedi le a fent felsorolt öt réteget.

Futtasson le egy tesztmenetet. Konfiguráljon egy másolatot a ülés egy lapos fájlba való íráshoz. Ha a munkamenet észrevehetően felgyorsul, akkor a cél a szűk keresztmetszet. Ugyanennek a trükknek a tükörképe, egy lapos fájlforrásból olvasva, azonosítja a forrás szűk keresztmetszetét.
Elemezze a szálak statisztikáit. Az Adatátalakítás-kezelő egy olvasószálat, egy vagy több átalakítási szálat és egy írószálat futtat. A munkamenet-naplóban a legnagyobb foglaltsági idővel rendelkező szál egyenesen a szerkesztendő rétegre mutat: az olvasó a forráshoz, az átalakítás a térképhez.ping, a célközönség írója.
Teljesítményelemzés részletei. Engedélyezze a teljesítményadatok gyűjtését a munkameneten, és olvassa be a számlálókat. A magas hibaszámú sorok vagy a keresési gyorsítótárban lévő nagyszámú sor leképezést jelez.ping probléma, nem pedig adatbázis-probléma.
Figyelje a rendszert. Operarendszereszközök, amelyek a CPU-használatot, az I/O várakozásokat és a lapozást mutatják, valamint a Munkafolyamat-figyelő az erőforrás nézetek egy olyan gépet mutatnak, amelynek egyszerűen nincs kapacitása.

Miután ismert a felelős réteg, érdemes alkalmazni a következő szakaszokban található transzformációs szintű tanácsokat. A szakaszok a folyamat sorrendjében vannak elrendezve, attól a ponttól kezdve, ahol az adatok belépnek a rétegbe. térképping odáig, hogy összesítik.

Forrásminősítő átalakítása

Minden sor, amit a forrásminősítő nem olvas be, olyan sor, amit egyetlen más transzformációnak sem kell feldolgoznia, így ez a legolcsóbb hely az egész térképen.ping időt spórolni.

Csak a szükséges oszlopokat hozza a forrásból. A legtöbb esetben a forrástábla összes oszlopa nem kötelező, ezért csak a kötelező mezőket hozza be a felesleges oszlopok törlésével.
Kerüld az order by záradék használatát a Forrás minősítő SQL felülbírálás. Az order by záradék további feldolgozást igényel, és a teljesítmény növelhető annak elkerülésével.

Szűrő átalakítás

A szűrés ugyanazt az elvet követi a folyamat egy későbbi lépésével: a nem kívánt sorokat a térkép legkorábbi pontján dobja el.ping elegendő információval rendelkezik ahhoz, hogy azonosítsa őket.

Felhasználás szűrőátalakítás a lehető leghamarabb a térképen belülpingHa a nem kívánt adatokat a térkép elején el lehet dobni.ping, ez növelné az áteresztőképességet.
Használjon forrásminősítőt az adatok szűréséhez. A rekordok szűréséhez szűrőtranszformáció használata helyett használhatja a forrásminősítő SQL-felülírását is.

Asztalos átalakulás

A csatlakozás az első valóban költséges művelet egy átlagos pályán.ping, mivel a fő forrást gyorsítótárazni kell, mielőtt a részletsorokat össze lehetne vetni vele.

Mindig az adatbázisban végezzünk illesztéseket, ha lehetséges, mivel az adatbázis-illesztések gyorsabbak, mint az Informaticában létrehozott illesztések. csatlakozó átalakítás.
Ha lehetséges, a csatlakozás előtt rendezze az adatokat, mivel ez csökkenti az összekapcsolás során végrehajtott lemez I/O-t.
Készítsen kevesebb sorból álló táblázatot fő táblázatként.

A harmadik pont a leggyakrabban figyelmen kívül hagyott. Az Integrációs Szolgáltatás gyorsítótárazza a fő forrást, így a kisebb tábla masterként való megjelölése kis gyorsítótárat biztosít.

Keresési átalakítás

Egy lekérdezés vagy soronként egyszer lekérdezi az adatbázist, vagy gyorsítótárat épít a memóriában, és mindkét útvonal egy kisebb, jobban indexelt keresési forrást jutalmaz.

Hozz létre egy indexet az oszlophoz egy keresőtábla amelyet keresési feltételben használnak. Mivel a keresési táblázatot lekérdezik a megfelelő adatok kikereséséhez, egy index hozzáadása növelné a teljesítményt.
Ha lehetséges, a keresési átalakítás helyett használja a csatlakozást az adatbázisban. Mivel az adatbázis-csatlakozások gyorsabbak, a teljesítmény növekedni fog.
Törölje a felesleges oszlopokat a keresőtáblából, és csak a szükséges oszlopokat tartsa meg. Ez csökkenti az extra oszlopok adatbázisból való lekérésének többletköltségét.

Aggregátor átalakítás

An Összesítő az adatokat a gyorsítótárban tárolja, miközben a sorokat csoportosítja, így bármi, ami csökkenti az elért mennyiséget, csökkenti a szükséges gyorsítótár méretét.

Szűrje az adatokat az összesítés előtt. Ha szűrőtranszformációt használ a térképenping, majd szűrje le az adatokat az aggregátor használata előtt, mivel ez csökkenti a felesleges aggregációs műveleteket.
Korlátozza az aggregátor transzformációban használt portok számát. Ez csökkenti az aggregátor transzformáció által a gyorsítótárban tárolt adatok mennyiségét.

Munkamenet-szintű hangolás az Informaticában

Amikor a térképping Maga a beállítás tiszta, a fennmaradó nyereség a munkamenet tulajdonságaiból származik. Ezeket a beállításokat érdemes egyenként módosítani, minden módosítás után időzített futtatással, mert több közülük memóriát cserél a sebesség érdekében.

Beállítás	Mit szabályoz	Mikor kell megváltoztatni
DTM puffer mérete	Az Integrációs Szolgáltatás által a forrás- és céladatblokkok számára lefoglalt teljes memória	Növelje, ha a munkamenet sok partíciót, forrást vagy célt kezel
Buffer blokk méret	Egyetlen memóriablokk mérete	Növelje a méretet szokatlanul nagy sorok esetén; csökkentse, ha a fizikai memória korlátozott
Véglegesítési intervallum	Hány sor kerül kiírásra egy commit kiadása előtt	Akkor aktiválja, amikor az írói szál az adatbázis ellenőrzőpontjain való várakozással tölti az idejét.
Lefelé tolható optimalizálás	A térkép mekkora részeping a logikát SQL-lé alakítja, és az adatbázis végrehajtja	Használja, ha a forrás- és céloldal ugyanazon a nagy teljesítményű adatbázison található

Buffer A memóriahasználat dokumentált számításon alapul, nem pedig találgatáson. Az Integrációs Szolgáltatás legalább két blokkot foglal le minden forrás- és célpartícióhoz, így a munkamenet-pufferblokkok száma (összes forrás + összes cél) szorozva kettővel, a DTM pufferméret pedig az adott blokkszám szorozva a pufferblokk méretével és osztva 0.9-cel.

A lefelé irányuló optimalizálással óvatosan kell bánni. Csak akkor segít, ha az adatbázis valóban gyorsabb, mint az Integration Service gép, és az átalakítási logika kifejezhető SQLA nem lefordítható logika a munkamenetben marad, így a nyereség gyakran kisebb a vártnál. Mérje meg előtte és utána, ahelyett, hogy alapértelmezettként engedélyezné.

GYIK

A particionálás akkor hasznos, ha az Integration Service gépnek van szabad CPU-ja, és a forrás- és célgép ki tudja szolgálni a párhuzamos kapcsolatokat. Telített gépen vagy egyszálú célgépen a plusz partíciók a futási idő lerövidítése nélkül növelik a terhelést.

Állítson be elég nagy index- és adatgyorsítótárat ahhoz, hogy a teljes keresési forrást elférje, egyébként az Integration Service oldalakat lemezre. A munkamenet-naplók a ténylegesen szükséges gyorsítótár-méretet jelentik, ezért futtassa egyszer automatikus méretezéssel, és olvassa vissza az értéket.

Minden beszúrás megőrzi a céltábla összes indexét és korlátozását, és ez a költség a tábla méretével nő. Az elavult adatbázis-statisztikák csak rontanak a helyzeten. Az író szál ezután a legforgalmasabb szállá válik, ami a klasszikus célpont szűk keresztmetszetének aláírása.

Igen, mert az átalakítás képes minden egyes csoportot azonnal felszabadítani, amint az véget ér, ahelyett, hogy mindent gyorsítótárazna. A bejövő soroknak már rendezve kell lenniük a csoportosítási portok szerint, és a munkamenet meghiúsul, ha nem így van.

Nagy, csak betéttel ellátott terhelés esetén ejtse leping Először az indexeket és a korlátozásokat kell létrehozni, majd utána általában gyorsabb újraépíteni őket. A munkamenet tulajdonságainál a munkamenet előtti és utáni SQL-parancsok a szokásos helyek mindkét lépés szkripteléséhez.

A tömeges mód megkerüli az adatbázis-naplózás nagy részét és gyorsabban töltődik be, de megakadályozza a helyreállítást, és nem működik minden céllal vagy frissítési stratégiával. A normál mód a szokásos naplózott útvonalon keresztül ír, és helyreállítható marad.

A korábbi futási időkön betanított modellek jelzik azokat a munkameneteket, amelyek jóval azelőtt eltértek a normál időtartamuktól, hogy bárki észrevenné őket, valamint a klaszterrel kapcsolatos hibákat. Rámutatnak a megváltozott futásra – a felelős réteget még meg kell erősíteni a szálstatisztikákból.

Képes átírni egy lekérdezést, indexjelölteket javasolni és elmagyarázni a szerkesztőbe beillesztett végrehajtási tervet. Nem látja a tárházat vagy a munkamenet-naplót, így minden átírást validálni kell a valós tervvel és a sorok számával szemben.