Ottimizzazione delle prestazioni in Informatica: tutorial completo

By: David Carter David Carter
Hours aggiornato

⚡ Riepilogo intelligente

L'ottimizzazione delle prestazioni in Informatica rimuove il collegamento più lento in una sessione, un livello alla volta, lavorando dalla destinazione a ritroso attraverso la sorgente, la mappapingla sessione e infine il sistema operativo.

  • 🎯 Ordine fisso: Informatica consiglia di cercare i colli di bottiglia come obiettivo, poi come origine e infine come mappa.ping, poi sessione, poi sistema.
  • 🧵 Le statistiche del thread parlano chiaro: Il più impegnato dei thread di lettura, trasformazione e scrittura nomina il livello che necessita di lavoro.
  • 🚿 Filtrare in anticipo: Le righe scartate nel Source Qualifier non entrano mai nella pipeline, quindi non comportano alcun costo a valle.
  • ️ Invia il lavoro al database: Le operazioni di join, ordinamento e filtro sono generalmente più veloci in SQL che in una trasformazione.
  • 🧊 Disciplina della cache: Un minor numero di porte e di colonne di ricerca si traduce in cache più piccole e in un minor utilizzo del disco per la paginazione.
  • ⚙️ Le impostazioni della sessione sono importanti: La dimensione del buffer DTM, la dimensione del blocco del buffer, l'intervallo di commit e l'ottimizzazione del pushdown vengono regolati dopo la mappatura.ping è pulito.
Scopri di più

Ottimizzazione delle prestazioni in Informatica

Che cos'è l'ottimizzazione delle prestazioni in Informatica?

L'ottimizzazione delle prestazioni in Informatica consiste nell'individuare il componente che limita la velocità di esecuzione di una sessione, rimuovere tale limitazione e ripetere l'operazione sul componente successivo che risulta essere il più lento. La velocità di una sessione è sempre e solo pari a quella del suo livello più lento, quindi ottimizzare una trasformazione che non ha mai rappresentato il problema non produce alcun vantaggio misurabile.

Informatica identifica cinque punti in cui può trovarsi un collo di bottiglia e raccomanda di controllarli in un ordine prestabilito.

Ordine Strato Causa tipica
1 Target Scritture lente, intervalli di checkpoint ridotti, dimensioni ridotte dei pacchetti di rete del database
2 Fonte Query lenta, indici mancanti, lettura di colonne non necessarie
3 Mappaping Trasformazioni costose o mal posizionate, cache sovradimensionate
4 Sessione Buffer memoria, intervallo di commit, partizionamento, tipo di caricamento
5 Sistema Saturazione della CPU, attese I/O, paging sulla macchina del servizio di integrazione

L'ordine è intenzionale. Un target che non riesce ad assorbire righe abbastanza velocemente farà sembrare lento ogni livello a monte, quindi viene controllato per primo. Il metodo completo è documentato in Guida all'ottimizzazione delle prestazioni di PowerCenter.

Come identificare i colli di bottiglia delle prestazioni

Cercare di indovinare quale strato sia lento fa perdere più tempo che misurarlo. Quattro tecniche coprono i cinque strati sopra elencati.

  • Avvia una sessione di prova. Configura una copia del Sessione Scrivere su un file di testo. Se la sessione accelera in modo evidente, il collo di bottiglia risiede nel file di destinazione. L'operazione speculare, ovvero leggere da un file di testo, permette di isolare un collo di bottiglia nella sorgente.
  • Analizza le statistiche dei thread. Il gestore della trasformazione dei dati esegue un thread di lettura, uno o più thread di trasformazione e un thread di scrittura. Il thread con il tempo di attività più elevato nel registro di sessione punta direttamente al livello su cui lavorare: lettore per la sorgente, trasformazione per la mappa.ping, scrittore per il bersaglio.
  • Analizzare i dettagli delle prestazioni. Abilita la raccolta dei dati sulle prestazioni nella sessione e leggi i contatori. Un elevato numero di righe di errore o un gran numero di righe in una cache di ricerca indicano una mappaping problema piuttosto che un problema di database.
  • Monitorare il sistema. Operastrumenti di sistema che mostrano l'utilizzo della CPU, le attese I/O e il paging, insieme al Monitoraggio del flusso di lavoro Le visualizzazioni delle risorse rivelano che la macchina ha semplicemente esaurito la sua capacità.

