PAL si MOSS Performance Load Tests – sau webfarm performance testing I

 

Dezvoltarea unei aplicații MOSS 2007 presupune planificarea resurselor alocate, numărul de servere, echipamentele hardware, echipamentele de stocare, spargerea rolurilor in funcție de dimensiune, profilul aplicației, numărul utilizatorilor s.a.m.d. De multe ori am observat ca se trece peste o etapa destul de esențiala in dezvoltare si anume testarea performantei. Exista multe resurse atât pe site-ul Microsoft dar si multe bloguri care fac referința la planificarea unui deployment si partea de sizing, însa chiar daca acestea sunt respectate de multe ori se trece peste partea efectiva de testare. Testarea ne poate confirma corectitudinea calculelor noastre si ne poate arata scăpările sau “bottleneckurile” existente in design. Exista multe referințe despre load testing si analiza performantei, una dintre ele fiind : Estimate performance and capacity requirements (Office SharePoint Server) document care îl putem folosi drept referința in testele noastre.

• Estimate performance and capacity requirements for Windows SharePoint Services collaboration environments (Office SharePoint Server)

• Estimate performance and capacity requirements for portal collaboration environments

• Estimate performance and capacity requirements for search environments

• Determine resource requirements to support Excel Services

• Estimate performance and capacity requirements for Internet environments (Office SharePoint Server) .

• Performance and capacity requirements for Hyper-V

