Thread profiling - hogyan

Fejlesztés

Udv!

A processzem 100%on teker, amit biztosan valamelyik threadje okoz, ezeket szeretnem debugolni/profileolni.
Ugye a sima process profiling nem vezet itt eredmenyre.
jelenleg oprofile al problakozok, opreport -l { tid:1 } { }
errort ad vissza, hogy a specifikacio tul strict... ez nekem zsakutca lett, doksi nem magyarazta meg mi lehet itt a problema.

Van estleg otlete vagy ajanlasa egy jo progira(annak gyors hasznalataval egyutt) valakinek, hogy hogyan lehetne minnel fajdalommentesebben profilolni a threadeket?

koszi,
Zsolt

  • 1385 megtekintés

( uid_15426 | 2010. 02. 17., sze – 10:30 )

Valgrind / Cachegrind / VTune?

----------------------
while (!sleep) sheep++;

( vomberg | 2010. 02. 17., sze – 12:33 )

Bővebben a programról? Konzolos alkalmazás vagy valamilyen GUIt is használsz?

( Andrei | 2010. 02. 18., cs – 15:15 )

Oprofile/Vtune barmelyike jo lesz neked.

Az oprofile azert nem adott eredmenyt, mert nem volt 1-es thread id. Gyujtsd ossze egy logba az osszes thread id-t es azokat add at parameterkent.

Ez azon mulik, hogy mennyi rahatasod van a programra es a futtatasi kornyezetre.

(1) Ha van forraskodod, akkor az osszes thread letrehozas muvelet (pthread_create) elso parameterben adja vissza a threadid-et. Ha ezt kilogolod, akkor kesobb felhasznalhatod az oprofile reportok szuresehez.

(2) Ha nincs forraskodod, akkor kell csinalni egy egyszeru shared objectet, ami definialja a pthread_create muveletet (termeszetesen azonos szignaturaval, mint a libpthread). Ket kis fuggvenyre van szukseged:
- a .so _init fuggvenyeben dlsym hivassal kikeresi a valodi (libpthread.so -ban definialt) pthread_create fuggveny cimet es egy statikus fuggvenypointerben eltarolja.
- a .so pthread_create fuggvenyben delegalja beerkezo hivast az eltarolt fuggvenypointer fele, es visszatereskor egy file-ba, vagy naploba kiirja a thread_id-t.

Ha ez megvan akkor a kovetkezo modon kell futtatnod az alkalmazasod: LD_PRELOAD=./libfakepthread.so yourprogram

Ez akkor is mukodik, ha a program csak binaris formaban van meg (azaz nem intruziv).

Ha a binaris tarol debug infot, akkor a backtrace() hivassal ki tudod gyujteni a hivasi kontextust is. Gondolom ez a helyzet, mert kulonben az oprofile sem fog rajtad sokat segiteni (csak hexa cimeket fogsz latni).

(3) Ha egyikhez sincs kedved/lehetoseged, akkor ps -p
-L -o pid,tid hivogatasaval es parsolasaval is kinyerheted az infot. Nyilvan ez a rovid eletu szalakat nem fogja el.

( praetor | 2010. 02. 18., cs – 16:47 )

ha van solarisod
dtrace -n 'profile-3001:::/pid==$target/{@[ustack(7), tid]=count();}' -c programod
ha nincs akkor tanulmanyozd a -finstrument-functions gcc kapcsolot.

solarison egy pstack-ből simán meg lehet mondani, hogy miért teker a program.
linuxon egy debuggerrel megállítod, kérsz minden threadről stack frame dumpot, és szintén lehet tudni.

persze, ha a program forrásához nincs hozzáférésed, akkor mérsékelten értelmes az egész...

ha van nehany orad debuggerrel jatszani, es eleg stacktracet gyujteni vele, hogy atfogo keped legyen arrol, mivel is telik az ido, akkor igen, jo a debugger/pstack is. (linuxon is van pstack amugy, csak kicsit gagyi) ha nincs akkor a profile-3001-el 5mp alatt boven eleg infot gyujtesz. a debuggeres megoldasnal szerintem a kezi traceles -finstrument-functions-al is gyorsabb lesz.