Una volta individuato il livello responsabile, vale la pena applicare i consigli a livello di trasformazione contenuti nelle sezioni seguenti. Le sezioni sono organizzate in ordine di pipeline, dal punto in cui i dati entrano nel carta geograficaping fino al punto in cui viene aggregato.

Trasformazione del qualificatore di origine

Ogni riga che il Source Qualifier non legge è una riga che nessun'altra trasformazione deve elaborare, il che la rende il punto più economico dell'intera mappa.ping risparmiare tempo.

  • Porta solo le colonne richieste dall'origine. Nella maggior parte dei casi non tutte le colonne della tabella sorgente sono obbligatorie, quindi porta solo i campi obbligatori eliminando le colonne non necessarie.
  • Evitare di utilizzare la clausola order by all'interno della Qualificatore della fonte Sovrascrittura SQL. La clausola ORDER BY richiede un'elaborazione aggiuntiva e le prestazioni possono essere migliorate evitandola.

ARTICOLI CORRELATI

Trasformazione del filtro

Il filtraggio segue lo stesso principio un passo più tardi nella pipeline: scartare le righe indesiderate nel punto più precoce in cui la mappaping ha informazioni sufficienti per identificarli.

  • Usa il trasformazione del filtro il prima possibile all'interno della mappapingSe i dati indesiderati possono essere scartati all'inizio della mappapingCiò aumenterebbe la produttività.
  • Utilizza il qualificatore di origine per filtrare i dati. In alternativa alla trasformazione di filtro, puoi utilizzare l'override SQL del qualificatore di origine per filtrare i record.

Trasformazione falegname

L'unione è la prima operazione veramente costosa in una mappa tipicaping, perché la sorgente principale deve essere memorizzata nella cache prima che le righe di dettaglio possano essere confrontate con essa.

  • Se possibile, è sempre preferibile eseguire le join direttamente nel database, poiché le join create nel database sono più veloci di quelle create in Informatica. trasformazione del falegname.
  • Ordinare i dati prima dell'unione, se possibile, in quanto diminuisce l'I/O del disco eseguito durante l'unione.
  • Imposta come tabella principale quella con il minor numero di righe.

Il terzo punto è quello che più spesso viene trascurato. Il servizio di integrazione memorizza nella cache la sorgente principale, quindi nominare la tabella più piccola come principale mantiene la cache di dimensioni ridotte.

Trasformazione della ricerca

Una ricerca può eseguire una query sul database una volta per riga oppure creare una cache in memoria, ed entrambe le soluzioni premiano una fonte di ricerca più piccola e meglio indicizzata.

  • Crea un indice per la colonna in un tabella di ricerca che viene utilizzato nella condizione di ricerca. Poiché la tabella di ricerca verrà interrogata per trovare i dati corrispondenti, l'aggiunta di un indice migliorerebbe le prestazioni.
  • Se possibile, invece di utilizzare la trasformazione di ricerca, utilizzare l'unione nel database. Poiché le unioni del database sono più veloci, le prestazioni aumenteranno.
  • Elimina le colonne non necessarie dalla tabella di ricerca e mantieni solo le colonne obbligatorie. Ciò ridurrà il sovraccarico derivante dal recupero delle colonne aggiuntive dal database.

Trasformazione dell'aggregatore

An Aggregator Il sistema memorizza i dati nella cache mentre raggruppa le righe, quindi qualsiasi fattore che riduca il volume di dati che lo raggiunge riduce lo spazio di cache necessario.

  • Filtra i dati prima di aggregarli. Se stai utilizzando la trasformazione filtro nella mappaping, quindi filtra i dati prima di utilizzare l'aggregatore, in modo da ridurre le operazioni di aggregazione non necessarie.
  • Limita il numero di porte utilizzate nella trasformazione dell'aggregatore. Ciò ridurrà il volume di dati che la trasformazione dell'aggregatore memorizza nella cache.

Ottimizzazione a livello di sessione in Informatica

