Linux za Sve forum

Slamd64 je napisao/la:Isključi desktop efekte, ili prebaci na softverski rendering. Mada ne vjerujem da to ima veze.

@Netko Ati ima prilično očajne proprietary drivere, to će ti reći osim mene svaki ati-jev korisnik. S open source nemam problema.

Gesendet von meinem MT11i mit Tapatalk 2

Probao sam i bez desktop efekata - nema razlike koliko se sjećam, ali evo još jednom ću probati bez njih

Izbjegavam vlasničke drivere na veliko - tako i odabirem hardver pri kupnji - prva stavka da radi sa slobodnim kernelom, a onda sve ostalo

drade je napisao/la:@andY

Tesko ces tako prckajuci naci "memory leak" na sustavu.

Ono sto mozes je upogoniti alat kao sto je valgrind.

Kod: Označi sve

valgrind -v --leak-check=yes --tool=memcheck --log-file=memtracer.log /putanja/do/app


Npr.

Kod: Označi sve

valgrind -v --leak-check=yes --tool=memcheck --log-file=memtracer.log /bin/tracepath google.com


Po zavrsetku bi trebao dobiti datoteku memtracer.log unutar koje bi mogao saznati nesto vise.

Znam za valgrind, ali ne mogu vrtiti cijele X-e i sve aplikacije u njemu u valgrindu pogotovo ne dugo vremena (cca tjedan dana) na produkcijskoj mašini. Ipak značajno usporava rad aplikacija, a neke nisam uspio ni pokrenut u realnom vremenu s valgrindom.

Hvala vam svima na idejama - probat ću ih nekako sistematizirat i pokušat primjenit da izgubim najmanje vremena i najmanje poremetim svoj svakodnevni workflow. Iako mi se čini da je najlakša solucija uzet bolje podržanu grafičku - mislim da se u ovom slučaju isplati dat cca 300kn i problem zaobiđen No kad bih sigurno znao da je problem u grafičkoj...

4ndY je napisao/la:A možda ću i to probat... iako je pitanje moram li onda i Qt rebuildat jer ipak novije verzije KDE-a zahtjevaju noviji Qt, a noviji Qt novije X-e itd.

Da treba pazit na te zavisnosti - to je jos i najzeznutiji dio ^^... Pazi i da ti glibc bude na istoj verziji ko i onaj na problematicnoj sustavu... Najidealnje bi ti vjerojatno bilo da dignes fedoru 17 na neki spare server ako imas takvog ^^.

4ndY je napisao/la:Da, dešava se samo s KDE-om i može se reći da nije izolirani slučaj već se ponavlja (desilo mi se barem već 20-ak puta ako ne i više). Kad ulovim vremena malo ću još potražit po internetu kako se radi forenzika RAM/swap dumpa...

A ti se desava to kad samo KDE(bez da pokreces ikakve aplikacije) ostavis da ti radi nego duze vrijeme? Imas uopce mogucnosti isprobat taj scenarij?
Ajd javi(ako ti nije prob) ako nades sta za tu forenziku RAM-a, sad me bas zanima, ali mi se idalje cini da to nije bas moguce ^_x.

4ndY je napisao/la:Iako mi se čini da je najlakša solucija uzet bolje podržanu grafičku - mislim da se u ovom slučaju isplati dat cca 300kn i problem zaobiđen No kad bih sigurno znao da je problem u grafičkoj...

Mene u tom slucaju najvise brine da driver vjerojatno i dijeli neke dijelove izmedu razlicitih modela grafulja... Probaj posudit neku drugu eksternu ATI-eviku za koju mislis da je dobro/bolje podrzana pa ako ti se problem ne ponavlja onda je tek upikni... Mada je tu problem - kolko ti se cesto to desava? Ja sam bio pod dojmom da ti se to desi jednom dnevno...ali ako je jednom tjednom, e to je vec malo zeznuto...

Sretno svakako .

Forensic Analysis of a Live Linux System, Pt. 1
http://www.symantec.com/connect/article ... ystem-pt-1

ako nije moguće zašto se onda se onda radi?

Lutherus je napisao/la:Forensic Analysis of a Live Linux System, Pt. 1
http://www.symantec.com/connect/article ... ystem-pt-1

ako nije moguće zašto se onda se onda radi?

Hvala Luth, pomogao mi je ovaj Pt. 2.

Evo postupak:
* napravio sam dd swapa i RAM-a,
* izvukao sam donekle smislene stringove sa: "strings -t d dump.dat > dump-clean.dat",
* izbacio sam brojeve na početku svake linije sa: sed "s/^[\ 0-9].* / /g" dump-clean.dat > dump-cleaner.dat
* ispisao sam linije koje se najčešće pojavljuju i sortirao: cat dump-cleaner.dat | uniq -c | sort -g | tail -n300
* ove koje se najčešće pojavljuju sam "grepnuo" i prebrojao...

And the winner is: akonadi!

Kod: Označi sve

# grep akonadi_maildir_resource_1 swap.dat  | wc -l
75457
# grep akonadi_maildir_resource_1 fmem.dat | wc -l
98290


Zaključak je da akonadi ima leak u mom slučaju jer kad ubijem sve procese (uključujući i X-e), RAM i swap ostaju puni, a obrazac koji se najviše pojavljuje u njima jest "akonadi_maildir_resource_1" dok se svi drugi stringovi pojavljuju puno rjeđe.