Mis toimub „karu kõhus“ ehk miks majandustarkvaral jaks otsa saab?!

Seadistused, mis mõjutavad tugevalt jõudlust ja kuidas neid avastada.

Autor: Rain Raadla; BCS Itera tehniline konsultant

Majandustarkvara on nagu auto. Enne kasutusele võttu tuleb täpselt paika panna milline peaks ideaalne isend olema. Mõtlema täpselt läbi oma praegused vajadused, kes ja kui palju kasutama hakkab ning kuidas kasutatakse 1,2,3 aasta pärast.  Ning kui esmane käivitamine (GO-LIVE) on tehtud tuleb mõlemat hakata jälgima, tuunima ja korrastama.

Hooldamata ja puhastamata majandustarkvara andmebaas töötab nii nagu sarnaselt koheldud auto – sõidab kohale aga mitte kiiresti, mõnel halval päeval ei taha üldse tööle minna. Kõigile meile meeldib kiiresti kohale jõuda, seega siin mõned näpunäited kuidas panna majandustarkvara mootor täistuuridel tööle ning hoida tippkiirust ka pärast aastatepikkust kasutamist.

Kogu protsess jaguneb kolmeks etapiks:

1. Tegevused enne arenduste algust ehk nõuetele vastav riistvara ja tarkvara
2. Jõudluse kontroll pärast Go-Live ehk päriselu
3. Andmebaasi regulaarne hooldus pärast Go-Live

Tegevused enne arenduste algust ehk nõuetele vastav riistvara ja tarkvara

Juba majandustarkvara juurutamise projekti algfaasis tuleb ära teha reaalse tööolukorra jõudluse analüüs. Lühidalt näeb see välja selline:

1. Kui palju kasutajaid kasutavad samaaegselt NAVi?
2. Kui palju müügiarveid ja ostuarveid konteeritakse?
3. Kas konteeritakse massiliselt muid dokumente (üleviimiskorraldusi, tarnekinnitusi, rendilepinguid)?
4. Kui palju tekib kandeid?
5. Kas ketastel on piisavalt ruumi andmebaasi mahutamiseks?

Aeg, mis investeeritakse enne arenduste algust nõuetekohase riistvara ja tarkvara ülesseadmisele on targalt investeeritud. Hiljem kui süsteemi on tehtud arendusi ning seda kasutavad pidevalt konsultandid/arendajad, siis riistvara ja tarkvara uuendamisele kuluv aeg on mitmekordne. Seega oleks soovitus majandustarkvara arenduse algfaasis vaadata üle tootjate poolsed nõuded ning selle järgi võtta kasutusele riistvara ja tarkvara.

Microsoft on Dynamics NAV riistvarale seadnud miinimum nõudmised. Tingimused kehtivad standardse NAVi lahenduse puhul, kuid iga süsteemi täpsed vajadused selguvad täpsema analüüsi käigus.

Tarkvara nõuded

Tarkavara puhul räägime peamisel kahest rakendusest – Windows server, SQL server. Kasutada tasuks uuemaid versioone kuna need versioonid on uuendatud Microsofti poolt, vastavalt Dynamics NAV versioonide vajadustele.

 Seadistused andmebaasile

Majandustarkvara üks tähtsamaid komponente on andmebaas. Selleks, et juba algfaasis tagada andmebaasile hea tervis tuleb silmas pidada mitmeid tähtsaid seadistusi. Üks tähtsamaid soovitusi on paigutada andmed (Data), logid (Logs) ja varukoopia (Backup) kõik eraldi ketastele. Varukoopia võiks lisaks teatud regulaarsusega kopeerida mõnele välisele andmekandjale nagu OneDrive või muule virtuaalsele kettale, mis pole kuidagi seotud majandustarkvaraga.

Ettevõtte sujuvaks tööks on vajalik, et ketastel on piisvalt ruumi ning andmebaas täis ei saaks. Esmapilgul võib tunduda, et SQL andmebaasi maht saab täis aga pole vaja muretseda, sest niikaua kui on kõvakettal ruumi ei saa SQL andmebaas täis. SQL serveri seadistuses on andmebaasi selline mõõdik nagu Inital Size . Artikli alguspooles mainitud reaalse tööolukorra jõudluse analüüsi käigus tekib ka ettekujutus kui palju võiks andmeid tekkida reaalses olukorras esimese aasta jooksul. Tekkiva mahu väärtus tulebki lisada Inital Size väljale.

Lisaks on SQL andmebaasis selline funktsionaalsus Auto-Grow. Standardis on selle väärtuseks 10%, mis tähendab, et SQL andmebaasi Inital Size hakkab täis saama siis suurendatakse seda 10% võrra. Aga just see andmebaasi suurendamise tegevus võtab ära palju jõudu ning kasutajatel võib tekkida tunne, et NAVi töötab aeglaselt. Auto-Grow funktsionaalsust ei ole mõttekas kasutada pidevalt andmebaasi suurendamiseks, kuna siis pole teada millal ta käivitub ning, kuidas see mõjub kasutajakogemusele. Soovitatud praktika on selline, kus ettevõte ise suurendab andmebaasi Initial Size väärtust korra 1-2 kuu jooksul vastavalt eeldatavale lisanduvale mahule ning  Auto-Grow funktsionaalsust kasutataks nn.turvavõrguna olukordades, kus ootamatult on vaja andmebaasi salvestada suuri andmemahte.

Nüüd läheb jutt tehnilisemaks aga seda juttu ei saa ka kirjutamata jätta kuna need seadistused mõjutavad jõudlust märkimisväärselt. Nimelt tuleb paika panna  SQL serveri seadisused Max. Degree of Parallelism ja Cost Threshold for Parallelism. Need kaks seadistust määravad ära, milliste päringute puhul SQL server hakkab endale juurde otsima ajujõudu ehk lisaprotsessorit, et tagada minimaalne ajakulu.

Standardis on seadistus:

• Cost Threshold for Parallelism = 5

See tähendab, et kui mõne päringu osa teostamise kulu (Cost) on rohkem kui 5% ühe protsessori jõudlusest, siis otsitakse appi teine samasugune. Võib oletada, et enamus päringuid ületavad 5% jõudluse piirmäära. See tähendab aga, et enamuse päringute puhul kulutatakse jõudu selleks, et otsida päringu teostamiseks teine/kolmas/neljas jne. protsessor. Kui päring on teostatud siis tuleb erinevate protsessorite andmed sünkroniseerida.

• degree of parallelism = 0

Selline seadistus tähendab, et kasutada võib kõiki saada olevaid protsessoreid. Kui näiteks on süsteemis 16 protsessorit, siis jagatakse suuremaid päringuid 16-neks ning pärast pannakse need uuesti kokku. Selline pidev „üksteise abistamine“ aga mõjub päris tugevalt jõudlusele.

Soovituslik seadistus oleks

• Cost Threshold for Parallelism = 50
• degree of parallelism = 5

Soovituslik Cost Threshold for Parallelism väärtus tähendab seda, et kui mõne päringu osa teostamise kulu (Cost) on rohkem kui 50% ühe protsessori jõudlusest, siis otsitakse appi teine protsessor.

Soovituslik Max.degree of parallelism väärtus 5 tähendab seda, et kui mõne päringu osa teostamise kulu (Cost) on rohkem kui 50% ühe CPU jõudlusest, siis otsitakse appi maksimaalselt 5 CPU-d.

Hea tava kohaselt seadistatakse esmajärjekorras tööle andmebaasi varunduse loogika, et tehtud tööd kaduma ei läheks. Arendusfaasis pole vast mõttekas teha varukoopiat igapäevaselt kuid korra kuus on tark teha koopia andmebaasist mõnele välisele andmekandjale.

Juba töötava majandustarkvara puhul on tavapraktika teha varukoopia igapäevaselt. Ja ettevõtetes, kus tehinguid on palju tehakse ka muudatuste (differential) varukoopiaid ning logide varukoopiaid. Ehk siis vastavalt äriloogikale tuleks valida varunduspoliitikaks, kas Simple või Full.

Jõudluse kontroll pärast Go-Live

Nüüd, kus andmebaasi ja servereid kasutab palju rohkem kasutajaid kui arendamise faasis, tuleks üle vaadata elutähtsate toimingute teostamise kiirus.

Tavaolukorras tehakse majandustarkvaras üks tehing või päring ära millisekundite jooksul. Enne Go-live  tegeleb lahenduse väljatöötamise ja testimisega maksimaalselt 10 inimest ja need ka mitte korraga ning nad kasutavad erinevaid tüüpi ühendusi andmebaasiga. Seega jõudluse probleeme tõenäoliselt ei ole. Reaalses elus võib aga tekkida hoopis teistsugune olukord.

Näiteks ühe müügiarve konteerimisel tekib vähemalt 10 erinevat rida NAVi erinevatesse andmikesse. Kui nüüd sada müügiinimest korraga konteerivad arveid, siis korrektselt seadistamata ja hooldamata majandustarkvaras võib pooltel müügiinimestel konteerimine võtta märkimisväärselt rohkem aega.

Miks? Põhjuseid võib olla mitmeid, näiteks see, et ühe instantsi (lihtsustatult: instants on uks mille kaudu kasutajad käivad andmebaasis) kaudu saab korraga ilma tõrgeteta andmebaasi kasutata 40 kasutajat. Kui tuleb ukse taha 41-nes kasutaja siis tema jääb ootele või proovib ennast kuidagi läbi ukse suruda. Või siis võrguühendus on liiga aeglane, või serveril pole jõudu nii paljude tehingutega samaaegselt tegeleda, tarkavara (SQL või NAV) vaikeseadistused pole sellise äriloogika jaoks sobivad või hoopis midagi muud.

Vastavalt äriloogikale, kas kasutajate arv on 20, 50 või 250 tuleks seadistada instantside kasutajad. Hea tava on erinevatele osakondadele teha erinevad instantsid. Sellisel juhul on lihtsam avastada jõudluse probleeme NAVi funktsionaalsustes ning kasutajate arv ühe instantsi peal ei ületa soovituslikku väärtust.

Ühe instantsi peale on soovitus töötama panna kuni 50 kasutajat. Ning Dynamics NAV seadistuses panna Max. concurrent Connections väärtuseks 150, mis näitab mitu ühendust ühe instansti pealt saab korraga NAVi ja SQLi vahel luua.

Lisaks tuleks üle vaadata seadistus Max. concurrent Calls, mille väärtus peaks olema 40. Selle seadistuse mõte on selles, et maksimaalselt 40 kasutajat saavad korraga ühe instantsi kaudu NAVi kasutada. Eelnevalt oli soovitus ühe instantsi peale panna 50 kasutajat aga selle seadistuse järgi saab neist ainult 40 kasutajat korraga NAVi kasutada. Siin on tehtud arvestus, et kõik kasutajad ei kasuta NAVi kogu aeg.

Veel üks natuke tehnilisem seadistus on Metadata Cache size. Standardis on seadistuseks 150. See seadistus näitab, mitut NAVi objekti võib samal ajal kasutuses olla. Näiteks müügiarve konteerimisega on kasutuses u. 10 objekti siis kui NAVis tegutsevad aktiivselt 100 kasutajat siis on juba suur tõenäosus, et eelmainitud seadistus võib tekitada jõudluse probleeme.

Soovituslik seadistuse väärtus on 5000, mis isegi mitmesaja kasutajaga NAVi puhul ei hakka piirama kasutamismugavust ja majandustarkvara toimimise kiirust.

Andmebaasi regulaarne hooldus pärast Go-Live

Umbes üks aasta pärast majandustarkvaraga töötamist tuleks teostada jõudlust mõjutavate teemade analüüs. Analüüsis tuleks kindlasti vastata neile alljärgnevatele küsimustele:

• Kas kettaruumi on piisavalt ja mitmeks kuuks veel kettaruumi jätkub?
• Kui tihti käivitub andmebaasi Auto-Grow? Kas seadistus on piisav? Kui tihti käsitsi andmebaasi suurendatakse?
• Kas DBCHECK, REINDEX/REBUILD funktsioonid töötavad ehk kas on tööle seadistatud Hoolduspakett?
• Indeksite olemasolu ja millistel tabelitel on üldse indekseid vaja
• Kas varukoopia teostatakse edukalt ja kas varukoopia failis saab reaalselt töötava andmebaasi (test-backup)

Enamus juhtudel pole hooldatud andmebaasi puhul vaja väga palju muretseda. Aga kui ikkagi on näha, et majandustarkvara kiirus hakkab vähenema siis tuleks ette võtta täpsem jõudlusanalüüs. Sellisel juhul võetakse kasutusele raskekahurvägi – SQL Profiler. SQL profilerist kirjutame aga juba järgevates artiklites.