Reglarea performanței în Informatica: Tutorial complet

⚡ Rezumat inteligent

Reglarea performanței în Informatica elimină cea mai lentă legătură dintr-o sesiune, câte un strat pe rând, lucrând de la țintă înapoi prin sursă, hartaping, sesiunea și în final sistemul de operare.

🎯 Ordine fixă: Informatica recomandă căutarea blocajelor ca țintă, apoi sursă, apoi hartăping, apoi sesiune, apoi sistem.
🧵 Statisticile firelor de discuție spun povestea: Cel mai aglomerat dintre firele de execuție pentru cititor, transformare și scriitor denumește stratul care necesită lucru.
🚿 Filtrare timpurie: Rândurile eliminate din Calificatorul sursă nu intră niciodată în canal, deci nu costă nimic în aval.
🗄️ Transferați lucrarea către baza de date: Unirile, sortările și filtrele se execută de obicei mai rapid în SQL decât într-o transformare.
🧊 Disciplina memoriei cache: Mai puține porturi și mai puține coloane de căutare înseamnă cache-uri mai mici și paginare pe disc mai redusă.
⚙️ Setările sesiunii contează: Dimensiunea bufferului DTM, dimensiunea blocului bufferului, intervalul de commit și optimizarea pushdown sunt reglate după hartăping e curat.

Citește mai mult

Ce este optimizarea performanței în Informatica?

Reglarea performanței în Informatica este practica de a găsi singura componentă care limitează viteza de rulare a unei sesiuni, de a elimina această limită și apoi de a repeta exercițiul cu oricare componentă devine cea mai lentă în continuare. O sesiune este întotdeauna la fel de rapidă ca stratul său cel mai lent, așadar reglarea unei transformări care nu a fost niciodată problema nu produce un câștig măsurabil.

Informatica identifică cinci locuri în care poate apărea un blocaj și recomandă verificarea acestora într-o ordine fixă.

Order	strat	Cauză tipică
1	Target	Scrieri lente, intervale mici de control, dimensiuni mici ale pachetelor de rețea ale bazelor de date
2	Sursa	Interogare lentă, indexuri lipsă, coloane inutile citite
3	Hartăping	Transformări scumpe sau plasate greșit, cache-uri supradimensionate
4	Sesiune	Buffer memorie, interval de commit, partiționare, tip de încărcare
5	Sistem și	Saturație CPU, așteptări I/O, paginare pe mașina Integration Service

Ordinea este deliberată. O țintă care nu poate absorbi rândurile suficient de repede va face ca fiecare strat din amonte să pară lent, așa că este verificat mai întâi. Metoda completă este documentată în Ghid de optimizare a performanței PowerCenter.

Cum să identificați blocajele de performanță

Ghicirea care strat este lent pierde mai mult timp decât măsurarea acestuia. Patru tehnici acoperă cele cinci straturi enumerate mai sus.

Rulați o sesiune de testare. Configurați o copie a sesiune pentru a scrie într-un fișier țintă plat. Dacă sesiunea se accelerează considerabil, ținta este blocajul. Imaginea în oglindă a aceluiași truc, citind dintr-un fișier sursă plat, izolează un blocaj sursă.
Analizați statisticile firelor de execuție. Managerul de transformare a datelor rulează un fir de citire, unul sau mai multe fire de transformare și un fir de scriere. Firul cu cel mai mare timp de ocupare din jurnalul sesiunii indică direct stratul stratificat asupra căruia să lucreze: cititor pentru sursă, transformare pentru hartă.ping, scriitor pentru țintă.
Analizați detaliile performanței. Activați colectarea datelor de performanță în cadrul sesiunii și citiți contoarele. Rândurile cu un număr mare de erori sau un număr mare de rânduri într-o memorie cache de căutare indică o mapareping problemă, mai degrabă decât una de bază de date.
Monitorizați sistemul. Operainstrumente de sistem care arată utilizarea CPU, așteptările I/O și paginarea, împreună cu Monitor flux de lucru vizualizările resurselor, dezvăluie o mașină care pur și simplu nu mai are capacitatea necesară.

