Pomalý Helios?

PříspěvekNapsal: 18.04.2019 12:05
od josef.korensky
Aktualizace 2023 - Marek Peisar

Obecně lze říci, že Helios není pomalý. Standardní funkcionalita funguje poměrně svižně i na pomalejším notebooku a to dokonce i v případě, že na tom samém notebooku je nainstalovaný SQL server.

Proč se tedy někdy stává, že uživatelé pláčí nad odezvami Heliosu?

1. Mód napájení
Schéma napájení musí být všude nastavené na „Vysoký výkon“. Mód „Rovnováha“, který je defaultní dokonce i na serverech, šetří energii tím, že snižuje frekvenci procesorů a vypíná procesorová jádra. Tím ale dramaticky snižuje výkon. Na databázový server je tedy naprosto nevhodný. Schéma se kontroluje v Ovládacích panelech. Schéma je nutné zkontrolovat:
  • na fyzickém serveru
  • v BIOSu fyzického serveru
  • v nastavení virtualizace
  • na virtuálním serveru
  • na PC/NTB koncových uživatelů
Už jsme se setkali s případem, kdy se načítání sestavy zkrátilo z 5-ti minut na 2 vteřiny.

Osmiprocesorový server v defaultním nastavení (schéma napájení rovnováha)
BalancedCPU.png
BalancedCPU.png (5.94 KiB) Zobrazeno 15843 krát


Osmiprocesorový server v nastavení "Vysoký výkon"
HighPerformanceCPU.png
HighPerformanceCPU.png (5.71 KiB) Zobrazeno 15843 krát


2. Čekající aktualizace
Aktualizace systému windows dokáže počítač nepříjemně zpomalit. A to i v případě, že pouze "čeká" na instalaci a vytížení procesoru je 5%. V těchto případech je potřeba aktualizaci nainstalovat a počítač restartovat.
Je nutné zkontrolovat/reatartovat:
  • Databázový server
  • Aplikační server
  • PC/NTB koncových uživatelů

3. LPIM
Zamykání stránek v paměti. Pokud má Windows nedostatek paměti, tak začne "čistit" cache jednotlivých programů. To se bohužel týká i procedurální cache SQL serveru. Následkem této akce je SQL server nucen kompilovat smazané exekuční plány a odezvy se Heliosu mohou protáhnout o jednotky až nižší desítky sec.

Náprava
Náprava spočívá v třech krocích.

3.1 Nejprve omezíme paměť SQL serveru, aby zbylo dost pro operační systém
  • V SQL Server Management Studiu klikneme pravým talčítkem na server a vybereme Properties
  • V levém seznamu vybereme položku Memory
  • Hodnotu Max Server Memory nastavíme tak, aby zbylo dost paměti pro operační systém (například Nainstalovaná paměť - 2 GB). Pro systémy s dostatkem RAM, na kterých neběží jen MS SQL je lepší pro OS ponechat 4 nebo 8 GB.

3.2 Zjištění, pod jakým účtem běží SQL Server
  • Spustíme SQL Server Configuration Manager
  • Zobrazíme Properties SQL serveru
  • Přejdeme na kartu "Log On"
  • Zkopírujeme si "Account name" do schránky

3.3 Zamknutí stránek SQL serveru v paměti
  • Spustíme na serveru příkaz: gpedit.msc
  • V levém panelu přejdeme na:
    Local Computer Policy
    - Computer Configuration
    - Windows Settings
    - Security Settings
    - Local Policies
    - User Rights Assigment
  • V pravém panelu rozklikneme:
    - Lock pages in memory
    - Klikneme na tlačítko Add User or Group
    - Vložíme ze schránky účet, pod kterým běží SQL a zkontrolujeme/změníme "Location", podle toho, zda jde o lokální, nebo doménový účet
    - Vše potvrdíme OK

4. Nastavení virtualizace (VMWARE)
Diskový řadič
  • pro optimální funkci se doporučuje nastavit více diskových řadičů (max 4), což zvýší propustnost systému
  • řadiče by měly být SCSI CONTROLLER - VMWARE PARTITUAL (ideální pro SQL, nízké nároky na CPU)
