Dostrajanie wydajności w Informatica: Kompletny samouczek

⚡ Inteligentne podsumowanie

Dostrajanie wydajności w Informatica polega na usuwaniu najwolniejszego łącza w sesji, warstwa po warstwie, pracując od celu z powrotem przez źródło, mapęping, sesja i na końcu system operacyjny.

  • 🎯 Stała kolejność: Informatica zaleca poszukiwanie wąskich gardeł w miejscu docelowym, źródłowym, a następnie mapowymping, następnie sesja, a następnie system.
  • 🧵 Statystyki wątku mówią wszystko: Najbardziej zajęty wątek czytelnika, transformacji i zapisu określa warstwę, nad którą trzeba popracować.
  • 🚿 Filtruj wcześnie: Wiersze odrzucone w kwalifikatorze źródłowym nigdy nie trafiają do potoku, więc nie generują żadnych dalszych kosztów.
  • 🗄️ Prześlij pracę do bazy danych: Łączenia, sortowanie i filtrowanie zwykle działają szybciej w języku SQL niż w przypadku transformacji.
  • 🧊 Dyscyplina pamięci podręcznej: Mniej portów i kolumn wyszukiwania oznacza mniejsze pamięci podręczne i mniej stronicowania dysku.
  • ⚙️ Ustawienia sesji mają znaczenie: Rozmiar bufora DTM, rozmiar bloku bufora, interwał zatwierdzania i optymalizacja pushdown są dostrajane po mapieping to czyste.

Strojenie wydajności w informatyce

Czym jest dostrajanie wydajności w Informatica?

Strojenie wydajności w Informatica polega na znalezieniu jednego komponentu ograniczającego szybkość działania sesji, usunięciu tego ograniczenia, a następnie powtórzeniu ćwiczenia na tym, który stanie się najwolniejszym komponentem. Sesja jest zawsze tak szybka, jak jej najwolniejsza warstwa, więc dostrojenie transformacji, która nigdy nie stanowiła problemu, nie przynosi mierzalnych korzyści.

Informatica zidentyfikowała pięć miejsc, w których może występować wąskie gardło, i zaleca ich sprawdzanie w ustalonej kolejności.

Zamówienie Warstwa Typowa przyczyna
1 Target Powolne zapisy, małe odstępy między punktami kontrolnymi, małe rozmiary pakietów sieciowych bazy danych
2 Źródło Powolne zapytanie, brakujące indeksy, odczytywane niepotrzebne kolumny
3 Mapaping Drogie lub źle umiejscowione transformacje, zbyt duże skrytki
4 Sesja Buffer pamięć, interwał zatwierdzania, partycjonowanie, typ obciążenia
5 Konfiguracja Nasycenie procesora, oczekiwanie na wejście/wyjście, stronicowanie na maszynie usługi integracji

Kolejność jest celowa. Cel, który nie może absorbować wierszy wystarczająco szybko, sprawi, że każda warstwa nadrzędna będzie wyglądać na powolną, dlatego jest sprawdzana w pierwszej kolejności. Pełna metoda jest udokumentowana w Przewodnik po dostrajaniu wydajności PowerCenter.

Jak zidentyfikować wąskie gardła wydajności

Zgadywanie, która warstwa jest wolniejsza, marnuje więcej czasu niż jej pomiar. Cztery techniki obejmują pięć warstw wymienionych powyżej.

  • Uruchom sesję testową. Skonfiguruj kopię Sesja zapisać do pliku docelowego w postaci płaskiego pliku. Jeśli sesja zauważalnie przyspieszy, to właśnie ten plik docelowy jest wąskim gardłem. Lustrzane odbicie tej samej sztuczki, odczyt z pliku źródłowego w postaci płaskiego pliku, izoluje wąskie gardło źródła.
  • Analizuj statystyki wątku. Menedżer transformacji danych uruchamia wątek odczytu, jeden lub więcej wątków transformacji oraz wątek zapisu. Wątek o największym czasie zajętości w dzienniku sesji wskazuje bezpośrednio warstwę, nad którą należy pracować: wątek odczytu dla źródła, wątek transformacji dla mapy.ping, pisarz dla celu.
  • Przeanalizuj szczegóły wydajności. Włącz zbieranie danych o wydajności w sesji i odczytaj liczniki. Wiersze z dużą liczbą błędów lub duża liczba wierszy w pamięci podręcznej wyszukiwania wskazują na mapę.ping problem, a nie problem bazy danych.
  • Monitoruj system. Operanarzędzia systemowe pokazujące użycie procesora, oczekiwanie na wejście/wyjście i stronicowanie, wraz z Monitor przepływu pracy widoki zasobów ujawniają, że maszyna po prostu nie wykorzystuje już swoich możliwości.

