Differences

This shows you the differences between two versions of the page.

Link to this comparison view

ep:laboratoare:05 [2017/01/16 22:41]
emilian.radoi [Monitorizare RAM]
ep:laboratoare:05 [2017/01/17 10:22] (current)
emilian.radoi [Resurse]
Line 55: Line 55:
  
    
-Inainte de a porni toolul ne ducem in Options->​Configure Symbols si punem acolo calea catre pdb-urile specifice programului nostru si respective spre serverul de simboluri Microsoft, precum si calea catre sursele programului ​nostrum.+Inainte de a porni toolul ne ducem in Options->​Configure Symbols si punem acolo calea catre pdb-urile specifice programului nostru si respective spre serverul de simboluri Microsoft, precum si calea catre sursele programului ​nostru.
  
 Se porneste toolul, selectam tabul Launch and trace a new process, selectam procesul care ne intereseaza,​ spunem care sa fie directorul de unde sa ruleze si ii dam drumul sa ruleze. O data pornit toolul o sa vedem ceva de genul: Se porneste toolul, selectam tabul Launch and trace a new process, selectam procesul care ne intereseaza,​ spunem care sa fie directorul de unde sa ruleze si ii dam drumul sa ruleze. O data pornit toolul o sa vedem ceva de genul:
Line 68: Line 68:
  
  
-Si in cazul CPU Usage avem oarecum probleme similare cu cele pentur ​memory usage. Daca vrem sa aflam consumul din acest moment de CPU al unui process, ne este de ajuns Task Manager:+Si in cazul CPU Usage avem oarecum probleme similare cu cele pentru ​memory usage. Daca vrem sa aflam consumul din acest moment de CPU al unui process, ne este de ajuns Task Manager:
  
  
Line 96: Line 96:
 Din grafice se observa impactul de vreo 12% al programului nostru. Ok, am identificat problema, am vazut cine genera consumul de CPU – acum apare intrebarea cum debugam acest lucru? La fel ca si la memory, daca nu e un process scris de noi, vedem daca ne e util, daca nu ne asiguram ca nu mai ruleaza. Daca ne e util incercam sa gasim un update pentru el in speranta ca nu se mai reproduce problema. Daca nu gasim un astfel de update raportam problem ape forumurile producatorului in speranta ca se va fixa. Dar cum la evaluarea performantelor ne intereseaza sa analizam procesele scrise de noi, o sa presupunem ca acest process, cum se si intampla de altfel, e scris de noi, si e impotant sa gasim de unde a aparut problema. Din pacate, spre deosebire de cazurile discutate mai sus, lucrurile nu mai sunt la fel de simple, neexistand un tool care sa ne dea stiva unde se genereaza problema, de data aceasta va trebui sa ne cream noi acest tool. Din grafice se observa impactul de vreo 12% al programului nostru. Ok, am identificat problema, am vazut cine genera consumul de CPU – acum apare intrebarea cum debugam acest lucru? La fel ca si la memory, daca nu e un process scris de noi, vedem daca ne e util, daca nu ne asiguram ca nu mai ruleaza. Daca ne e util incercam sa gasim un update pentru el in speranta ca nu se mai reproduce problema. Daca nu gasim un astfel de update raportam problem ape forumurile producatorului in speranta ca se va fixa. Dar cum la evaluarea performantelor ne intereseaza sa analizam procesele scrise de noi, o sa presupunem ca acest process, cum se si intampla de altfel, e scris de noi, si e impotant sa gasim de unde a aparut problema. Din pacate, spre deosebire de cazurile discutate mai sus, lucrurile nu mai sunt la fel de simple, neexistand un tool care sa ne dea stiva unde se genereaza problema, de data aceasta va trebui sa ne cream noi acest tool.
  
-Va rog sa deschideti ​ EvenimenteProcMon. Scopul programului e de a ne integra mesajele noastre cu ProcessMonitor,​ ca sa le putem vedea pe masura ce se desfasoara procesul. O sa explic un pic programul, desi nu e musai necesar ​s ail intelegeti. Ca si QA puteti cere dezvoltatorului sa integreze el cu process monitor pentru a va ptuea permite sa investigate. Dar, consider totusi ca, ca si QA e totusi nececsar sa puteti intelege orice fel de cod – nu perfect, dar macar sa aveti idee cam ce se intampla, de aceea sper sa va fie cat mai clar codul explicat mai jos:+Va rog sa deschideti ​ EvenimenteProcMon. Scopul programului e de a ne integra mesajele noastre cu ProcessMonitor,​ ca sa le putem vedea pe masura ce se desfasoara procesul. O sa explic un pic programul, desi nu e musai necesar ​sa il intelegeti. Ca si QA puteti cere dezvoltatorului sa integreze el cu process monitor pentru a va putea permite sa investigati. Dar, consider totusi ca, ca si QA e totusi nececsar sa puteti intelege orice fel de cod – nu perfect, dar macar sa aveti idee cam ce se intampla, de aceea sper sa va fie cat mai clar codul explicat mai jos:
  
 Deci, am creat o clasa ProcessMonitor,​ care are 5 functii: Deci, am creat o clasa ProcessMonitor,​ care are 5 functii:
Line 118: Line 118:
 Mai jos in cod vedeti ca am declarant global: Mai jos in cod vedeti ca am declarant global:
  
 +<​code>​
 MyProcMon __procMon; MyProcMon __procMon;
 +</​code>​
  
 Aceasta inseamna ca la pornirea procesului, inainte de executia functiei main cand se initializeaza variabilele globale, va fi construit obiectul clasei noastre si implicit deschiderea handelului peste interfata de mesaje din ProcessMonitor. Inchiderea handeului facandu-se cand se distruge obiectul, adica dupa executia programului. Aceasta inseamna ca la pornirea procesului, inainte de executia functiei main cand se initializeaza variabilele globale, va fi construit obiectul clasei noastre si implicit deschiderea handelului peste interfata de mesaje din ProcessMonitor. Inchiderea handeului facandu-se cand se distruge obiectul, adica dupa executia programului.
Line 124: Line 126:
 Pe langa clasa de mai sus, am mai declarat o clasa – ProcMonLogFunc,​ al carui scop este sa afiseze cat mai simplu cand intra intr-o functie si cand iese. Pentru aceasta am definit macroul: Pe langa clasa de mai sus, am mai declarat o clasa – ProcMonLogFunc,​ al carui scop este sa afiseze cat mai simplu cand intra intr-o functie si cand iese. Pentru aceasta am definit macroul:
  
-#define DBGTRACE_FN_() ProcMonLogFunc __my_log__(__FUNCTIONW__) care declara un obiect de tip ProcMonLogFunc caruia ii da ca parametru numele functiei curente. Astfel, pus macroul la inceputul unei functii el va afisa la inceputul functiei numele functiei si la iesire, cand se distruge obiectul declarant, va afisa faptul ca iese din functie.+<​code>​#define DBGTRACE_FN_() ProcMonLogFunc __my_log__(__FUNCTIONW__)</​code> ​care declara un obiect de tip ProcMonLogFunc caruia ii da ca parametru numele functiei curente. Astfel, pus macroul la inceputul unei functii el va afisa la inceputul functiei numele functiei si la iesire, cand se distruge obiectul declarant, va afisa faptul ca iese din functie.
  
 Ok, inarmati cu toate acestea sa pornim ProcessMonitor,​ sa schimbam filtru in care sa punem ProcessName contains EvenimenteProcMon. Selectam butonul de Profiling ca in figura de mai jos: Ok, inarmati cu toate acestea sa pornim ProcessMonitor,​ sa schimbam filtru in care sa punem ProcessName contains EvenimenteProcMon. Selectam butonul de Profiling ca in figura de mai jos:
Line 241: Line 243:
  
 In concluzie am vazut cum putem monitoriza ce se intampla pe retea si cum putem vedea efectiv traficul. In concluzie am vazut cum putem monitoriza ce se intampla pe retea si cum putem vedea efectiv traficul.
 +
 +====== Resurse ======
 +
 +{{:​ep:​laboratoare:​logs2.zip|}}
 +
 +Parola arhiva resurse (log2.zip): parola
 +
 +
 +Masina virtuala:
 +
 +<​code>​
 +mkdir /​home/​student/​windows
 +sudo mount -orw /​dev/​sda2 ​ /​home/​student/​windows
 +</​code>​
 +
 +Parola VM: !@#4QWEr
 +
 +
  
  
ep/laboratoare/05.1484599269.txt.gz · Last modified: 2017/01/16 22:41 by emilian.radoi
CC Attribution-Share Alike 3.0 Unported
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0