CPU
  • počet CPU by neměl být příliš nízký, ale ani příliš vysoký. Příliš vysoký počet CPU zvyšuje nároky na scheduler a tím paradoxně zhoršuje odezvy.
  • počet virtuálních CPU na socket (NUMA mód) nesmí být vyšší, než počet jader fyzického CPU (jeden socket). Pokud jsou virtuální jádra namapována na fyzická jádra různých socketů, tak dochází k extrémní degradaci výkonu.
  • Enable CPU hot add - NEZAŠKRTÁVAT
RAM
  • Reserve all guest memory - ZAŠKRTNOUT. Tím se zajistí, že paměť serveru nebude ve skutečnosti swap hostu.

5. Nastavení virtualizace (HYPER-V)
V nastavení HYPER-V doporučujeme disablovat "NUMA Spanning"

6. Údržba databáze
Pro SQL server je nezbytné provádět pravidelnou údržbu databáze. Správně nastavená údržba databáze zajišťuje
  • defragmentaci indexů
  • aktualizaci statistik
Aktualizaci statistik je nutné spouštět s hintem „WITH FULLSCAN“. S tímto nastavením trvá údržba déle, ale poskytuje podstatně lepší výsledky. Chybné statistiky mohou prodloužit čas dotazu o několik řádů.

Script pro vytvoření údržbového jobu je zde:
!JobUdrzbaDatabazi.hql
(5.88 KiB) 868 krát

Job provádí údržbu všech databází na serveru s výjimkou systémových databází. Job pracuje v noci a tak se jeho vliv projeví až druhý den ráno.
Po dokončení scriptu ukončete Helios. Pokud se zobrazí chybová hláška, tak jí můžete ingorovat

7. LEGACY_CARDINALITY_ESTIMATION
Nelekejte se složitě znějícího nadpisu :D . Existují dva postupy, jak předem odhadnout počty řádků v tabulce na splňujících nějakou podmínku. Nový postup (zavedený v SQL 2014 a novějších) neposkytuje pro Helios správné odhady a proto je vhodnější použít původní metodu. To se provede tímto scriptem:

USE NastavSpravnouDatabazi --Nejprve vybrat provozni DB
ALTER DATABASE
SCOPED CONFIGURATION
SET LEGACY_CARDINALITY_ESTIMATION = ON;

Jestliže existuje více instancí Heliosu (Databází), je nutné skript spustit na všech instancích (Databázích) Heliosu.

8. Externí řešení
Řešení třetích stran, externí triggery apod. mohou ovlivnit odezvy celého serveru.

9. Nastavení aplikace - Počítané sloupce
Pokud se v sestavách či přehledech používají počítané sloupce, tak se doba načtení může mnohonásobně prodloužit. Pak je vhodné vyzkoušet rychlost sestavy bez počítaných sloupců, popřípadě s jiným řazením.

10. Nastavení aplikace - Omezené načítání dat
Pokud sestava či přehled vrací příliš mnoho řádků, může být prodleva způsobena čekáním na předání dat ze serveru na klienta. Server může být seberychlejší, ale předání 5-ti milionů řádku z účetního deníku zkrátka nějakou dobu trvá. Pak je vhodné nastavit "Omezené načítání dat" a znovu rychlost sestavy otestovat. Viz níže obrázek omezené_načítání_dat_&_špinavé_čtení.png.

11. Nastavení aplikace - Špinavé čtení
V provozech s vysokým zatížením, kdy dochází k masivnímu zápisu a změnám v datech může být hlavním důvodem pomalejších odezev blokování procesů. Pokud některý proces mění data, ostatní procesy/uživatelé musí čekat až na dokončení. Zapnutím špinavého čtení se nastaví přehled/sestava do stavu, kdy nemusí čekat na dokončení změn a čte data tak, jak jsou aktuálně v systému. Viz níže obrázek Omezené_načítání_dat_&_špinavé_čtení.png.

Přehled -> Nastav.

Omezené_načítání_dat_&_špinavé_čtení.png
Omezené_načítání_dat_&_špinavé_čtení.png (75.2 KiB) Zobrazeno 5933 krát

Sestavu pak uložíme: 4 - Sestavy (vybrat sestavu) -> Uložit

12. Nastavení aplikace - Řazení
Pokud má sestava mnoho řádků, můžeme docílit výrazného zrychlení aplikováním předchozího bodu. Bohužel zde však existuje úskalí v podobě řazení sestavy podle uživatelem vybraného sloupce. Tato volba pak způsobuje, že se sestava stejně načte celá do paměti, následně se seřadí podle sloupce a teprve pak se zobrazí malé množství řádků uživateli.
Kvůli tomu pak omezené načítání dat ztrácí účinnost a aplikace se nezrychlí.

Proto je vhodné, pokud nepotřebujeme měnit řazení nechat defaultní (řazení podle ID). Tím zachováme výhody omezeného načítání dat.

Přehled -> Nastav.
Razeni_spatne.png
Razeni_spatne.png (66.16 KiB) Zobrazeno 5835 krát

Razeni_spravne.png
Razeni_spravne.png (59.85 KiB) Zobrazeno 5835 krát


Sestavu pak uložíme: 4 - Sestavy (vybrat sestavu) -> Uložit

13. Další nastavení
Spusťe příkaz:
Kód: Vybrat vše
EXEC sp_configure
a výsledky si uložte. Poslední sloupec znamená aktuálně používanou hodnotu, ke které se můžeme kdykoliv vrátit.
Parametry, kterými můžete ovlivnit odezvy SQL:
  • Autoshrink
    Doporučujeme vypnout funkcionalitu "Autoshrink" pomocí příkazu:
    Kód: Vybrat vše
    ALTER DATABASE Helios001 SET AUTO_SHRINK OFF

    , kde samozřejmě namísto "Helios001" doplníte provozní databázi.

  • Optimize for Ad-Hoc workload
    Doporučujeme nastavit na TRUE pomocí příkazu:
    Kód: Vybrat vše
    EXEC sp_configure 'optimize for ad hoc workloads', 1
    RECONFIGURE

  • max degree of parallelism
    Doporučujeme omezit počet paralelních vláken pomocí příkazu:
    Kód: Vybrat vše
    EXEC sp_configure 'max degree of parallelism', X
    RECONFIGURE

    , kde "X" nahradíme za polovinu počtu procesorů v jednom Node, maximálně však na hodnotu 8.
    Takže pokud mám v jednom node 8 procesorů, bude příkaz takto:
    Kód: Vybrat vše
    EXEC sp_configure 'max degree of parallelism', 4
    RECONFIGURE

  • cost threshold for parallelism
    Doporučujeme omezit použití paralelismus pomocí příkazu:
    Kód: Vybrat vše
    EXEC sp_configure 'cost threshold for parallelism', X
    RECONFIGURE

    , kde X nastavíme na 50 a postupně zvyšujeme třeba na 100, 200, 500, 1000, 2000 ...

14. Schvalování dokladů
Využíváte schvalování dokladů? Máte nainstalovaný plugin? Tak proveďte aktualizaci na poslední verzi. Funkce pro tento plugin byly v dubnu 2020 optimalizované a to dost podstatně.

15. SQL 2019/2022
Od MSSQL 2019 zavedl Microsoft mnoho novinek a jednou z nich je "Inlinning skalárních UDF funkcí". Což je celkem geniální, protože to znamená, že namísto, aby se funkce vypočítávala třeba milionkrát, tak se vypočte třeba jen jednou a dopady na výkon mohou být celkem zásadní. Bohužel se zdá, že tato funkcionaita má své mouchy a v některých případech nedojde k dramatickému zrychlení, ale naopak k velkému poklesu rychlosti.
V tom případě můžete inlining vypnout příkazem spuštěným v provozní databázi:

ALTER DATABASE SCOPED CONFIGURATION SET TSQL_SCALAR_UDF_INLINING = OFF

16. Nic z bodů výše nepomohlo
Pak existují dvě možnosti
  • Posílit HW
  • Objednat optimalizaci
Asseco Solutions může poskytnout kapacity pro monitoring a optimalizaci SQL serveru. Jde ovšem o placenou službu, která není součástí systémové podpory. V případě zájmu o tuto službu neváhejte naši firmu kontaktovat.

17. Hurá - pomohlo to
Pokud jste realizovali některý z bodů výše a situace se vyřešila, tak gratulujeme a budeme rádi za zpětnou vazbu (co konkrétně pomohlo) --> můžete zadat reakci na této stránce.