Spis treści
Po wykonanych przeze mnie pracach nad Microsoft Dynamics AX i SQL Server średni czas wykonania 63 mierzonych zadań wsadowych spadł z 58 min 21 s do 13 min 9 s. Wynik pochodzi z podsumowania z października 2022 roku i dotyczy tego zbioru zadań, a nie szybkości całego systemu ERP.
Wolny ERP a praca produkcji
W międzynarodowej grupie z branży motoryzacyjnej wolne działanie i zawieszanie się Dynamics AX wpływały na codzienną pracę. Użytkownicy czekali na zakończenie operacji. Część zadań wymagała nadgodzin, a problemy z systemem prowadziły również do przestojów produkcyjnych.
Szczególnie istotne były zadania wsadowe odpowiedzialne za planowanie główne, czyli Master Scheduling. Wykonywały przetwarzanie potrzebne do przygotowania planu produkcji. Gdy nie kończyły się poprawnie lub na czas, plan był niekompletny albo nie powstawał.
Dlatego ocena zmian musiała uwzględniać zarówno parametry środowiska IT, jak i operacje potrzebne ludziom do pracy.
Moja rola i zakres prac
W okresie prac podsumowanych w 2022 roku byłem kierownikiem systemów IT. Samodzielnie wykonałem techniczne prace optymalizacyjne. W testy wydajnościowe zaangażowałem użytkowników kluczowych, czyli osoby z biznesu dobrze znające system i procesy swoich działów.
Opisywane działania były kontynuacją projektu z 2020 roku. Wyniki przedstawione w tym tekście pochodzą z podsumowania z października 2022 roku; nie opisują nieprzerwanego projektu trwającego przez cały ten okres.
Prace obejmowały Dynamics AX 2012, bazę SQL Server, serwery aplikacyjne, zadania wsadowe oraz nocne przetwarzanie danych dla raportowania i hurtowni danych.
Audyt i pomiary
Zacząłem od audytu technicznego i ustalenia poziomu bazowego wydajności. Dzięki temu miałem punkt odniesienia do oceny kolejnych zmian.
Analizowałem czas wykonania i obciążenie generowane przez zapytania, odczyty logiczne, plany wykonania oraz aktywne sesje i blokady. Sprawdzałem indeksy, aktualność i próbkowanie statystyk oraz wielkość tabel. Przejrzałem także konfigurację aplikacji i ruch sieciowy.
Następnie zweryfikowałem ustawienia pod kątem najlepszych praktyk. Część parametrów wymagała testów w naszym środowisku. Dotyczyło to między innymi MAXDOP oraz ustawień wielkości buforów.
W pojedynczym teście zmieniałem jeden parametr, zbierałem pomiary, porównywałem je z poziomem bazowym i zapisywałem wyniki. Na tej podstawie wybrałem zestaw ustawień odpowiadający naszemu środowisku.
Baza, aplikacja i przetwarzanie
Pracowałem w kilku powiązanych obszarach. Optymalizowałem zapytania i procedury SQL, indeksy i statystyki, a także wybrane modyfikacje Dynamics AX oraz elementy interfejsu generujące duże obciążenie.
Zmieniłem harmonogramy i parametry zadań wsadowych. Prace objęły również nocne przetwarzanie danych dla Business Intelligence — raportowania i analizy danych — oraz hurtowni danych. Optymalizowałem zapytania używane w integracji AX z systemem realizacji produkcji MES.
Zweryfikowałem i poprawiłem konfigurację AOS, czyli serwerów aplikacyjnych Dynamics AX. Sprawdziłem także ruch sieciowy. Zakres prac obejmował więc różne części środowiska; pomiary końcowe nie pozwalają przypisać całej poprawy jednemu ustawieniu.
Archiwizacja uzgodniona z biznesem
Zakres i częstotliwość czyszczenia oraz archiwizacji danych ustaliłem z jednostkami biznesowymi, szczególnie z finansami. Korzystałem ze standardowych mechanizmów AX i stworzyłem dodatkowe automatyczne mechanizmy w SQL Server Agent oraz SQL Server Integration Services (SSIS).
Przy porządkowaniu danych o wymiarach magazynowych InventDim uwzględniałem odwołania z tabel AX i rozszerzeń organizacji. Opis tych prac nie jest instrukcją czyszczenia danych w innym środowisku: zakres zależności i wymagania biznesowe trzeba sprawdzić dla konkretnego systemu.
Monitoring i testy użytkowników
Utworzyłem automaty zbierające dane o 10 kluczowych operacjach w systemie. Monitoring umożliwił bardziej proaktywną pracę nad wydajnością. W testach uczestniczyli użytkownicy kluczowi, dzięki czemu ocenialiśmy również działanie operacji wykonywanych na co dzień.
Te 10 operacji to odrębny zakres od 63 zadań wsadowych, których średnie czasy pokazuję poniżej.
Wyniki pomiarów AX i SQL Server
W podsumowaniu z października 2022 roku przedstawiłem cztery porównania. Każde dotyczy określonej funkcji lub miernika.
63 zadania wsadowe58 min 21 s → 13 min 9 s
Średnie obciążenie CPU55,1% → 17,2%
Odrębne miary i zakresy pomiarów; nie jest to wynik dla całego ERP.
| Miernik | Przed | Po | Zakres i ograniczenie pomiaru |
|---|---|---|---|
| Średni czas wykonania 63 mierzonych zadań wsadowych AX | 58 min 21 s | 13 min 9 s | W podsumowaniu nie opisano pełnej metody agregacji ani dokładnego okresu pomiaru. Wynik dotyczy tego zbioru zadań. |
| Średnie wykorzystanie procesora serwera bazy danych | 55,1% | 17,2% | Porównanie od 10 października 2022, godz. 00:00, do 13 października, godz. 08:00, z okresem od 3 października, godz. 00:00, do 6 października, godz. 08:00. Godziny według zrzutu źródłowego; strefy czasowej nie wskazano. Porównywalność obciążenia biznesowego nie została udokumentowana. |
| Czas otwarcia wybranego formularza AX | 10 min | 3 s | Wynik dotyczy jednego formularza, nie wszystkich ekranów systemu. |
| Zakleszczenia SQL przy planowaniu produkcji | ponad 100 dziennie | poniżej 10 dziennie | W podsumowaniu nie wskazano okresu obserwacji. Wynik nie oznacza wyeliminowania wszystkich blokad. |
Źródło: własne podsumowanie prac nad wydajnością AX z października 2022 roku, slajdy 12, 16 i 18. Dane przedstawiam anonimowo, bez identyfikatorów infrastruktury.
Zmiana średniego czasu zadań odpowiada skróceniu o około 77,5%. Jest to spadek czasu wykonania wskazanego zbioru, a nie miara przyspieszenia całego ERP. Spadek średniego wykorzystania procesora wynosi 37,9 punktu procentowego w porównanych okresach.
Na podstawie tych wartości nie wyliczam oszczędności finansowych ani odzyskanych godzin pracowników. Czas wykonania zadania na serwerze nie określa, ile czasu pracy ludzi udało się zaoszczędzić.
Efekty dla użytkowników i IT
Użytkownicy z finansów, planowania produkcji i zakupów potwierdzali poprawę komfortu pracy. Pozostały również zgłoszenia pojedynczych spowolnień i problemów ze środowiskiem zdalnego dostępu.
Optymalizacja oraz monitoring wspierały stabilność działania i pozwoliły lepiej przygotować środowisko do większego obciążenia. Są to rezultaty opisowe: nie podaję procentowego wzrostu satysfakcji ani zmierzonego przyrostu skalowalności.
Osobnym wynikiem jest brak krytycznych awarii ERP w latach 2021–2024 w obszarze, którym kierowałem. Krytyczna awaria oznacza tu zatrzymanie systemu w całej grupie albo w kluczowym obszarze. Był to rezultat pracy zespołu w tym okresie; opisane działania optymalizacyjne i monitoring stanowiły część tej pracy. Nie oznacza to braku wszystkich incydentów ani pełnej dostępności każdej funkcji systemu.
Jak oceniam podobny problem
Ten projekt pokazuje znaczenie punktu odniesienia i precyzyjnego zakresu wyniku. Przed wyborem zmian warto ustalić, która operacja utrudnia pracę, kiedy występuje problem i jakie dane pozwolą ocenić efekt.
Sama informacja, że „AX działa wolno”, jest początkiem rozmowy. Nazwa operacji, czas jej wykonania, pora występowania problemu i skutek dla procesu biznesowego pozwalają ją skonkretyzować. Wynik jednego projektu nie jest prognozą poprawy w innym środowisku.
Źródła i charakter materiału
Opis opiera się na moim podsumowaniu prac z października 2022 roku oraz potwierdzonym przeze mnie zakresie wykonanych działań. Zachowane materiały techniczne uzupełniają opis warsztatu diagnostycznego; same skrypty nie stanowią pomiaru uzyskanej poprawy. Dane dotyczą jednego środowiska i opisanych operacji.
O autorze
Rafał Mokrowiecki. Mam ponad 20 lat doświadczenia w IT, od programowania ERP do stanowiska dyrektora IT. Obecnie doradzam firmom; najlepiej znam Dynamics AX 2012 i SQL Server. Zobacz moje doświadczenie i zakres odpowiedzialności.
Która operacja w AX trwa zbyt długo? Napisz, co wykonujesz, kiedy występuje problem i jak wpływa na pracę firmy. To punkt wyjścia do rozmowy o zakresie diagnozy. Zakres wsparcia dla firm.
