Jak postupovat při pomalosti ABRA Gen

Tento návod je určen pro situace, kdy se systém ABRA Gen spouští pomalu, pomalu otevírá agendy nebo se zpomalení projevuje při konkrétní činnosti. Jednotlivé kroky vám pomohou určit, zda je příčina spíše na stanici, v síti, na aplikačním serveru, v databázi nebo v konfiguraci systému.

Pokud budete pomalost řešit s podporou nebo se správcem systému, doporučujeme připravit možnost sdílení obrazovky a vzdáleného připojení. V praxi bývá pro vzdálené ovládání často vhodnější specializovaný nástroj než samotné sdílení přes komunikační aplikaci.

1. Prvotní ukázka a popis problému

Nejprve si nechte ukázat konkrétní místo nebo proces, kde se podle uživatele pomalost projevuje. Je vhodné si zároveň nechat vysvětlit i běžný pracovní postup a četnost použití.

Proč to děláme: Někdy se už v této chvíli ukáže, že se problém děje jen ojediněle nebo jej nelze cíleně zopakovat. Případně jde spíše o subjektivní hodnocení pomalosti, přitom systém běží v pořádku.

2. Prvotní měření

Vybranou pomalou činnost změřte alespoň třikrát po sobě, například pomocí stopek v telefonu. Tím si potvrdíte, že se problém skutečně děje, a zároveň odlišíte, zda je ukazovaný čas konstantní, nebo zda jsou další průchody už rychlejší.

Proč to děláme: Už tady je často vidět, že „je něco špatně“, což se potvrdí v dalších krocích. Například když se ABRA Gen spouští čtyři minuty, než dosáhne Shellu pro výběr agend.

3. Správce úloh (Task Manager) - procesy

Během pomalé operace otevřete Správce úloh systému Windows a sledujte zejména:

  • který proces nejvíce vytěžuje CPU,

  • využití sítě,

  • ostatní systémové prostředky.

Proč to děláme: Můžeme zjistit, které procesy vytěžují systém, a určit, zda s nimi souvisí i běh ABRA Gen. Například se tak může odhalit i jiný technický problém, který zpomaluje celý systém. V minulosti se řešily i případy, kdy nesprávné uvolňování WSKernelu vytěžovalo CPU a řešením bylo přenastavení WS.cfg a následná opravná verze.

4. Kontrola Nexus.cfg

Správce systému by měl zkontrolovat konfigurační soubor Nexus.cfg, zejména zda:

  • není zapnuto logování,

  • cesta pro logování neukazuje na složku, kterou klientská stanice nedokáže použít,

  • parametr ExcludedNxErrorCodes není zadán bez hodnoty.

Zapnuté logování může mít negativní vliv na výkon. Podrobnosti naleznete v kapitole Logování běhu aplikace.

Proč to děláme: Občas se stane, že po ladění nebo hledání chyby není logování vypnuto, případně je nastaveno nevhodně, a systém pak zpomaluje. Ideální je logovat jen konkrétní klienty nebo oddělenou testovací kopii.

5. Test výkonu

Spusťte agendu Test výkonu. Zabere přibližně minutu, ale řekne vám, jak je na tom:

  • rychlost stanice,

  • odezva aplikačního serveru,

  • odezva databáze,

  • výkon databáze při zápisu,

  • výkon databáze při čtení.

Význam jednotlivých hodnot je popsán v kapitole Test výkonu - popis.

Ideální případ je, když jsou všechny hodnoty na maximální úrovni:

Proč to děláme: Test výkonu nás může navést správným směrem, kde hledat zpomalení. Ukáže, zda je slabým místem stanice, síť, aplikační server nebo databáze. Do budoucna by mělo být toto měření rozšířeno i o další údaje týkající se přímo rychlosti aplikačního serveru.

6. Parametr NoScripting (-noscripting)

Hlášenou situaci ověřte dvakrát: jednou se zapnutým skriptingem a podruhé s vypnutým skriptingem pomocí parametru -noscripting. Výsledky porovnejte a v případě výrazného rozdílu začněte pátrat ve skriptech.

Proč to děláme: Je dobré si tuto variantu ověřit i tehdy, když uživatel tvrdí, že skripting už byl z možných příčin vyloučen.

7. Parametr ProfilingAutoStart (-profilingautostart)

Parametr -profilingautostart použijte v případě, pokud chcete začít profilovat hned od spuštění systému.

  • Po spuštění a přihlášení uživatele lze vyvolat Profiler klávesovou zkratkou Ctrl+Alt+Shift+F12.

  • Profilování je pak možné zastavit klávesovou zkratkou Ctrl+F2.

  • Tento postup je vhodný například při profilování rychlosti spuštění systému.

Proč to děláme: Profily je vhodné uložit a správně pojmenovat pro další analýzu, pokud bude potřeba dodat podklady vývoji nebo podpoře.

8. Lokální kopie programu

Pokud máte podezření, že je pomalost způsobena spuštěním ze serveru, ověřte chování při spuštění z lokální kopie programu na klientské stanici.

  • Ze serveru obvykle stačí zkopírovat celou složku s instalací programu.

  • Databáze se většinou nachází mimo tuto složku, ale je dobré to předem zkontrolovat, aby se nepřenášela data zbytečně.

  • V tomto kroku je také vhodné sledovat rychlost přenosu velkých souborů. Ta by měla dosahovat alespoň 80 MB/s.

  • Ověřte, zda je spuštění přes lokální kopii podstatně rychlejší než spuštění ze serveru pomocí zástupce.

Proč to děláme: U zákazníků s menším počtem koncových uživatelů může být lokální kopie řešením rychlosti spuštění i práce. U větších instalací je ale potřeba zvážit správu a aktualizaci těchto kopií.

9. Další doporučení pro optimalizaci

Pokud se ukáže, že je potřeba řešit výkon prostředí systematicky, doporučujeme projít kapitolu Optimalizace výkonu.

V případě pomalosti databázového serveru mohou být pro správce užitečné zejména tyto oblasti:

1: Pomalé spuštění systému a načítání agendy

Popis problému: „Pomalé spuštění ABRA Gen a načítání agendy“

Při vzdáleném řešení se projdou výše uvedené body. Měří se spuštění systému po síti a následné otevření agendy Výrobní příkazy.

Tabulka ukazuje první a druhé spuštění a rozdíl v naměřených časech.

1. měření 2. měření
Do Splash-e 1:02 0:31
Až do Shellu 2:16 1:10
Pak otevření agendy Výrobní příkazy +1:35 +0:26

Z naměřených hodnot je patrné, že druhé spuštění je mnohem rychlejší než první, protože dochází k načtení do paměti. Následně se ověří lokální kopie programu. Z ukázky se potvrdí, že rychlost spuštění z lokální kopie je násobně rychlejší než spuštění po síti přes zástupce. Při kontrole přenosu velkého souboru po síti se ukáže, že rychlost dosahuje jen přibližně 10-12 MB/s, přestože by měla být výrazně vyšší.

Výsledek: Na straně zákazníka se ověří, proč je přenos tak omezený, i když je síť 1 Gbps. Na straně podpory se může následně ověřit telemetrie a dodané profily z profileru, zda neobsahují něco neočekávaného.

Při následné komunikaci může vyjít najevo, že problém není v disku, ale například v parametrech síťové karty. V původním řešeném případě vedlo vypnutí funkcí RSC a LSO ke zvýšení přenosové rychlosti mezi koncovými počítači a serverem přibližně pětkrát.

2: Systém je poslední dobou pomalejší než dříve

Popis problému: „Poslední dobou je ABRA Gen pomalejší než předtím“

Při vzdáleném řešení se opět projdou výše uvedené body. Test výkonu spuštěný přímo na serveru ukáže, že odezva databáze je špatná, výkon stanice je v nižších hodnotách a v dobrých hodnotách zůstává pouze odezva aplikačního serveru. Současně uživatel uvádí, že pomalost se projevuje teprve poslední jeden až dva týdny.

Pokud jsou k dispozici údaje z telemetrie, mohou toto tvrzení potvrdit. V popisovaném případě od konkrétního dne vzrostlo vytížení CPU a průměrná doba vykonávání SQL dotazů se místy zvýšila až desetinásobně. Přitom v daném období nedošlo k aktualizaci systému ani databázového serveru Firebird. Vše tedy ukazovalo spíše na změnu v infrastruktuře.

Při kontrole prostředků se navíc ukázalo, že na serveru s 16 GB RAM běží tři aplikační servery, dva automatizační servery a API server, zatímco databázový server je na odděleném stroji. Pro dosažení co nejrychlejšího zpracování dotazů je přitom obecně vhodné mít aplikační server a databázový server co nejblíže sobě, ideálně na stejném serveru, pokud to architektura umožňuje.

Výsledek: Doporučí se ověřit, co se v konkrétním datu změnilo v infrastruktuře nebo v operačním systému, že došlo k tak výraznému zpomalení. Současně se doporučí zvážit umístění databázového a aplikačního serveru na stejný server.