issue'lerin en babasi heap problemi.

[sardok]

Cemo,

Biliyosun yakala'da runtime sorunu var abi, bu mevcut framework'dede var actor degisikliginden sonrada devam ediyor. Ben Set den oldugunu dusunuyorum ama olmama ihtimali ortaya cikti! cunku set yerine database koydum, yok olmadi.

Fakat, Heap probleminde bi adim oteye gittim ve jvm'e out of memory exception'u oldugu zaman heap'i dump etmesini saglayan bir flag ekledim (export JAVA_OPTS="-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=heap_dump").
Cok guzel oldu heap'i dump etti (yaklasik 1GB lik bir dosya) ve bende heap in icini desmeye basladim.

Su stringler tanidik geliyor mu?

0072 005f 006c 0069 0073 0074 002e 0070 .r..l.i.s.t...p
000012b0: 0068 0070 003f 0073 0065 006c 0065 0063 .h.p.?.s.e.l.e.c
000012c0: 0074 006f 0072 003d 0031 0026 0061 0063 .t.o.r.=.1.&.a.c
000012d0: 0074 0069 006f 006e 003d 0062 0075 0079 .t.i.o.n.=.b.u.y
000012e0: 005f 006e 006f 0077 0026 0070 0072 006f ..n.o.w.&.p.r.o
000012f0: 0064 0075 0063 0074 0073 005f 0069 0064 .d.u.c.t.s..i.d
00001300: 003d 0031 0031 0034 0031 0039 0032 0020 .=.1.1.4.1.9.2.
00001310: 0022 003e 003c 0069 006d 0067 0020 0073 .".>.<.i.m.g. .s
00001320: 0072 0063 003d 0022 0069 006d 0061 0067 .r.c.=.".i.m.a.g
00001330: 0065 0073 002f 0073 0061 0074 0069 006e .e.s./.s.a.t.i.n
00001340: 005f 0061 006c 002e 0067 0069 0066 0022 ..a.l...g.i.f."
00001350: 0020 0062 006f 0072 0064 0065 0072 003d . .b.o.r.d.e.r.=
00001360: 0022 0030 0022 003e 003c 002f 0061 003e .".0.".>.<./.a.>
00001370: 003c 002f 0074 0064 003e 000a 0020 0020 .<./.t.d.>... .
00001380: 0020 0020 0020 0020 0020 0020 0020 0020 . . . . . . . .
00001390: 003c 002f 0074 0072 003e 000a 0020 0020 .<./.t.r.>... .
000013a0: 0020 0020 0020 0020 0020 0020 0020 0020 . . . . . . . .
000013b0: 003c 0074 0072 003e 000a 0020 0020 0020 .<.t.r.>... . .
000013c0: 0020 0020 0020 0020 0020 0020 0020 0020 . . . . . . . .
000013d0: 0020 003c 0074 0064 0020 0063 006c 0061 . .<.t.d. .c.l.a
000013e0: 0073 0073 003d 0022 006d 0061 0069 006e .s.s.=.".m.a.i.n
000013f0: 0022 0020 0061 006c 0069 0067 006e 003d .". .a.l.i.g.n.=
00001400: 0022 0072 0069 0067 0068 0074 0022 0020 .".r.i.g.h.t.".
00001410: 0077 0069 0064 0074 0068 003d 0022 0032 .w.i.d.t.h.=.".2
00001420: 0030 0070 0078 0022 0020 0076 0061 006c .0.p.x.". .v.a.l
00001430: 0069 0067 006e 003d 0022 0074 006f 0070 .i.g.n.=.".t.o.p
00001440: 0022 003e 0031 0038 002e 003c 002f 0074 .".>.1.8...<./.t
00001450: 0064 003e 000a 0020 0020 0020 0020 0020 .d.>... . . . .
00001460: 0020 0020 0020 0020 0020 0020 0020 003c . . . . . . . .<
00001470: 0074 0064 0020 0063 006c 0061 0073 0073 .t.d. .c.l.a.s.s
00001480: 003d 0022 006d 0061 0069 006e 0022 0020 .=.".m.a.i.n.".
00001490: 0061 006c 0069 0067 006e 003d 0022 0063 .a.l.i.g.n.=.".c
000014a0: 0065 006e 0074 0065 0072 0022 0020 0077 .e.n.t.e.r.". .w
000014b0: 0069 0064 0074 0068 003d 0022 0038 0070 .i.d.t.h.=.".8.p
000014c0: 0078 0022 0020 0076 0061 006c 0069 0067 .x.". .v.a.l.i.g
000014d0: 006e 003d 0022 0074 006f 0070 0022 003e .n.=.".t.o.p.".>
000014e0: 0026 006e 0062 0073 0070 003b 003c 002f .&.n.b.s.p.;.<./
000014f0: 0074 0064 003e 000a 0020 0020 0020 0020 .t.d.>... . . .
00001500: 0020 0020 0020 0020 0020 0020 0020 0020 . . . . . . . .
00001510: 003c 0074 0064 0020 0063 006c 0061 0073 .<.t.d. .c.l.a.s
00001520: 0073 003d 0022 006d 0061 0069 006e 0022 .s.=.".m.a.i.n."
00001530: 0020 0076 0061 006c 0069 0067 006e 003d . .v.a.l.i.g.n.=
00001540: 0022 0074 006f 0070 0022 003e 003c 0061 .".t.o.p.".>.<.a
00001550: 0020 0068 0072 0065 0066 003d 0022 002f . .h.r.e.f.=."./
00001560: 0070 0072 006f 0064 0075 0063 0074 005f .p.r.o.d.u.c.t._
00001570: 0069 006e 0066 006f 002e 0070 0068 0070 .i.n.f.o...p.h.p
00001580: 003f 0070 0072 006f 0064 0075 0063 0074 .?.p.r.o.d.u.c.t
00001590: 0073 005f 0069 0064 003d 0031 0030 0038 .s._.i.d.=.1.0.8
000015a0: 0036 0034 0038 0022 003e 003c 0062 003e .6.4.8.".>.<.b.>
000015b0: 004d 0065 006c 0065 006b 006c 0065 0072 .M.e.l.e.k.l.e.r