Po ustaleniu warstwy odpowiedzialnej warto zastosować się do porad dotyczących poziomu transformacji zawartych w kolejnych sekcjach. Sekcje są ułożone w kolejności potokowej, od punktu, w którym dane wchodzą do mapaping do punktu, w którym następuje agregacja.

Transformacja kwalifikatora źródła

Każdy wiersz, którego nie odczyta Kwalifikator źródła, to wiersz, którego żadna inna transformacja nie musi przetwarzać, co czyni go najtańszym miejscem na całej mapieping oszczędzać czas.

  • Pobierz ze źródła tylko wymagane kolumny. W większości przypadków nie wszystkie kolumny tabeli źródłowej są wymagane, dlatego należy wprowadzić tylko wymagane pola, usuwając niepotrzebne kolumny.
  • Unikaj używania klauzuli order by wewnątrz Kwalifikator źródła Nadpisanie kodu SQL. Klauzula order by wymaga dodatkowego przetwarzania, a jej pominięcie może zwiększyć wydajność.

Transformacja filtra

Filtrowanie odbywa się na tej samej zasadzie w kolejnym kroku procesu: odrzuca niechciane wiersze w najwcześniejszym punkcie, w którym mapa się znajduje.ping ma wystarczająco dużo informacji, aby je zidentyfikować.

  • Zastosowanie transformacja filtra jak najwcześniej na mapieping. Jeśli niepożądane dane można usunąć na wczesnym etapie mapyping, zwiększyłoby to przepustowość.
  • Użyj kwalifikatora źródła do filtrowania danych. Możesz również użyć nadpisania kwalifikatora źródła w kodzie SQL do filtrowania rekordów, zamiast stosować transformację filtru.

Transformacja Stolarza

Dołączenie jest pierwszą naprawdę kosztowną operacją w typowej mapiepingponieważ źródło główne musi zostać zapisane w pamięci podręcznej przed porównaniem z nim wierszy szczegółowych.

  • Jeśli to możliwe, zawsze preferuj wykonywanie połączeń w bazie danych, ponieważ połączenia baz danych są szybsze niż połączenia tworzone w Informatica transformacja stolarza.
  • Jeśli to możliwe, posortuj dane przed dołączeniem, ponieważ zmniejsza to dyskowe operacje we/wy wykonywane podczas łączenia.
  • Utwórz tabelę z mniejszą liczbą wierszy jako tabelę główną.

Trzeci punkt jest najczęściej pomijany. Usługa Integracji buforuje źródło master, więc nominowanie mniejszej tabeli jako master ogranicza rozmiar bufora.

Transformacja wyszukiwania

Wyszukiwanie albo wykonuje zapytanie do bazy danych raz na wiersz, albo tworzy pamięć podręczną w pamięci; obie metody nagradzają mniejsze, lepiej zindeksowane źródło wyszukiwania.

  • Utwórz indeks dla kolumny w tabela przeglądowa który jest używany w warunku wyszukiwania. Ponieważ tabela wyszukiwania będzie przeszukiwana w celu wyszukania pasujących danych, dodanie indeksu zwiększyłoby wydajność.
  • Jeśli to możliwe, zamiast używać transformacji wyszukiwania, użyj połączenia w bazie danych. Ponieważ łączenie baz danych jest szybsze, wydajność zostanie zwiększona.
  • Usuń niepotrzebne kolumny z tabeli przeglądowej i zachowaj tylko wymagane kolumny. Zmniejszy to obciążenie związane z pobieraniem dodatkowych kolumn z bazy danych.

Transformacja agregatora

An Agregator przechowuje dane w pamięci podręcznej, grupując jednocześnie wiersze, więc wszystko, co zmniejsza objętość docierającej do niego pamięci podręcznej, zmniejsza jej zapotrzebowanie.

  • Przefiltruj dane przed ich agregacją. Jeśli używasz transformacji filtru na mapieping, a następnie przefiltruj dane przed użyciem agregatora, ponieważ zredukuje to liczbę niepotrzebnych operacji agregacji.
  • Ogranicz liczbę portów używanych w transformacji agregatora. Spowoduje to zmniejszenie ilości danych przechowywanych w pamięci podręcznej przez transformację agregatora.

Strojenie na poziomie sesji w Informatica

Kiedy mapaping Sam w sobie jest czysty, pozostałe zyski pochodzą z właściwości sesji. Warto zmieniać te ustawienia pojedynczo, z odmierzonym czasem po każdej zmianie, ponieważ wiele z nich zamienia pamięć na szybkość.