Din pacate insa etapa de load testing si analizarea rezultatelor se realizează de multe ori doar in companii specializate in livrarea de soluții MOSS, unde exista atât resursa umana necesara dar si cunostiintele pentru a putea formula scenarii de test si analiza rezultate lor. Liam Cleary [SharePoint MVP] are o serie de articole foarte interesante despre Visual Studio Team Suite Edition si load testing pentru MOSS (http://www.helloitsliam.com/archive/tags/Testing/default.aspx) si chiar recomand la toata lumea sa arunce o privire,  insa ce putem face daca nu avem la dispozitie resursele necesare pentru testarea performantei, a scalabilitatii si identificarea potențialelor probleme?

Cea mai la indemana soluție ar fi sa folosim  MOSS Performance Load Tests disponibile împreuna cu SharePoint 2007 Test Data Population Tool pe codeplex. Pentru analiza rezultatelor putem folosi PAL. Despre PAL am mai scris in posturile anterioare astfel incat nu voi intra in detaliu despre ce poate face, denumirea fiind concludenta ( Performance Analysis of Logs ).MOSS Performance Load Tests va simula load-ul a 50 de utilizatori si permite atat efectuarea de actiuni mixte (read and write) sau doar simple (read).

Visual Studio Team Suite Edition  ofera multe facilitati pentru testare inclusiv utilizarea si masurarea counterelor in timpul run-ului insa in situatia de fata vom utiliza PAL pentru analiza. Putem folosi atat counterele care vin cu testul cat si analiza logurilor din perfmon ulterior.

Pentru configurarea counterelor pe care apoi le vom urmări in timpul run-ului vom edita fișierul de threshold din PAL (MOSS 2007) lasand doar componentele necesare pentru serverul respectiv si vom crea cate un Threshould pentru fiecare rol de MOSS instalat (FrontEnd, SQL Server, Index, Search Server, etc).

 

Odata definite fisierele pentru serverele din ferma, le exportam  ca templateuri pentru a le putea apoi importa in perfmon.

Daca avem MOSS instalat pe Server 2008 pentru a putea importa fisierele de tip html va trebui sa facem cativa pasi suplimentari (Server 2008 necesita fisiere template in format xml nu html.)  Va trebui sa importam template-ul pe o masina cu Server 2003 iar de pe severul MOSS va trebui sa rulam 

 logman query -s <server2003 machine mane>

 

pentru a afisa lista cu counterele importate , iar apoi :

logman export -n "MOSS counter log name" -xml mossDB.xml -s <server2003 machine mane>

 

Odata importate fișierele care conțin counterele dorite, următorul pas va fi configurarea masinii de test care ne va genera activitatea.  Configurarea si rularea testului precum si analiza rezultatelor le voi acoperi insa intr-un post viitor.

Cum diagnosticam problemele de performanta V

PAL – sau cum luam pulsul unui sistem

 

In ultimele posturi am tot descris countere si cum  ele ne pot prezenta o imagine de ansamblu asupra potențialei problemei, analizând simptomele, corelând valori ale mai multor countere si trăgând o concluzie.  Insa de multe ori avem nevoie de o analiza mai detaliata întinsa pe o perioada mai lunga de timp (zile, saptamani sau chiar luni) pentru a trage o concluzie. E clar ca in astfel de situații nu ne mutam la servici deschidem perfmonul si încercam sa urmarim valorile. Avem nevoie de o metoda mai eficienta pentru a putea analiza logurile de performanta. Poate cel mai bun instrument pentru analiza este PAL (Performance Analysis of Logs)

Pentru a utiliza PAL aveti nevoie de Log Parser 2.2 care va parsa logurile  si Microsoft Office Web Components 2003 pentru a genera grafice. PAL poate fi descarcat de pe codeplex, la fel ca si documentatia de utilizare.

PAL folosește ca imput pentru analiza fișiere XML (Threshold files) unde ne putem defini toata logica de analiza si expertiza pe care o avem. Folosind GUI-ul putem chiar crea fisierele de analiza, utilizând cunostiintele pe care le avem si particularitatea aplicației pe care o vom analiza.

Revenind la discutia inițiala, PAL ofera posibilitatea de a exporta in format HTML lista cu countere pentru ca apoi, sa putem înregistra datele in perfmon  folosind un counter log pentru a lua masuratori. Pentru a importa fisierul, din meniul Actions alegem optiunea “New Log Settings From” si selectam fișierul exportat.

Va trebui totusi sa fim foarte atenti in momentul stabilirii duratei dintre masuratori. Valoarea implicita este de 15 secunde insa de obicei este bine sa o marim la 30 secunde, 1 minut sau chiar mai mult, in special deca avem un numar mare de countere si dorim sa analizam o perioada mai îndelungata. Multi pot cadea in capcana de a captura cat mai multa infomatii stabilind un interval foarte mic, insa sa nu uitam ca luarea de masutatori consuma resurse si sub nici un caz, o masuratoarea nu ar trebui sa creeze spike-uri in CPU mari astfel riscam ca analiza sa nu fie valida. La fel daca dimensiunea logurilor va fi foarte mare  generarea raporatelor poate dura destul de mult si exista riscul ca scriptul VB din spate sa nu faca fata. Scopul nostru in analiza nu este de a prinde toate spike-urile ci de stabili trenduri si a studia valorile medii pe perioade cat mai semnificate pentru problema pe care o analizam.

Pentru a realiza analiza va trebui sa pornim interfața de PAL, iar apoi vom selecta logul pe care dorim sa-l analizam si intervalul de analiza. Urmatorul pas consta in algerea fisirului de configurare pentru analiza (Threshold file). GUI-ul va genera un o comanda care va apela scripul de analiza (un script VB) trimițândui  parametri stabiliti.

Scriptul va analiza logurile si pe baza fișierului de analiza, va construi un raport cu analiza counterelor selectate si afișând alerte daca valorile definite vor fi atinse.

PAL ofera o modalitate foarte eficienta de a lua “pulsul” unui sistem si de a ne oferi indicii cu privire la bottleneck-urile de pe sistem. PAL mai ofera, in afara posibilitatii de a ne defini fișierele de configurație aplicate specificului aplicatiilor analizate, o serie de configurari predefinite care ne pot ajuta sa luam pulsul pentru SQL Server, IIS, Project Server, Hyper-V, Exchange, Biztalk, AD sau Sharepoint.

Powershell in ajutor – delogare

 

Astazi am fost nevoit la servici sa-mi schimb parola ca la fiecare 3 luni. Bun pana aici nici o problema insa cum am un obicei prost de ma loga pe masini si a ramane logat acolo, cam din ora in ora contul meu era blocat. Enervat am deschis putin powershell-ul si m-am apucat sa-mi scriu o functie care sa ma delogheze de pe toate masinile.

001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 019 020 021 022 023 024 025 026 027 028 029 030 031 032 033 034

#Usage: #.\LogOffMachinesTextImput.ps1 “servers.txt” “numedomniu\numeutilizator” #Requires PowerShell Community Extensions (http://www.codeplex.com/Pscx) Param($file,[string]$user,[switch]$verbose) if($verbose){$VerbosePreference = “Continue”} if(!(test-path $file)) {    throw ” File NOT found!”    return } Get-Content $file | Foreach-Object {    #write-Host “Get-TerminalSession -ComputerName $_”    $computer = $_    #write-Host $computer    Get-TerminalSession -ComputerName $computer | foreach-Object {                          if($_.UserName -eq $user )          {          Stop-TerminalSession -ComputerName $computer -ID $_.Id                               write-Host ” Using Computer: $computer “          write-Host ” Disconecting user $user from Machine $computer”         }    else {write-Host “User $user not connected on machine: $computer” }   }  }

Cum diagnosticam problemele de performanta IV

CPU

Cand vorbim despre cauzele performantei scazute primul gand, ne zboara spre resurse hardware insuficiente, insa de multe ori cauzele sunt foarte variate si solutiile la fel de variate. Pentru a ajunge insa la cauze trebuie sa analizam efectul iar apoi pe baza informațiilor vom trage o concluzie. Sunt multe situații cand planificarea corecta in funcție de particularitățile aplicației ne scutește de astfel de probleme, sunt situații când un Bug in aplicație ne da totul peste cap sau sunt situații când fie trebuie sa aplicam un update, un hotfix sau un workaround pentru a rezolva problemele. Indiferent de rezolvare va trebui sa identificam simptomele si cu ajutorul lor sa punem un diagnostic problemei.

Revenind la subiectul principal si anume cum colectam date despre CPU pentru a obține informații mai clare despre simptome, încercând pe baza acestor date sa gasim vinovatul problemei sau macar sa restrângem aria de căutare a problemei.

Perfmon ne pune la dispoziție ca pentru toate componentele o serie de countere pe care le putem observa pentru a identifica o potențiala problema a carei actiuni se regăsește si la nivelul CPU-ului:

• Processor\% Processor Time – reprezintă procentul din timp in care nu rulează thread-ul idle (este un thread care ruleaza pe fiecare procesor in momentul cand nu mai se executa nimic) si se calculează scăzând din timpul total timpul in care a rulat thread-ul Idle.In general trebuie sa urmărim daca valoarea de utilizare a procesorului depaseste 60% utilizare constanta, iar apoi sa observam unde petrece cea mai mare parte din timp (user mode sau kernel mode). Daca petrece majoritatea timpului in user mode va trebui sa analizam fiecare process in parte si mai departe cu un profiler dupa ce identificam procesul. Daca in schimb petrece cea mai mare parte din timp un kernel mode probabil exista un alt motiv iar activitatea intensa din CPU este doar un efect. In kernel mode se executa funcții de sistem (disc I/O, memorie, rețea, etc.)
• System\Processor Queue Length – reprezintă numărul de fire de execuție (thread-uri) aflate in coada procesorului. Pentru sisteme multiprocessor sau multicore va trebui sa impartim valoarea la numarul de core-uri de pe sistem. In general in fuctie de nivelul de procesare o coada o coada cu peste 10 fire de executie care asteapta in medie pentru perioade prelungite corelata cu timpul in care executa fie in kernel mode sau user mode ne poate duce la concluzia daca performanta sistemului va beneficia prin cresterea puterii de procesare. Sau se poate reduce numarul de fire de executie care asteapta sa fie rulate pe processor la nivelul aplicatiilor care ruleaza pe sistem.
• Processor ()\% Privileged Time – timpul pe care procesorul il petrece executand in kernel mode, executand operatii la nivel de sistem cum ar fi functii de disc I/O , network I/O sau alocare de memorie, spe exemplu. Utilizarea excesiva a procesorului in kernel mode, sugerează o posibila problema la nivelul memoriei, discului sau a retelei care cauzeaza activitatea ridicata la nivel de sistem, determinantul  sa petreacă foarte mul timp deservind I/O la nivel de sistem, ramanand mult mai putin timp alocat executiei aplicațiilor in user mode.
• System\Context Switches/sec – devine o problema daca este corelat cu utilizarea ridicata a procesorului in kernel mode si un nivel ridicat de utilizare in general. Context switching se petrece atunci cand un fir de execuție cu o prioritate mare opreste execuția unui fir cu o prioritate mai mica sau cand schimba intre executia in user mode si kernel mode. Valoarea de unde trebuie sa fim atenti este peste 15,000 pe secunda ar trebui sa ne puna in garda. In general un numar mare de fire de executie care schimba contextual intrand in kernel mode are la baza o problema legata de I/O unde ar trebui sa mergem mai departe pentru a gasi problema reala.
• Process (*)\% Processor Time – ne arata cat timp din procesor consuma fiecare process in parte. Daca suspectam un bottleneck pentru executia in user mode, putem identifica procesul care consuma excesiv de mult si apoi putem folosi un profiler pentru a analiza procesul respective.
• Processor\% Interrupt Time – indica timpul pe care procesorul il petrece pentru a primi si deservi întreruperi hardware la intervalele prestabilite. In general dispozitivele care genereaza intreruperi sunt mouse-ul driverele pentru disc, ceasul de sistem, NIC-urile sau alte dispozitive periferice. De obicei dispozitivele respective întrerup firul normal de execuție a procesorului cand fie au terminat un task sau necesita atenție. O creștere dramatica a valorii counterului ne sugerează o potențiala problema hardware.

Cum diagnosticam problemele de performanta III

Disc

Cele mai dese bottleneck-uri intalnite, in contextul actual, sunt cele legate de disc si I/O, in special in aplicatii care citesc sau scriu intensiv pe disk (SQL Server, Exchange,etc). Evoluția calculatoarelor a ajuns intr-un punct unde subansamblul de disc este cea mai înceata componenta dintr-un sistem. Daca vrem a face o comparație, latenta pentru diskuri in situații ideale este undeva la 10-15 milisecunde in timp ce pentru RAM este la 5 nanosecunde (de 2000 – 3000 ori mai rapide). De multe ori se ajunge la saturarea SAN-urilor in special de aplicații care utilizează intens I/O,  fie din cauza saturației discului  in special când aplicația nu are exclusivitate pentru LUN si intervine concurenta foarte mare pentru I/O (virtualizarea este un exemplu unde acesta problema este foarte comuna).  Am observat chiar si in producție datorita paginării si concurentei I/O ajungerea chiar si la valori peste 1 secunda (latenta pentru un floppy disk este sub 900 milisecunde). In special aplicații care consuma mult I/O gen SQL Server, Exchange, SharePoint vor trebui planificate corespunzător din punctul de vedere al accesului la sistemul de disc pentru a obține un nivel optim de performanta. Dar sa revenim la metodele disponibile pentru analiza performanta diskului. Perfmon ne pune la dispoziție multe countere adresate monitorizării discului dar in majoritatea situațiilor sunt 6 countere de care trebuie sa ținem cont in orice situație:

• LogicalDisk\% Free Space – masoara procentul de spațiu liber disponibil pe discul logic selectat. In general daca acesta scade sub 10% avem spatiu insuficient disponibil pe disk si e posibil sa afecteze nivelul de performanta al OS-u,l acesta nemaiavând spațiu pentru a fișierele critice. Valabil in special pentru discul logic unde se afla OS-ul
• PhysicalDisk\% Idle Time – masoara procentul de timp in care discul nu era folosit in intervalul monitorizat. Recomandarea spune ca daca valoarea scade sub 20% diskul este saturat si ar trebui înlocuit cu un disk mai rapid.
• PhysicalDisk\Avg. Disk Sec/Read – masoara timpul mediu in secunde pentru a citi date de pe disk. Daca valoarea este mai mare de 25 milisecunde , atunci diskul are probleme de latenta in momentul citirii de pe disk . Pentru LOB servere cum ar fi SQL Server sau Exchange valoarea maxima scade la 10 ms.  Daca trece de 50 milisecunde nu e bine.
• PhysicalDisk\Avg. Disk Sec/Write – masoara timpul mediu in secunde pentru scriere pe disc . Madia va trebuie sa fie pana in 25 ms, iar daca depaseste 50 milisecunde aven o problema care trebuie investigata. Pentru servicii LOB valoarea acceptata este de aproximativ 10ms.

 

• PhysicalDisk\Avg. Disk Queue Length – masoara cate operații I/O așteaptă pentru ca discul sa devina disponibil. Daca valoarea depaseste de doua ori numărul de diskuri din array (daca avem un singur disk valoarea nu ar trebui sa depaseasca 2 operatii care sa astepte in caoda) putem lua in calcul o problema legata de performanta discurilor si va trebui sa intram mai mult in detaliu privind o potentiala problema.
• Memory\Cache Bytes indica cantitatea de memorie folosita de cache-ul din sistem. Putem considera o problema daca valoarea depaseste 300MB.

 

Cum diagnosticam problemele de performanta II

Am vorbit in postul trecut despre informațiile pe care perfmon le oferă, incepand cu momentul deschiderii lui si cum putem observa o problema utilizând cele trei countere afisate la pornire. Insa tot in acelasi post spuneam ca niciodata nu ar trebui sa luam o concluzie doar pe baza unui counter. Asadar vom incerca sa le analizam pe rand, incepand cu problemele legate de memorie. Mentionam in postul anterior ca peste 1000 de Pages/sec , valoare prezenta o durata îndelungata, ne sugerează o presiune la nivel de memorie care ar trebui investigata pentru aflarea cauzei reale si cum poate fi rezolvata. Ar mai trebui precizat ca de multe ori datorita scrierilor intense de page files mai devreme sau mai târziu vom observa si un botleneck la nivelul diskului, insa el trebuie analizat in concordanta cu counterele de memorie pentru ca de multe ori este un efect al lipsei de memorie. Un alt lucru de care trebuie sa tinem cont cand spunem monitorizarea counterulul pe o durata mai indelungata este eliminarea varfurilor (perioadele scurte cand valoarea counterului creste exponențial )

Cand analizam problemele legate de memorie trebuie sa avem in vedere doua componente: user space memory and kernel (system) space memory.

Pentru user space memory avem doua countere care trebuie sa ne intereseze in mod special. Primul este Memory\Pages/sec despre care am discutat in postul anterior (Probleme apar la peste valori peste 1000 intr-o perioada îndelungata de utilizare). Al doilea counter de interes este Memory\Avaible Mbytes(MB). Acesta indica memoria fizica imediat disponibila in vederea alocării spre un proces sau pentru sistem. In mod normal ar trebui sa existe cel putin 50 MB memorie imediat disponibila in orice moment.  Utilizand ambele countere putem trage o concluzie privind limitarea memoriei, Pages/sec fiind inselator iar manifestari pot aparea in mai multe situatii in special pentru programe care utilizeaza in mod intensiv memoria gen SQL Server unde presiunea ar putea fi datorita memoriei alocate per instanta sau Exchange.

Pentru componenta referitoare la memoria de sistem avem:

Memory\Pool Paged Bytes fiind portiunea din memorie partajata care poate fi paginate in fisierul de paginare din windows. Paged Pool este creat la initializarea sistemului fiind folosit de componentele care rulează in modul sistem pentru alocarea memoriei.

Memory\Pool Nonpaged Bytes sunt adresele virtuale păstrate in memoria fizica care pot fi accesate de la oricare spatiu de adresare virtual fara a folosi paging de pe disk. La fel este si ea initializata la startup si este folosita de componentele sistem pentru alocarea memoriei de sistem.

Memory\Free System Page Table Entries * Adresele in memoria virtuala ale fișierelor de paginare sunt mapate la memoria fizica folosit System Page Table. Aplicațiile vor folosi apoi acest PTE pentru a mapa aceste sistem pages.

Valorile pentru cate trebuie sa fim atenți la memoria sistem sunt descrise cel mai bine in următorul tabel (tabel disponibil pe technet intr-o forma mai detaliata)

Memoria de sistem	Performance Monitor counter	Valorile din Performance Monitor in configurarea predefinita	Valorile din Performance Monitor cu opțiunile din  boot.ini configurate ( /3GB si /USERVA = 3030 )
Paged Pool	Memory\Pool Paged Bytes	·        Valoare depaseste 320 MB	·      Valoare depaseste 220 MB
Nonpaged Pool	Memory\Pool Nonpaged Bytes	·      Valoare depaseste 220 MB	·    Valoare depaseste 110 MB
System PTEs	Memory\Free System Page Table Entries *	·      Valoare este mai mica de 5,000	·     Valoare este mai mica de 5,000

Utilizând aceste valori putem diagnostica o posibila problema la nivelul memoriei si putem lua astfel o decizie legata de cantitatea de memorie alocata sau alocarea ei către aplicații. Ar mai trebui zis ca pe sisteme x64 optiunile din boot.ini descrise nu isi mai au rostul programele putand beneficia de mai mult de 2 GB memorie alocata per proces.

Voi continua in urmatorul post analiza counterelor de baza analizand eventualele probleme legate de disk.

Cum diagnosticam problemele de performanta I

Mai mult ca sigur fiecare dintre noi si-a pus măcar odată întrebarea de ce merge serverul nostru așa de greu sau de ce aplicația noasta se mișca încet. Desigur exista întotdeauna problema calitatii codului scris si cum poate fi optimizat însa tot la fel de des performanta se oprește intr-o limitare a resurselor hardware disponibile pe mașina. Întrebarea este însa, cum ne dam seama, cum putem afla unde este problema ?

Windows pune la dispoziție o unealta ideala pentru diagnosticarea astfel de probleme: perfmon sau mai bine zis Peformance Monitor.

Din momentul deschiderii, Perfmon ne oferă un diagnostic in timp real asupra ce se întâmpla la nivelul OS-ului având trei indicatori porniți:

• Pages/sec indica rata la care sunt scrise sau citite “paginile” de pe disk ( “hard page faults”) altfel zis datele care nu exista in memorie si trebuie incarcate din pagefiles aflate pe disk. Ideea cu acest counter este următoare: cu cat este mai mica valoarea cu atât este mai bine neavând presiune asupra memoriei iar mașina se mișca bine. Insa când valoarea creste si avem peste 1000 pages/second avem o problema. Sigur ca nu putem trage o concluzie doar pe baza acestui counter însa depășirea acestei valori in general ne spune ca avem o problema legata de memorie care ar trebui investigata înainte sa aruncam banii pe mai mult RAM.
• Avg. Disk Queue Lenght este un counter pentru monitorizarea diskului  luând masuratori de I/O la nivelul ansamblului de disk. Acest counter este de fapt o medie dintre timpului mediu de răspuns al dispozitivelor care alcătuiesc ansamblul de disk si rata I/O. El estimează numărul de cereri neprocesate adresate diskului la nivelul logic sau fizic. Acestea includ cererile care sunt momentan efectuate la nivelul dispozitivului la care se adăuga cererile care așteaptă accesul la dispozitiv. In general putem estima o problema la nivelul diskului daca counterul depaseste valoarea 2 pentru perioade extinse de timp (minim 15 minute) pentru fiecare disk din ansablul de diskuri. Partea interesanta pentru ansamblele de disk configurate in array este ca valoarea pe care PerfMON o afișează va trebui impartita la numărul de diskuri din Array înainte de a trage o concluzie (se poate discuta si aici mai ales daca avem SQL Server instalat pentru ca sunt multe variabile, însa impartirea la numarul de diskuri este in general valabila) Spre exemplu daca avem un sistem RAID 5 cu 5 diskuri iar Avg. Disk Queue Length este 9 atunci valoarea reala a acestui counter este 1.8, sub valoarea recomandata de 2 per disk fizic.
• % Processor Time determina procentul de timp in care procesorul este ocupat calculanduse ca diferența dintre perioada de timp in care rulează thread-ul procesului Idle  si scăzând valoarea din 100. In general ar trebui sa ne punem un semn de întrebare când utilizarea procesorului depaseste 70-80 % pentru perioade îndelungate de timp, însa nu întotdeauna procesare crescuta arata o problema reala.

Perfmon ne poate oferi destul de multe informatii despre condiția sistemului nostru numai deschizândul si aruncând o privire pe cele trei countere. Însa ca orice lucru in analiza performantei acestor countere, singure nu ne spun mare lucru exceptând poate un semnal de alarma in zona respectiva unde am putea avea o problema, reala sau doar de moment. Ca reguli de baza in monitorizarea stării  unei mașini  trebuie insasi sa reținem ca nici un counter nu ar trebui luat izolat pentru a formula o concluzie. 

In următoarele posturi voi merge puțin mai departe si vom discuta mai in detaliu despre counterele de care avem nevoie pentru a ne forma o părere corecta despre starea unei mașini si cum putem crea rapoarte pe baza acestor date.