Quando la mappaping Il codice sorgente è pulito, i miglioramenti rimanenti derivano dalle proprietà della sessione. Vale la pena modificare queste impostazioni una alla volta, eseguendo un test cronometrato dopo ogni modifica, perché molte di esse comportano un compromesso tra memoria e velocità.

Configurazione Cosa controlla Quando cambiarlo
dimensione del buffer DTM Memoria totale allocata dal servizio di integrazione per i blocchi di dati di origine e di destinazione. Aumenta quando la sessione gestisce molte partizioni, sorgenti o destinazioni
Buffer misura del blocco Dimensione di un singolo blocco di memoria Aumentare per righe insolitamente lunghe; diminuire quando la memoria fisica è limitata.
intervallo di impegno Quante righe vengono scritte prima che venga emesso un commit? Genera questo errore quando il thread di scrittura impiega del tempo ad attendere i checkpoint del database.
ottimizzazione pushdown Quanto della mappaping La logica viene convertita in SQL ed eseguita dal database. Da utilizzare quando la sorgente e la destinazione risiedono sullo stesso potente database.

Buffer La gestione della memoria si basa su calcoli documentati anziché su supposizioni. Il servizio di integrazione alloca almeno due blocchi per ogni partizione di origine e di destinazione, quindi il numero di blocchi del buffer di sessione è pari a (origini totali + destinazioni totali) moltiplicato per due, e la dimensione del buffer DTM è data da tale numero di blocchi moltiplicato per la dimensione del blocco del buffer e diviso per 0.9.

L'ottimizzazione pushdown merita cautela. È utile solo quando il database è effettivamente più veloce della macchina del servizio di integrazione e la logica di trasformazione può essere espressa in SQLLa logica non traducibile rimane nella sessione, quindi il guadagno è spesso inferiore alle aspettative. È preferibile misurare prima e dopo piuttosto che abilitarlo come impostazione predefinita.

DOMANDE FREQUENTI

Il partizionamento è utile quando la macchina del servizio di integrazione dispone di CPU libere e sia l'origine che la destinazione possono gestire connessioni parallele. Su una macchina satura, o su una destinazione a singolo thread, partizioni aggiuntive comportano un sovraccarico senza ridurre la durata dell'esecuzione.

Imposta una cache di indice e dati sufficientemente grande da contenere l'intera origine di ricerca, altrimenti le pagine del servizio di integrazione verranno salvate su disco. I log di sessione riportano la dimensione della cache effettivamente necessaria, quindi esegui il processo una sola volta con il dimensionamento automatico e leggi il valore ottenuto.

Ogni inserimento mantiene anche tutti gli indici e i vincoli sulla tabella di destinazione, e questo costo aumenta con le dimensioni della tabella. Le statistiche obsolete del database peggiorano ulteriormente la situazione. Il thread di scrittura diventa quindi il thread più occupato, che rappresenta la classica causa di collo di bottiglia per il database di destinazione.

Sì, perché la trasformazione può rilasciare ciascun gruppo non appena termina, invece di memorizzare tutto nella cache. Le righe in ingresso devono essere già ordinate in base alle porte di raggruppamento e la sessione fallisce in caso contrario.

Per un carico di grandi dimensioni solo inserimento, far cadereping Creare prima gli indici e i vincoli e ricostruirli in seguito è solitamente più veloce. I comandi SQL pre e post-sessione sulle proprietà della sessione sono il luogo ideale per automatizzare entrambi i passaggi.

La modalità bulk ignora gran parte della registrazione nel database e carica più velocemente, ma impedisce il ripristino e non funziona con tutte le destinazioni o con tutte le strategie di aggiornamento. La modalità normale scrive attraverso il percorso di registrazione standard e rimane recuperabile.

I modelli addestrati sui tempi di esecuzione storici segnalano una sessione che si è discostata dalla sua durata normale molto prima che qualcuno se ne accorga, e individuano i guasti correlati al cluster. Indicano l'esecuzione in cui si è verificata la modifica: il livello responsabile deve ancora essere confermato dalle statistiche dei thread.

Può riscrivere una query, suggerire potenziali indici e spiegare un piano di esecuzione incollato nell'editor. Non può accedere al repository o al log di sessione, quindi qualsiasi riscrittura deve essere convalidata rispetto al piano effettivo e al conteggio delle righe.

Riassumi questo post con: