Řešení problémů s výkonem

Home / Support / Příručka administrátora /

Řešení problémů s výkonem

1. Task Manager – kontrola CPU

Windows Server 2016

Obrázek.png

Windows Server 2008

Obrázek.png

  • Na záložce „Details“ v „Task Manageru“ seřaďte spuštěné procesy sestupně podle sloupečku „CPU“ a zjistěte, který proces způsobuje neobvyklé vytížení CPU.

Obrázek.png

1.1. CPU je vytížené permanentně na 100 %

  • Permanentní vytížení CPU může značit zacyklení webové aplikace, konzolové aplikace nebo služby, které je způsobené chybou ve zdrojovém kódu aplikace.
  • Permanentní vytížení CPU procesem „w3wp.exe“ může značit zacyklení aplikačního poolu resp. chybu v některé z webových aplikací.
  • Permanentní vytížení CPU procesem „firebird.exe“ může značit buď špatně navržené SQL dotazy, které neúměrně vytěžují databázový server Firebird, nebo dlouhodobě narůstající zátěž databázového serveru, kterou je nutné řešit hardwarovým navýšením počtu jader procesoru.
  • Permanentní vytížení CPU procesem „sqlserver.exe“ může značit buď špatně navržené SQL dotazy, které neúměrně vytěžují databázový server MSSQL, nebo dlouhodobě narůstající zátěž databázového serveru, kterou je nutné řešit hardwarovým navýšením počtu jader procesoru.

1.2. Vytížení CPU osciluje kolem hranice 70 % a výše

  • Vyšší vytížení CPU procesem „w3wp.exe“ může značit neoptimální algoritmy v některé z webových aplikací.
  • Vyšší vytížení CPU procesem „firebird.exe“ může značit buď špatně navržené SQL dotazy, které neúměrně vytěžují databázový server Firebird, nebo dlouhodobě narůstající zátěž databázového serveru, kterou je nutné řešit hardwarovým navýšením počtu jader procesoru.
  • Vyšší vytížení CPU procesem „sqlserver.exe“ může značit buď špatně navržené SQL dotazy, které neúměrně vytěžují databázový server MSSQL, nebo dlouhodobě narůstající zátěž databázového serveru, kterou je nutné řešit hardwarovým navýšením počtu jader procesoru.

1.2.1. Příklady neoptimálních algoritmů

  • For cykly, které v každé iteraci volají SQL dotaz – řešením je hromadné načtení všech dat před samotným for cyklem, a následná indexace těchto dat do objektu „Dictionary“. Tento postup je detailně popsán v samostatné příručce Externí funkce.
  • Generování velkých souborů ve formátu PDF či XLSX pomocí knihoven „Aspose“ – řešením je hardwarové navýšení počtu jader.
  • Zpracovávání obrázků ve vysokém rozlišení – řešením je hardwarové navýšení počtu jader.
  • Neoptimální algoritmy jsou často umístěné v jedné z externích funkcí, nebo mohou být způsobené tiskem do tiskových šablon. V obou případech je důležité zkontrolovat report skriptů (total_worker_time) a externích funkcí (total_worker_time), ve kterém se dlouhé časy trvání skriptů nebo externích funkcí zobrazí na předních příčkách reportu.

1.3. Vytížení CPU osciluje pod hranicí 50%

Tento stav je normální.

2. Task Manager – kontrola paměti

Windows Server 2016

Obrázek.png

Windows Server 2008

Obrázek.png

  • Na záložce „Details“ v „Task Manageru“ seřaďte spuštěné procesy sestupně podle sloupečku „Memory (private working set)“ a zjistěte, který proces způsobuje neobvyklé vytížení paměti.

Obrázek.png

2.1. Paměť je vytížená permanentně na 100 %

  • Je nutné zjistit vytížení paměti procesem „w3wp.exe“, který může díky jednorázovému spouštění náročnějších úloh na paměť být omezen operačním systémem tak, že aktuálně alokovaná paměť již nemusí být dostatečná pro plynulý chod webových aplikací uvnitř tohoto procesu. V krizových situacích je možné NET Geniu dočasně zakázat používání cache vytvořením souboru „DenyCache.txt“ v adresáři „Config“, což zajistí menší spotřebu paměti, a při nedostatku paměťových prostředků rychlejší odbavování webových požadavků.
  • Permanentní vytížení paměti procesem „w3wp.exe“ může značit neoptimální algoritmy v některé z webových aplikací.
  • Permanentní vytížení paměti procesem „firebird.exe“ může značit buď špatně navržené SQL dotazy, které neúměrně vytěžují databázový server Firebird, nebo dlouhodobě narůstající zátěž databázového serveru, kterou je nutné řešit hardwarovým navýšením paměti.
  • Permanentní vytížení paměti procesem „sqlserver.exe“ může značit buď špatně navržené SQL dotazy, které neúměrně vytěžují databázový server MSSQL, nebo dlouhodobě narůstající zátěž databázového serveru, kterou je nutné řešit hardwarovým navýšením paměti.
  • Permanentní vytížení paměti procesem „sqlserver.exe“ mimo jiné značí, že jedna z instancí (většinou ta výchozí) nemá nastavený limit pro využívání paměti, což následně znemožňuje správný chod jak operačního systému, tak ostatních aplikací. Každá instance serveru MSSQL by měla mít vždy nastavený limit pro využívání paměti na bezpečnou mez, například pouze na 80% z celkové paměti, aby i operační systém a ostatní aplikace měly dostatek prostoru pro sv ou činnost.

2.2. Vytížení paměti se pohybuje mezi 60 % a 99 %

  • Je nutné zjistit vytížení paměti procesem „w3wp.exe“, který může díky jednorázovému spouštění náročnějších úloh na paměť být omezen operačním systémem tak, že aktuálně alokovaná paměť již nemusí být dostatečná pro plynulý chod webových aplikací uvnitř tohoto procesu. V krizových situacích je možné NET Geniu dočasně zakázat používání cache vytvořením souboru „DenyCache.txt“ v adresáři „Config“, což zajistí menší spotřebu paměti, a při nedostatku paměťových prostředků rychlejší odbavování webových požadavků.
  • Je vhodné zvážit hardwarové navýšení paměti především kvůli jednorázovému spouštění náročnějších úloh na paměť.
  • Je nutné zkontrolovat nastavení instance serveru MSSQL, zda má nastavený limit pro využívání paměti.

2.3. Vytížení paměti se pohybuje pod hranicí 50 %

Tento stav je normální.

3. Čekající aktualizace operačního systému Windows

  • Na aplikačním i databázovém serveru zkontrolujte frontu čekajících aktualizací, u kterých je nutné dokončit instalaci. Tyto aktualizace mohou čekat na pozadí, a brát paměť celému serveru, přestože v Task Manageru to vypadá, že má server volné paměti dostatek. Ten následně nemá prostředky pro běžné spouštění a běh procesů, a kolabují jak běžné aplikace na aplikačním serveru, tak i databázový server. Typicky se tento stav na databázovém serveru projevuje tím, že si instance MSSQL alokuje například pouze 200MB, přestože má nastavený limit na daleko více, nebo nemá nastavený limit na alokovanou paměť vůbec.

4. Debug Diagnostic Tool

  • V kritických situacích je nutné ukončit jednotlivé procesy v „Task Manageru“. Před tímto krokem je užitečné vytvořit „memory dump“ daného procesu, který může být následně analyzován pomocí nástroje „Debug Diagnostic Tool“, a dokáže odhalit jak zacyklené algoritmy, tak důvod zahlcení paměti.
  • Zjednodušený postup pro práci s „memory dumpy“ je uveden v souboru „Config\Tools\MemoryDumps.txt“ každého NET Genia:
1) Download and install Debug Diagnostic Tool v2 Update 2 (https://www.netgenium.com/download/DebugDiagx64.msi)
2) Locate memory dumps (C:\Users\abc\AppData\CrashDumps)
3) Run DebugDiag
4) Default Analysis / CrashHangAnalysis
5) Add Data Files
6) Start Analysis

5. Tento počítač – kontrola disků

  • Došlé místo na disku často znamená nenávratné ztráty dat spojené narušením konzistence databází. Nejrychlejší cesta, jak uvolnit místo na disku, je smazat logové soubory nebo zálohy databází a souborů.

Obrázek.png

  • Program „TDP x-Ray“ je ideální nástroj na detailní analýzu zaplnění disků jednotlivými adresáři a soubory.

Obrázek.png

  • Mezi logové soubory patří jak logové soubory samotného IIS umístěné ve výchozím adresáři „C:\inetpub\logs\LogFiles ”, tak logové soubory konkrétních NET Genií – adresář „Logs“ každého NET Genia.
  • Zálohy databází jsou často umístěné v adresáři „Backup“ každého NET Genia, nebo v adresáři „E:\BackupServer“.
  • IIS má ve výchozím nastavení zapnuté protokolování provozu webových aplikací, které je nutné co nejdříve vypnout. Současně s tím je důležité smazat již existující logy, které se ve výchozím nastavení ukládají do adresáře „C:\inetpub\logs\LogFiles“. Přesné umístění těchto logů zjist ěte z konkrétního nastavení IIS podle následujícího postupu.
  • Přejděte do nastavení IIS a vyberte nejvyšší uzel vašeho serveru/počítače (například „OFFICE“ / „TOMAS-PC“), aby se nastavení propsalo i na další podřízené uzly, a v sekci „IIS“ vyberte „Logging“ / „Protokolování“.

Obrázek.png

Obrázek.png

  • Na panelu „Akce“ na pravé straně okna poté klikněte na „Zakázat“. Tím se vypne logování povozu pro uzel vašeho serveru/počítače.

Obrázek.png

Obrázek.png

6. Performance Manager – kontrola diskových operací

  • Na záložce „Performance“ v „Task Manageru“ klikněte na odkaz „Open Resource Monitor“.

Obrázek.png

  • Na záložce „Disk“ v „Resource Monitoru“ seřaďte diskové aktivity sestupně podle sloupečku „Write“ a zjistěte, které soubory – databáze Firebird nebo MSSQL – vykazují neobvyklé zápisy na disk.

Obrázek.png

  • Mezi neobvyklé zápisy na disk mohou spadat také souborové přílohy v adresáři „Files“, což může způsobovat znatelné zpomalení NET Genia při renderování portletů, nahlížecích stránek nebo editačních formulářů. Zvýšená zápisová aktivita na disku může způsobit zpomalení čtení šablon ovládacích prvků uložených v souborech „ascx“, pokud nemá NET Genium umístěné souborové přílohy v adresáři „Files“ na jiném disku pomocí konfiguračního souboru „Files/Files“. Přesměrování souborových příloh do jiného umístění na disku je detailně popsán v samostatné příručce Příručka administrátora.
  • Pro rychlou kontrolu diskových operací otevřete nastavení NET Genia, a zapněte „Logování do konzole“, případně i „Logování na disk“, pokud si chcete detailně projít průběh renderování portletů, nahlížecích stránek nebo editačních formulářů:

Obrázek.png

  • Zavřete a znovu otevřete webový prohlížeč s NET Geniem, a v konzoli umístěné ve spodní části obrazovky zkontrolujte „Disk Time“, který značí součet časů čtení všech šablon ovládacích prvků z disku:

Obrázek.png

7. RunningQueries.exe

  • Aplikace „RunningQueries.exe“ je umístěna v adresáři „bin“ každého NET Genia, a slouží pro vyhodnocení aktuálně zpracovávaných databázových dotazů. Spuštění této aplikace vytváří logový soubor „RunningQueries.htm“ v adresáři „Logs“, a zároveň tento logový soubor otevírá. Zpracovávané dotazy zmíněné v tomto logovém souboru mohou být důvodem snížení výkonu databázového serveru. Zároveň mohou sloužit k identifikaci databáze, ve které dochází k výkonnostním problémům.

Obrázek.png

8. SQL Server – Activity Monitor

  • Spusťte „SQL Server Management Studio“ a klikněte na ikonu „Activity Monitor“.

Obrázek.png

  • Na záložce „Recent Expensive Queries“ identifikujte seznam naposledy spuštěných náročných databázových dotazů. Tyto dotazy mohou zároveň sloužit k identifikaci databáze, ve které dochází k výkonnostním problémům.

Obrázek.png

9. SQL Server – Top Queries by Total CPU Time

  • Spusťte „SQL Server Management Studio“, klikněte pravým tlačítkem myši na nejvyšší uzel v „Object Exploreru“, a vyberte „Reports / Standard Reports / Performance – Top Queries by Total CPU Time“.

Obrázek.png

  • V tomto reportu identifikujte seznam databázových dotazů, které nejvíce zatěžují databázový server. Tyto dotazy mohou zároveň sloužit k identifikaci databáze, ve které dochází k výkonnostním problémům.

Obrázek.png

  • Jakmile dojde k identifikaci databáze, ve které dochází k výkonnostním problémům, je výhodnější spustit konkrétní NET Genium, a nechat si zobrazit report „dm_exec_query_stats (total_worker_time)“. Tento report zobrazuje identický seznam databázových dotazů, které nejvíce zatěžují databázový server, a navíc nabízí možnost identifikace ovládacího prvku, který databázový dotaz spouští (odkaz „…“).
  • SQL Server nabízí také report „Top Queries by Average CPU Time“, který má ekvivalent v NET Geniu pod reportem „dm_exec_query_stats (average_worker_time)“.
  • Obecně je doporučené reporty procházet v následujícím pořadí:
    • dm_exec_query_stats (total_worker_time) – v tomto reportu jsou na prvních místech jak databázové dotazy, které mohou mít rozumný čas zpracování dotazu, ale spouští se příliš často, tak databázové dotazy, které se spouští v rozumných intervalech, ale mají dlouhý čas zpracování.
    • dm_exec_query_stats (execution_count) – v tomto reportu jsou na prvních místech databázové dotazy, které se spouští často, a proto je u těchto dotazů důležité posoudit „average_worker_time“.
    • dm_exec_query_stats (average_worker_time) – v tomto reportu jsou na prvních místech databázové dotazy, které mají dlouhý čas zpracování jednotlivých dotazů.
  • Typická chyba nesprávně navrženého dotazu, který je spouštěn velmi často, a nemá nastavený index na sloupečku „ng_url“.

Obrázek.png

10. Logování NET Genia a vyhodnocení logů

  • Kroky uvedené v předchozích kapitolách by měly sloužit k identifikaci databáze, ve které dochází k výkonnostním problémům.
  • Zapněte logování v nastavení NET Genia výběrem „Do databáze a na disk“. Detailní popis nastavení NET Genia je uveden v samostatné příručce Nastavení NET Genia.

Obrázek.png

  • Logy vyhodnoťte pomocí reportů, a identifikujte nahlížecí stránky, editační formuláře, databázové dotazy, skripty nebo externí funkce, které trvají nejdéle. Detailní popis reportů je uveden v samostatné příručce Reporty.
    • Nahlížecí stránky (average_worker_time)
    • Nahlížecí stránky (total_worker_time)
    • Editační formuláře (average_worker_time)
    • Editační formuláře (total_worker_time)
    • Databázové dotazy (average_worker_time)
    • Databázové dotazy (total_worker_time)
    • Skripty (average_worker_time)
    • Skripty (total_worker_time)
    • Externí funkce (average_worker_time)
    • Externí funkce (total_worker_time)

11. Úpravy SQL dotazů a programového kódu

  • Nejčastějším důvodem problémů s výkonem jsou nevhodně navržené databázové dotazy, nebo neefektivní načítání dat z databáze. Ve většině případů stačí správně nastavit indexy na sloupečky v databázi, nebo změnit způsob joinování databázových tabulek. Daleko pracnější, avšak stejně důležité, je změnit způsob načítání dat z databáze tak, aby se do databáze posílalo co nejméně dotazů, a vždy všechny dotazy dané úlohy spouštět pouze v rámci jediného připojení do databáze.

11.1. Nastavení indexů

  • Detailní popis problematiky indexů je uveden v samostatné příručce Reporty, kapitola Indexy.

11.2. Joinování databázových tabulek

  • Joiny jsou často buď úplně zbytečné, protože se ve výsledku nijak nepoužívají sloupečky načtené z přijoinované databázové tabulky, používají pomalejší „LEFT“ namísto rychlejšího „INNER“ v případech, kdy je „LEFT“ zbytečný, nebo používají „LEFT“ ve spojení s podmínkou databázového dotazu viz příručka Reporty, kapitola Databázové dotazy (LEFT JOIN + Podmínka)
  • Ve chvíli, kdy se k sobě joinují objemné databázové tabulky, nebo je joinů až příliš, je nutné zcela změnit logiku načítání dat, a nákladný databázový dotaz s mnoha joiny rozdělit do více jednodušších databázových dotazů.

11.3. SQL Server Database Engine Tuning Advisor – ladění SQL dotazů

  • SQL Server obsahuje užitečný nástroj na ladění databázových dotazů – SQL Server Database Engine Tuning Advisor. Zjednodušený postup pro ladění databázových dotazů je uveden v souboru „Config\Tools\TunningQueries.txt” každého NET Genia:
1) Run SQL Server Management Studio
2) Right click on the instance name and select 'Reports / Standard Reports / Performance – Top Queries by Total CPU Time'
3) Identify top queries with constants in a condition that can be improved with indexes
4) Right click on the background of the report and select 'Print / Excel'
5) Open printed Excel file
6) Create 'netgenium.sql' file and insert top queries using the following syntax:

use netgenium
go
SELECT ...
SELECT ...

7) Run SQL Server Database Engine Tuning Advisor
8) Click 'Start New Session'
9) Select 'File' as a 'Workload' and browse for 'netgenium.sql'
10) Mark 'netgenium' database
11) Click 'Start Analysis'
12) Analyze 'Recommendations' tab
13) Create new indexes as recommended

11.4. Minimalizace SQL dotazů pro načítání dat z databáze

  • Nejčastější chybou při načítání dat z databáze je „SELECT *“. Dotaz by nikdy neměl obsahovat hvězdičku jako zástupný znak pro všechny sloupce zdrojové databázové tabulky, i všech sloupců všech přijoinovaných tabulek, ale vždy by měl obsahovat výčet načítaných sloupců oddělených čárkou.
  • Načítání stringů neomezené délky (TextArea, RichTextBox, MultiListBox) způsobuje značné zpomalení zpracování databázového dotazu především na databázovém serveru Firebird. Tyto sloupce by se měly načítat pouze v nejnutnějších případech.
  • Detailní popis způsobu načítání dat z databáze pomocí C# včetně příkladů je uveden v samostatné příručce Externí funkce, kapitola Čtení dat z databáze.