memory bunlarla dolu abi. Ilk suphelendigim jsoup'dan gelen Documentler oldu, cunku bakiyorumki hala html elementleri var bu datalarin icerisinde.
Biraz jvm garbage collector'une baktim ama bizim yanlis yaptigimiz birsey yok gibi duruyor.
Hatta scalanin olusturdu kodu dump ettim(javap komutuyla oluyor cok faydali), spider tarafinda ilgili kismi kopyaliyorum;

public scala.collection.immutable.Map processItem(org.jsoup.nodes.Document);
Code:
Stack=7, Locals=14, Args_size=2
0: aload_1
1: invokevirtual #518; //Method org/jsoup/nodes/Document.title:()Ljava/lang/String;
.
.
.

LocalVariableTable:
Start Length Slot Name Signature
0 355 0 this Lyakala/spiders/PandoraSpider;
0 355 1 doc Lorg/jsoup/nodes/Document;
5 313 2 title Ljava/lang/String;
.
.
.

Gordugum gibi burda doc, local variable tablosunda abi ve bu scope'dan sonra yok olmasi lazim (jvm garbage collector'une gore). Sence heap deki bu veriler nerde olabilir baska?

[sardok]

Cemo, jconsole diye bisey kesfettim abi super otesi.
calisan java instance'inin pid numarasini aliyorsun.
jconsole yaziyorsun ve ola!
resmen buyu gibi bisey hersey var.

[rimbi]

Sinancan,

doc değişkeni java için bildiğim kadarıyla pointer değişkeni. Stackten doc kaldırıldığında doc'un işaret ettiği nesnenin kaldırılacağı manasına gelmiyor bu. Garbage collector belirli zamanlarda (ya timeout ya insufficient memory ya her ikisi ya da araştırmamız gereken başka sebelerle) çalışıp silinmesi gereken objeleri seçip siliyor.
Bunu gözönüne aldığımızda yukarıdaki heap dump'a bakarak doc objelerinde memory leak olduğunu söyleyemeyiz diye düşünüyorum.
Garbage collector'ı daha sık çalıştırabilsek iyi olurdu. Program biraz yavaşlardı ama sanırım memory tüketimi azalmış olurdu.

[sardok]

cemo bu bugda ben ilerleme kaydetmiştim ama burda paylaşmadım kusura bakma.

garbage collector'u her fonksiyon çıkmadan önce çalıştırdım bu arda
işe yaramadı, onun dışında.

jhat diye bi komut var, şurda kullanımı açıklanmış.

http://blog.emptyway.com/2007/04/02/finding-memory-leaks-in-java-apps/

bunu kullanarak, heap deki objerleri, sizelari, refere edenleri gibi
şeyleri gösteriyor. bayağı kullanışlı. bu tool'u kullanarak gördüğüm
şeyleri doc objesi olduğunu düşünmüştüm, olmayabilirde ama sende
kullanırsan görüceğin şey. crawl edilen bir sayfanın tüm html içeriği,
ama komple yani heh.

sonradan farkettimki, bu adece benim en son açtığı
'actor-design-with-refdb' branchinde oluyor. sebebini anlamadım ama
heap sorunlarını bulmak için iyi bir örnek olabilir. bu arada bu
branch'in başka bir özelliğide, daha önce yazılımdaki bottleneck
spider idi. yani spider'a bir sürü url yollanıyor, o sırayla
işliyordu, fakat bu branch'de bottleneck crawler'in refdbsi. şimdi
böyle olunca belki kodda olan fakat göremediğimiz bi sorun mu ortaya
çıktı diye düşünüyordumki, tam çözemeden bayram geldi :).

neyse neticesinde bu bug geçerli değil (eğer actor-design-with-refdb
branchi kullanılmazsa.) fakat linkleri tutan crawler'daki set'in şişip
yavaşlaması hala bi sorun.

2011/8/27 rimbi
[email protected]:

Sinancan,

doc değişkeni java için bildiğim kadarıyla pointer değişkeni. Stackten doc kaldırıldığında doc'un işaret ettiği nesnenin kaldırılacağı manasına gelmiyor bu. Garbage collector belirli zamanlarda (ya timeout ya insufficient memory ya her ikisi ya da araştırmamız gereken başka sebelerle) çalışıp silinmesi gereken objeleri seçip siliyor.
Bunu gözönüne aldığımızda yukarıdaki heap dump'a bakarak doc objelerinde memory leak olduğunu söyleyemeyiz diye düşünüyorum.
Garbage collector'ı daha sık çalıştırabilsek iyi olurdu. Program biraz yavaşlardı ama sanırım memory tüketimi azalmış olurdu.

Reply to this email directly or view it on GitHub:
#20 (comment)

[rimbi]

İyi haber. DB için harcadığın eforu koruyabilecek miyiz yoksa boşa mı gitmiş olacak?

[sardok]

valla şu an boşa gitmiş gibi görünüyor ama benim için ufak çaplı
terübe oldu, o branchde neden heap çok hızlı yükseliyor ona biraz
bakıcam sadece, bu konuyu daha iyi anlamama yardımcı olabilir.

On Sun, Aug 28, 2011 at 9:35 PM, rimbi
[email protected]
wrote:

İyi haber. DB için harcadığın eforu koruyabilecek miyiz yoksa boşa mı gitmiş olacak?

Reply to this email directly or view it on GitHub:
#20 (comment)

[rimbi]

Ok. O branch'i bi sure tutalim derim, faydalanma ihtimaline karsi.

2011/8/29 sardok <
[email protected]>

valla u an boa gitmi gibi grnyor ama benim iin ufak apl
terbe oldu, o branchde neden heap ok hzl ykseliyor ona biraz
bakcam sadece, bu konuyu daha iyi anlamama yardmc olabilir.

On Sun, Aug 28, 2011 at 9:35 PM, rimbi
[email protected]
wrote:

yi haber. DB iin harcadn eforu koruyabilecek miyiz yoksa boa m
gitmi olacak?

Reply to this email directly or view it on GitHub:
#20 (comment)

Reply to this email directly or view it on GitHub:
#20 (comment)

[sardok]

cem sana zahmet su linkdeki dosyayi bi goz atarmisin?

https://github.com/returneksibir/yakala/blob/actor-design-with-ref-db/yakala/refdb/RefDb.scala

burda sence leak'e sebeb olucak bisey var mi?

[rimbi]

Şu an için bir şey göremedim. Anlayabildiğim kadarıyla her addRef çağrısına karşı bir delRef çağrısı yapılması lazım. Bunun yapıldığından emin misin?

[sardok]

cemo, delRef yapilirsa, o link database'den silinir. onun yapilmamasi lazim.

2011/9/9 Cem Eliguzel
[email protected]:

Şu an için bir şey göremedim. Anlayabildiğim kadarıyla her addRef çağrısına karşı bir delRef çağrısı yapılması lazım. Bunun yapıldığından emin misin?

Reply to this email directly or view it on GitHub:
#20 (comment)

[rimbi]

e öyleyse senin memory leak dediğin durum oluşmuş olmuyor mu?

[sardok]

yok ya neden. addRef database'e yaziyor sadece.

On Fri, Sep 9, 2011 at 3:54 PM, Cem Eliguzel
[email protected]
wrote:

e öyleyse senin memory leak dediğin durum oluşmuş olmuyor mu?

Reply to this email directly or view it on GitHub:
#20 (comment)