Wydajność XLa

[Lukas]

Cześć wszystkim,

chciałbym poruszyć dyskusję na temat ogólnej wydajności XLa. Mamy w firmie pododawane trochę kolumn dodatkowych. Po włączeniu tych kolumn oczywiście XL pracuje jak żółw. Czy znaleźliście jakieś sprawdzone sposoby na przyszpieszenie tego systemu? Mamy wersję 2019.3.2.

Przykładowo preliminarz płatności działa jakby nie działał, bardzo długo się odświeża lista. Dodatkowo w momencie kiedy w konstruktorze filtra wybierzemy dodatkowy filtr, który został utworzony przy pomocy tego forum, to przy powrocie z tego filtra już preliminarz się nie otwiera, tylko trzeba ubić proces XLa.

Parametry serwera mamy duże, tak na prawdę serwer "śpi" przy XLu.

Zapraszam do dyskusji.

[Monster]

Jak wszystkie zapytania - kolumny dodatkowe oraz filtry (szczególnie na preliminarzu) mogą być napisane bardziej lub mniej wydajnie.

Zacząłbym od tego, czyli właśnie konstrukcji kolumn i filtrów. Co nie zmienia faktu, że jest granica wydajności i dodanie wielu kolumn odpytujących wiele danych niestety musi spowalniać (zwłaszcza że podzapytania są uruchamiane dla każdego wiersza osobno).

[elmiq]

To, że masz filtr stworzony na forum, wcale nie oznacza, że będzie on wydajny. Jeśli chodzi o dodatkowe kolumny, to jest to związane ze specyfiką tego jak to działa od strony technicznej, czyli wykonywaniem podzapytań dla każdego wiersza oraz doczytywaniem wartości dla rekordów ze względu na ich widoczność na listach. Przy większej ilości płatności w połączeniu z dużym zakresem filtrowanych wartości ze względu na wybrane opcje filtrowania, być może rzeczywiście działa to wolno. XL sam w sobie jest systemem dla każdego, a jeśli specyfika Twojej instalacji wymaga określonych rozwiązań, to trzeba jest tworzyć z głową tak aby nie zabić wydajności samego systemu. Taka jest też rola partnerów/firm specjalizujących się w XL-u, aby znaleźć problem i stworzyć rozwiązanie - być może będzie to bardziej wydajny filtr, czy też kolumna, a może trzeba będzie pomyśleć o dodatkowych indeksach, bądź pomyśleć np. o pobieraniu danych w niektórych miejscach tylko z commitownych transakcji, tak aby nie czekać aż zwolnią się obiekty blokowane przez inne operacje.

Pozdrawiam,
Mateusz

[Lukas]

Tak swoją drogą, czy możecie sprawdzić jak wygląda u Was export do excela wpisów z Rejestrów VAT? Mamy dużo dokumentów i przy eksporcie nie eksportują się wszystkie dokumenty, ogranicza do 3000 dokumentów.

[Swiety_M]

Porównywanie wydajności pomiędzy klientami, jest dosyć niemiarodajne jeden ma bazę 20GB drugi 200GB, jeden ma bazę na dwóch dyskach w serwerze inny już siedzi na macierzy na SSD. Czasem problem jest sieć albo stacje robocze, bo ktoś żałuje na licencje terminalowe.

Twój partner powinien być twoim najlepszym doradcą, ale z doświadczenia wiem, że Partnerzy tematu wydajności unikają jak ognia.
Czasem jest to wiele spędzonych godzin na analizie logów profilera i innych zmiennych i ciężko później takich kilka/naście/dziesiąt roboczogodzin rozliczyć itp.itd...

[msiemienkowicz]

Czy dla tych nowych kolumn stworzyłeś też nowe indeksy i statystyki?

Mam sporo dodatkowych kolumn pozakładanych na listach, niektóre kolorowane, w momencie gdy były w fazie testów jeszcze bez indeksów i statystyk można było odczuć wyraźne spowolnienie.

W tej chwili baza ma 140 GB(na oddzielnej macierzy z NVMe) plus do tego oddzielna macierz na pliki TEMP (też na NVMe).
W jobach co godzinę uruchamia się skrypt sprawdzający fragmentację indeksów.

Wersja CDN 2020.

[Lukas]

Cześć,

możesz przybliżyć temat statystyk i indeksów? W tym momencie najgorszym problemem jest preliminarz płatności, który jest niemalże nieużywalny z racji szybkości pokazywania dokumentów.

czy jest jeszcze jakieś zapytanie, które w magiczny sposób może przyspieszyć działanie XLa?

[viesiek1]

Bazując na opisie dostępnym tu:

https://ola.hallengren.com/sql-server- ... ance.html

można wykonać takie polecnie:

Kod: Zaznacz cały

use master
go

EXECUTE dbo.IndexOptimize @Databases = 'CDNXL_FIRMA', @FragmentationLow = NULL, @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE', @FragmentationLevel1 = 80, @FragmentationLevel2 = 95, @UpdateStatistics = 'ALL', @StatisticsSample=100, @OnlyModifiedStatistics = 'Y'

[Lukas]

Cześć,

czy to nie jest czasem standardowe polecenie, które wykonuje się z poziomu menadżera baz? Bo widzę tam reindeksację etc.

[Swiety_M]

Temat indeksów był parokrotnie opisywany na forum. Dobrze poszukaj
Generalnie idea zgodnie z best practice MS powinna być taka, że sprawdzasz stan pofragmentowania swoich indeksów np,. zapytaniem:

Kod: Zaznacz cały

SELECT object_name(IPS.object_id) AS [TableName],
SI.name AS [IndexName], IPS.Index_type_desc, IPS.avg_fragmentation_in_percent
FROM sys.dm_db_index_physical_stats(db_id(N'CDNXL'), NULL, NULL, NULL , 'DETAILED') IPS
JOIN sys.tables ST WITH (nolock) ON IPS.object_id = ST.object_id
JOIN sys.indexes SI WITH (nolock) ON IPS.object_id = SI.object_id AND IPS.index_id = SI.index_id
WHERE ST.is_ms_shipped = 0
ORDER BY 1,3

Dalej raz w tygodniu wykonujesz reindeksacje gdzie stan pofragmentowania < 30%, a pełny rebuild indeksów tych, które są pofragmentowane > 30%
W zależności od wielkości przyrostów na twojej bazie manipuluje się % i czasookresami powyższych czynności.

Ja u swoich klientów robię to bezpośrednio z MSSQL, nie jestem do końca pewien co dokładnie robi narzędzie w menedżerze baz...
Jeśli jakaś funkcjonalność w twoim XL, kuleje wydajnościowo, najpierw zapuść profilera, przeanalizuj trace'a co tak naprawdę się dzieje na bazie i wrzuć w optymailzator MSSQL powinien co podpowiedzieć czy i ewentualnie gdzie jest problem z jakimiś brakującymi indeksami.

Chyba, że ktoś zna jakieś inne sposoby to może się podzieli wiedzą?

PS. Jeśli nie masz doświadczenia z grzebaniem w indeksach to lepiej nie ucz się tego na własnej bazie produkcyjnej, bo więcej możesz popsuć niż poprawić
Jeśli masz kumatego partnera to ON powinien twój problem ogarnąć