Odată ce stratul responsabil este cunoscut, sfaturile la nivel de transformare din secțiunile următoare devin utile. Secțiunile sunt aranjate în ordinea pipeline-ului, din punctul în care datele intră în Hartăping până la punctul în care este agregat.

Transformare calificativ sursă

Fiecare rând pe care Calificatorul Sursă nu îl citește este un rând pe care nicio altă transformare nu trebuie să-l proceseze, ceea ce îl face cel mai ieftin loc din întreaga hartă.ping pentru a salva timp.

Aduceți numai coloanele necesare din sursă. De cele mai multe ori nu sunt obligatorii toate coloanele din tabelul sursă, așa că aduceți doar câmpurile obligatorii ștergând coloanele inutile.
Evitați utilizarea clauzei order by în interiorul Calificator sursă Suprascriere SQL. Clauza order by necesită procesare suplimentară, iar performanța poate fi îmbunătățită prin evitarea acesteia.

Transformarea filtrului

Filtrarea urmează același principiu un pas mai târziu în fluxul de lucru: eliminarea rândurilor nedorite în cel mai timpuriu punct în care hartaping are suficiente informații pentru a-i identifica.

Utilizare transformare filtru cât mai devreme posibil în interiorul hărțiipingDacă datele nedorite pot fi eliminate devreme în hartăping, ar crește debitul.
Folosește calificatorul sursă pentru a filtra datele. De asemenea, poți folosi suprascrierea SQL a calificatorului sursă pentru a filtra înregistrările, în loc să utilizezi transformarea filtrului.

Transformare tamplar

Alăturarea este prima operațiune cu adevărat costisitoare pe o hartă tipicăping, deoarece sursa principală trebuie memorată în cache înainte ca rândurile de detalii să poată fi comparate cu aceasta.

Dacă este posibil, preferați întotdeauna să efectuați joncțiuni în baza de date, deoarece joncțiunile în baza de date sunt mai rapide decât joncțiunile create în Informatica. transformare joiner.
Sortați datele înainte de alăturare, dacă este posibil, deoarece scade I/O pe disc efectuate în timpul conectării.
Faceți tabelul cu un număr mai mic de rânduri ca tabel principal.

Al treilea punct este cel mai des trecut cu vederea. Serviciul de integrare stochează în cache sursa principală, așadar nominalizarea tabelului mai mic ca principal menține memoria cache mică.

Transformarea căutării

O căutare fie interoghează baza de date o dată pe rând, fie construiește o memorie cache, iar ambele rute recompensează o sursă de căutare mai mică și mai bine indexată.

Creați un index pentru coloana dintr-un tabel de căutare care este utilizat în condiția de căutare. Deoarece tabelul de căutare va fi interogat pentru căutarea datelor corespondente, adăugarea unui index ar crește performanța.
Dacă este posibil, în loc să utilizați transformarea de căutare, utilizați join în baza de date. Pe măsură ce conexiunile la bazele de date sunt mai rapide, performanța va crește.
Ștergeți coloanele inutile din tabelul de căutare și păstrați numai coloanele necesare. Acest lucru va reduce costul de preluare a coloanelor suplimentare din baza de date.

Transformarea agregatorului

An Agregator păstrează datele într-o memorie cache în timp ce grupează rânduri, astfel încât orice reduce volumul care ajunge la aceasta reduce memoria cache de care are nevoie.

Filtrați datele înainte de a le agrega. Dacă utilizați transformarea filtrului în hartăping, apoi filtrați datele înainte de a utiliza agregatorul, deoarece acest lucru va reduce operațiunile de agregare inutile.
Limitați numărul de porturi utilizate în transformarea agregatorului. Aceasta va reduce volumul de date pe care transformarea agregatorului le stochează în memoria cache.

Reglarea la nivel de sesiune în Informatica

Când hartaping Însăși este curat, restul câștigurilor provin din proprietățile sesiunii. Aceste setări merită schimbate pe rând, cu o rulare cronometrată după fiecare modificare, deoarece multe dintre ele schimbă memoria în favoarea vitezei.

