Prestandajustering i Informatica: Komplett handledning
David Carter
⚡ Smart sammanfattning
Prestandajustering i Informatica tar bort den långsammaste länken i en session, ett lager i taget, och arbetar från målet tillbaka genom källan, kartan.ping, sessionen och slutligen operativsystemet.
Vad är prestandajustering inom Informatica?
Prestandajustering i Informatica är praxisen att hitta den komponent som begränsar hur snabbt en session går, ta bort den gränsen och sedan upprepa övningen på den komponent som blir den långsammaste härnäst. En session är bara så snabb som dess långsammaste lager, så att justera en transformation som aldrig var problemet ger ingen mätbar vinst.
Informatica identifierar fem platser där en flaskhals kan sitta och rekommenderar att de kontrolleras i en fast ordning.
| Ordersammanställning | skikt | Typisk orsak |
| 1 | Target | Långsamma skrivningar, korta kontrollpunktsintervall, små nätverkspaketstorlekar för databaser |
| 2 | Källa | Långsam fråga, saknade index, onödiga kolumner läses |
| 3 | Kartaping | Dyra eller dåligt placerade transformationer, överdimensionerade cacher |
| 4 | Session Test | Buffer minne, commit-intervall, partitionering, laddningstyp |
| 5 | Systemkrav | CPU-mättnad, I/O-väntningar, växling på integrationstjänstdatorn |
Ordningen är avsiktlig. Ett mål som inte kan absorbera rader tillräckligt snabbt kommer att få varje uppströms lager att se långsamt ut, så det kontrolleras först. Den fullständiga metoden finns dokumenterad i PowerCenter Prestandajusteringsguide.
Hur man identifierar flaskhalsar i prestanda
Att gissa vilket lager som är långsamt slösar mer tid än att mäta det. Fyra tekniker täcker de fem lagren som listas ovan.
- Kör en testsession. Konfigurera en kopia av session att skriva till ett platt filmål. Om sessionen ökar märkbart i hastighet är målet flaskhalsen. Spegelbilden av samma trick, som läser från en platt filkälla, isolerar en flaskhals i källkoden.
- Analysera trådstatistik. Datatransformationshanteraren kör en läsartråd, en eller flera transformationstrådar och en skrivtråd. Tråden med den högsta upptagna tiden i sessionsloggen pekar direkt på lagret att arbeta med: läsare för källan, transformation för kartanping, författare för målet.
- Analysera prestandadetaljer. Aktivera insamling av prestandadata för sessionen och läs räknarna. Rader med högt fel eller ett stort antal rader i en sökcache indikerar en karta.ping problem snarare än ett databasproblem.
- Övervaka systemet. Operasystemverktyg som visar CPU-användning, I/O-väntningar och paging, tillsammans med Arbetsflödesövervakare resursvyer, avslöjar en maskin som helt enkelt har slut på kapacitet.
När det ansvariga lagret är känt blir råden för transformationsnivå i följande avsnitt värda att tillämpa. Avsnitten är ordnade i pipelineordning, från den punkt där data kommer in i kartaping till den punkt där det aggregeras.
Källa Qualifier Transformation
Varje rad som källkvalificeraren inte läser är en rad som ingen annan transformation behöver bearbeta, vilket gör den till den billigaste platsen i hela kartan.ping för att spara tid.
- Ta bara de obligatoriska kolumnerna från källan. Oftast krävs inte alla kolumner i källtabellen, så ta bara med de obligatoriska fälten genom att ta bort de onödiga kolumnerna.
- Undvik att använda ordningsföljdsklausulen inuti Källkval SQL-override. Order by-klausulen kräver ytterligare bearbetning och prestandan kan ökas genom att undvika den.
Filtertransformation
Filtrering följer samma princip ett steg senare i processen: kassera oönskade rader vid den tidigaste punkten där kartanping har tillräckligt med information för att identifiera dem.
- Använda filtertransformation så tidigt som möjligt inne på kartanpingOm oönskad data kan kasseras tidigt i kartanping, det skulle öka genomströmningen.
- Använd källkvalificeraren för att filtrera data. Du kan också använda källkvalificeraren SQL override för att filtrera posterna istället för att använda filtertransformation.
Joiner Transformation
Att gå med är den första verkligt dyra operationen i en typisk kartaping, eftersom huvudkällan måste cachages innan detaljrader kan matchas mot den.
- Föredra alltid att utföra joins i databasen om möjligt, eftersom databasjoins är snabbare än joins skapade i Informatica. joiner-transformation.
- Sortera data före koppling om möjligt, eftersom det minskar disk I/O som utförs under koppling.
- Skapa tabellen med färre rader som huvudtabell.
Den tredje punkten är den som oftast missas. Integrationstjänsten cachar huvudkällan, så att nominera den mindre tabellen som huvudtabell håller cachen liten.
Lookup Transformation
En sökning frågar antingen databasen en gång per rad eller bygger en cache i minnet, och båda vägarna belönar en mindre, bättre indexerad sökkälla.
- Skapa ett index för kolumnen i en uppslagstabell vilket används i sökvillkor. Eftersom söktabellen kommer att sökas efter matchande data, skulle ett index öka prestandan.
- Om möjligt, istället för att använda uppslagstransformation, använd join i databasen. Eftersom databasanslutningar går snabbare kommer prestandan att öka.
- Ta bort onödiga kolumner från uppslagstabellen och behåll endast de obligatoriska kolumnerna. Detta kommer att minska omkostnaderna för att hämta de extra kolumnerna från databasen.
Aggregatorförvandling
An Aggregator lagrar data i en cache medan den grupperar rader, så allt som minskar volymen som når den minskar den cache den behöver.
- Filtrera data innan du aggregerar dem. Om du använder filtertransformation i kartanpingoch filtrera sedan data innan du använder aggregatorn eftersom det minskar onödiga aggregeringsoperationer.
- Begränsa antalet portar som används i aggregatortransformationen. Detta minskar mängden data som aggregatortransformationen lagrar i cachen.
Sessionsnivåjustering i Informatica
När kartanping i sig själv är ren, kommer de återstående vinsterna från sessionsegenskaperna. Dessa inställningar är värda att ändra en i taget, med en tidsinställd körning efter varje ändring, eftersom flera av dem byter minne mot hastighet.
| Att lägga plattor | Vad den kontrollerar | När man ska ändra det |
| DTM-buffertstorlek | Totalt minne som integrationstjänsten allokerar för käll- och måldatablock | Öka när sessionen hanterar många partitioner, källor eller mål |
| Buffer block storlek | Storleken på ett enskilt minnesblock | Öka för ovanligt stora rader; minska när det fysiska minnet är begränsat |
| Bekräfta intervall | Hur många rader skrivs innan en commit utfärdas | Hämta den när skrivtråden spenderar sin tid med att vänta på databaskontrollpunkter |
| Pushdown-optimering | Hur mycket av kartanping Logiken konverteras till SQL och exekveras av databasen | Använd när källa och mål finns i samma kraftfulla databas |
Buffer Minnet följer en dokumenterad beräkning snarare än gissningar. Integrationstjänsten allokerar minst två block för varje käll- och målpartition, så antalet sessionsbuffertblock multipliceras med två (totala källor + totala mål), och DTM-buffertstorleken är blockantalet multiplicerat med buffertblockstorleken och dividerat med 0.9.
Pushdown-optimering förtjänar en försiktighetsåtgärd. Den hjälper bara när databasen verkligen är snabbare än integrationstjänstens maskin och transformationslogiken kan uttryckas i SQL; logik som inte kan översättas stannar kvar i sessionen, så vinsten är ofta mindre än förväntat. Mät före och efter istället för att aktivera den som standard.