Oprawa Co kontroluje Kiedy to zmienić
Rozmiar bufora DTM Całkowita pamięć przydzielana przez usługę integracji dla bloków danych źródłowych i docelowych Zwiększ, gdy sesja obsługuje wiele partycji, źródeł lub celów
Buffer rozmiar bloku Rozmiar pojedynczego bloku pamięci Zwiększ w przypadku nietypowo dużych wierszy; zmniejsz, gdy pamięć fizyczna jest ograniczona
Interwał zatwierdzania Ile wierszy jest zapisywanych przed wydaniem zatwierdzenia Podnieś ten alarm, gdy wątek pisarza spędza czas na oczekiwaniu na punkty kontrolne bazy danych
Optymalizacja pushdown Ile mapyping logika jest konwertowana na SQL i wykonywana przez bazę danych Użyj, gdy źródło i cel znajdują się w tej samej potężnej bazie danych

Buffer Pamięć opiera się na udokumentowanych obliczeniach, a nie na domysłach. Usługa Integracji przydziela co najmniej dwa bloki dla każdej partycji źródłowej i docelowej, więc liczba bloków bufora sesji jest mnożona przez dwa (łączna liczba źródeł + całkowita liczba celów), a rozmiar bufora DTM to liczba bloków pomnożona przez rozmiar bloku bufora i podzielona przez 0.9.

Optymalizacja pushdown wymaga ostrożności. Pomaga tylko wtedy, gdy baza danych jest rzeczywiście szybsza niż maszyna usługi integracji, a logikę transformacji można wyrazić w SQL; logika, której nie da się przetłumaczyć, pozostaje w sesji, więc wzmocnienie jest często mniejsze niż oczekiwano. Zmierz przed i po, zamiast włączać tę funkcję domyślnie.

FAQ

Partycjonowanie jest pomocne, gdy maszyna usługi integracji ma wolny procesor, a źródło i cel mogą obsługiwać połączenia równoległe. Na maszynie obciążonej obciążeniem lub w przypadku jednowątkowego celu, dodatkowe partycje zwiększają obciążenie bez skracania czasu wykonania.

Ustaw bufor indeksów i danych na tyle duży, aby pomieścić całe źródło wyszukiwania, w przeciwnym razie strony usługi integracji zostaną zapisane na dysku. Dzienniki sesji raportują faktycznie wymagany rozmiar bufora, więc uruchom go raz z automatycznym ustalaniem rozmiaru i odczytaj wartość.

Każdy insert zachowuje również wszystkie indeksy i ograniczenia w obiekcie docelowym, a koszt ten rośnie wraz z rozmiarem tabeli. Nieaktualne statystyki bazy danych pogarszają sytuację. Wątek zapisujący staje się wtedy najbardziej obciążonym wątkiem, co jest klasycznym sygnaturą wąskiego gardła obiektu docelowego.

Tak, ponieważ transformacja może zwolnić każdą grupę zaraz po jej zakończeniu, zamiast buforować wszystko. Przychodzące wiersze muszą być już posortowane według portów grupowania, a sesja kończy się niepowodzeniem, jeśli tak nie jest.

W przypadku dużego ładunku wkładanego tylko upuśćping Indeksy i ograniczenia najpierw, a następnie ich odbudowanie jest zazwyczaj szybsze. Polecenia SQL przed i po sesji, dotyczące właściwości sesji, to normalne miejsce na skryptowanie obu kroków.

Tryb zbiorczy pomija znaczną część rejestrowania w bazie danych i ładuje się szybciej, ale uniemożliwia odzyskiwanie i nie działa ze wszystkimi celami ani ze strategiami aktualizacji. Tryb normalny zapisuje dane poprzez standardową ścieżkę logowania i pozostaje odzyskiwalny.

Modele trenowane na historycznych czasach wykonania sygnalizują sesję, która odbiega od swojego normalnego czasu trwania na długo przed tym, zanim ktokolwiek to zauważy, oraz błędy związane z klastrem. Wskazują one na przebieg, który uległ zmianie — odpowiedzialna za to warstwa musi jeszcze zostać potwierdzona na podstawie statystyk wątków.

Potrafi przepisać zapytanie, zasugerować kandydatów do indeksu i wyjaśnić plan wykonania wklejony do edytora. Nie widzi repozytorium ani dziennika sesji, więc każde przepisanie musi zostać zweryfikowane pod kątem rzeczywistego planu i liczby wierszy.

Podsumuj ten post następująco: