1. Arvutisüsteemi kui terviku analüüs.
Arvutisüsteem koosneb erinevatest serveritest, serveri
tarkvarast ja lõppkasutajatest
Serveriteks on andmebaasi serverid, webiserverid,
rakendusserverid.
Kus igasühes jookseb teatud ülesandega tarkvara.
Tavaliselt on eraldi andmebaasiserver + rakendusserver +
kliendid.
See on süsteemi tavapärane süsteemi ülesehitus.
Nüüd kui süsteem on aeglane, siis kust otsida põhjust?
Kui üks firma haldab riistvara ja teine firma tarkvara ,siis
tihti ei suuda firmad omavahel koostööd teha, et saaks kiirelt öelda milles asi.
Põhjuseks on see, et ei leidu mitte ühtegi inimest kes
suudaks hallata süsteemi kui tervikut – lähtuvalt kõigest olemasolevast
informatsioonist.
Et süsteemi tervikuna mõista tuleb tunda ettevõtte
äriloogikat, kuidas ettevõte töötab, mis programmid on olemas,
andmebaasi tabelite maht ja struktuur, kasutajate
probleemid, ettevõtte kui süsteemi toimimine läbi infotehnoloogia.
Lisaks ettevõtte kui süsteemi terviku tundmisele on vaja
tunda ka erinevate tasandite arvutisüsteeme:
Riistvara monitoorimine(protsessori kasutus, mälu kasutus)
Andmebaasi monitoorimine(SQL per sec, mälukasutus)
Rakenduse sisemine monitoorimine(kävitatavate meetodite
logi).
Inimene kes valdab süsteemi kui tervikut, on suuteline igal
tasandil looma monitooringusüsteemi ja seda infot kasutades kiirelt jõudma
probleemi tuumani.
Probleemiks on kõige tavapärasemalt tähtsusjärjekorras:
1.1. Halvasti kirjutatud SQL-id
1.2. Halvasti optimeeritud andmebaasi indeksid.
1.3. Halvasti kirjutatud algoritmid
1.4. Ei ole osatud õieti konfigureerida keerukat süsteemi
ORACLE, rakendusserveri tasemel(mälukasutus, erinevadtoimimise parameetrid)
1.5. Riistvara on valesti installeeritud või vigased
draiverid, mis tõttu esineb aeglustavaid kõrvalmõjusid.
2. Süsteemi analüüs ja optimeerimine juhul kui rakendusi
pole võimalik muuta ja problem peitub SQL päringutes.
Sellisel juhul on vajalik läbida 10 astmeline algoritm
andmebaasi SQL päringumootori optimeerimiseks.
2.1. Teha analüüs tabelitest ja nende suurustest.
2.2. Kaardistada kõik indekseeritud väljad ning
indekseeritud väljade kombinatsioonid.
2.3. Panna peale logi, et pildistada kõik ühe
aruandlusperioodi(kuu/nädal) jooksul toimunud SQL-id.
2.4. Teha kõikide SQL-ide kävitusplaanide(execution plan)
analüüs.
2.5. Teha kõikide SQL-ide indeksikasutuse analüüs.
2.6. Lähtuvalt eelnevast infost on võimalik välja uurida iga
tabeli jaoks optimaalseim arv indekseid ning indeksitekombinatsioonid.
2.7. Kustutada üleliigsed indeksid ning olemasolevatele teha
rebuild ja analyze(ORACLE)
2.9. Optimeerida VIEW-des olevate SQL-ide kävitusplaanid.
2.10. Ära optimeerida ka Stored Protseduurides olevad
SQL-ide kävitusplaanid SQL-i vajadusel SQL ringikirjutades.
Tehes läbi sellise analüüsi on tavapärane tulemus 4-10 korda
kiirema infosüsteem.
3. Süsteemi analüüs ja optimeerimine juhul kui on võimalik
rakenduse algtekste muuta.
3.1 Vajalik on ehitada monitooringusüsteem, iga meetod mis
pöördub andmebaasi poole saab logitud ja näha on aegkaua selleks kulus.
3.2 Monitooringust tuleva info põhjal on võimalik käia üle
meetodite taga olev andmebaasi loogika.
Tavapäraselt n+1 probleem, ehk oskamatus kasutada SQL-i ja
tehakse selle asemel et 1 SQL niipalju SQL-e kuitulemuses ridu.
3.3 Tehnoloogia mittetundmisest tulenevad vead. Näiteks iga
webilehe peale tehakse uuesti kõigile loenditeleuuendus.
Võimalik rakendada erinevate tasemete cache, kui hibernate
pole võimalik või on väga keeruline ümber kirjutada.
3.4 CACHE süsteemide rakendamine. eKooli peale välja
töötatud cache süsteem arvestab klastritega ning andmetereaalajas muutmisega.
Info tabelite mu kohta sünkroniseeritakse andmebaasist
erinevate klaster serverite vahel.
Klasterserverite vahel käib iga 1 sec järel suhtlus muutuste
tabeli muutuste kohta.
3.5 Algoritmide valesti kasutus, tihti ei teata kõige
efektiivsemaid otsingualgoritme või kasutakse teadmatusesttehnoloogiat valesti.
Sellisel juhul tuleb iga erijuhus eraldi lahendada.
Argo Vilberg
argovilberg@gmail.com
56206727