reglaj	Ceea ce controlează	Când să o schimbi
Dimensiunea bufferului DTM	Memoria totală alocată de Serviciul de Integrare pentru blocurile de date sursă și țintă	Crește atunci când sesiunea gestionează mai multe partiții, surse sau ținte
Buffer dimensiunea blocului	Dimensiunea unui bloc individual de memorie	Măriți pentru rânduri neobișnuit de mari; reduceți când memoria fizică este limitată
Interval de validare	Câte rânduri sunt scrise înainte de emiterea unei commit-uri	Ridică-l atunci când firul de execuție al scriitorului își petrece timpul așteptând punctele de control ale bazei de date
Optimizare pushdown	Cât de mult din hartăping Logica este convertită în SQL și executată de baza de date	Se utilizează atunci când sursa și destinația se află pe aceeași bază de date puternică

Buffer Memoria urmează un calcul documentat, nu o presupunere. Serviciul de integrare alocă cel puțin două blocuri pentru fiecare partiție sursă și țintă, astfel încât numărul de blocuri din bufferul de sesiune este (totalul surselor + totalul țintelor) înmulțit cu doi, iar dimensiunea bufferului DTM este numărul de blocuri înmulțit cu dimensiunea blocului buffer și împărțit la 0.9.

Optimizarea pushdown merită o precauție. Aceasta ajută doar atunci când baza de date este într-adevăr mai rapidă decât mașina Integration Service și logica transformării poate fi exprimată în SQL; logica care nu poate fi tradusă rămâne în sesiune, așa că câștigul este adesea mai mic decât cel așteptat. Măsurați înainte și după, în loc să o activați în mod implicit.

Întrebări frecvente

Partiționarea este utilă atunci când mașina Integration Service are procesor liber, iar sursa și ținta pot deservi conexiuni paralele. Pe o mașină saturată sau pe o țintă cu un singur fir de execuție, partițiile suplimentare adaugă costuri suplimentare fără a scurta execuția.

Setați memoria cache a indexului și a datelor suficient de mare pentru a conține întreaga sursă de căutare, altfel paginile Integration Service vor fi transferate pe disc. Jurnalele de sesiune raportează dimensiunea necesară a memoriei cache, deci rulați o singură dată cu dimensionare automată și citiți valoarea înapoi.

Fiecare inserare menține, de asemenea, fiecare index și constrângere asupra țintei, iar acest cost crește odată cu dimensiunea tabelului. Statisticile învechite ale bazei de date înrăutățesc lucrurile. Firul de execuție al scriitorului devine apoi cel mai aglomerat fir de execuție, ceea ce reprezintă semnătura clasică a blocajului țintei.

Da, deoarece transformarea poate elibera fiecare grup imediat ce se termină, în loc să stocheze totul în cache. Rândurile primite trebuie să fie deja sortate după porturile de grupare, iar sesiunea eșuează dacă nu sunt.

Pentru o sarcină mare, doar cu inserție, renunțațiping indecșii și constrângerile mai întâi, iar reconstruirea lor ulterior este de obicei mai rapidă. Comenzile SQL pre-sesiune și post-sesiune din proprietățile sesiunii sunt locul normal pentru scriptarea ambilor pași.

Modul în bloc ocolește o mare parte din jurnalizarea bazei de date și se încarcă mai rapid, dar previne recuperarea și nu funcționează cu toate țintele sau cu strategiile de actualizare. Modul normal scrie prin calea obișnuită înregistrată în jurnal și rămâne recuperabil.

Modelele antrenate pe baza timpilor de execuție istorici semnalează o sesiune care a deviat de la durata sa normală cu mult înainte ca cineva să observe și erori legate de cluster. Acestea indică rularea care s-a modificat - stratul responsabil trebuie încă confirmat din statisticile firelor de execuție.

Poate rescrie o interogare, sugera candidați pentru index și explica un plan de execuție lipit în editor. Nu poate vedea repozitoriul sau jurnalul sesiunii, așa că orice rescriere trebuie validată în funcție de planul real și de numărul de rânduri.