• Willkommen im Geoclub - dem größten deutschsprachigen Geocaching-Forum. Registriere dich kostenlos, um alle Inhalte zu sehen und neue Beiträge zu erstellen.

cw bricht gc-spidern ab

R

realhuette

Geocacher
Hallo!
Ich habe folgendes Problem: beim spidern von gc bleibt cw nach gut 150 caches hängen.

Sind 200 zuviele? In Berlin hat man die schon bei einem Radius von 4 bis 5km.

Fehlermeldung siehe Screenshot. (Kann gerade wohl nix anhägen???? Meldung beginnt mit OutOfMemoryError: Java heap space)

Das log endet mit:
Code: 
01.11.2008/10:38: Fetching: GCGT61

01.11.2008/10:38: [fetch]:Cookie Zeug: Cookie: ASP.NET_SessionId=pcdlwkjxrzj4sgv4qn3ppy55; userid=e834eb8b-3957-4e20-82b1-52e7cc9a95ee

An dem speziellen cache liegt's nicht. Ist immer mal ein anderer...

Gibt es Abhilfe? Oder darf einfach die Liste nicht so lang sein?

Grüße,
Jürgen
 
Geo-Johnny

Geo-Johnny

Geowizard
realhuette schrieb:
Hallo!
Ich habe folgendes Problem: beim spidern von gc bleibt cw nach gut 150 caches hängen.

Sind 200 zuviele? In Berlin hat man die schon bei einem Radius von 4 bis 5km.
Zum Vergrößern anklicken....
Leider kann ich nichts dazu beitragen, da könnte Dir vielleicht das Entwicklerteam vom CW weiterhelfen.
Bei mir klappt das Spidern wunderbar, allerdings muß ich zugeben das ich die letzte Zeit nicht über ca.120 Caches gespidert habe. Ich verwende die letzte NB Version des CW, auf Basis der Version r1537.
L.G. - Johnny!
 
Bilbowolf

Bilbowolf

Geowizard
realhuette schrieb:
Hallo!
Ich habe folgendes Problem: beim spidern von gc bleibt cw nach gut 150 caches hängen.

Sind 200 zuviele? In Berlin hat man die schon bei einem Radius von 4 bis 5km.

Fehlermeldung siehe Screenshot. (Kann gerade wohl nix anhägen???? Meldung beginnt mit OutOfMemoryError: Java heap space)

Das log endet mit:
Code: 
01.11.2008/10:38: Fetching: GCGT61

An dem speziellen cache liegt's nicht. Ist immer mal ein anderer...

Gibt es Abhilfe? Oder darf einfach die Liste nicht so lang sein?

Grüße,
Jürgen
Zum Vergrößern anklicken....

was fuer eine Version nutzt du?
Java oder exe?
 
G

greiol

Geoguru
die menge an caches die gespidert/aktualisiert werden können unterliegt gewissen schwankungen. wenn man cw aber mal von einer kommandozeile aufruft, sieht man, dass man irgendwann in eine out-of-memory-exception läuft - es sei denn man setzt den speicher den sich die jvm nehmen darf so brutal hoch wie in anderen freds vorgeschlagen. mit einem tool wie visualgc kann man dabei auch genüsslich zuschauen. irgendwas zieht den old space nach und nach zu. was genau das ist, dürfte wohl nur ein profiler anzeigen.
 
MiK

MiK

Geoguru
Wird der Speicher denn wieder freigegeben, wenn dass Spidern abgeschlossen werden kann?
 
G

greiol

Geoguru
MiK schrieb:
Wird der Speicher denn wieder freigegeben, wenn dass Spidern abgeschlossen werden kann?
Zum Vergrößern anklicken....
leider nein. zumindest nicht vollständig.

für ein updated von 500 caches aus einer pq sieht die gc so aus (komplett)

wenn ich anschließend davon 75 caches markiere und aktualisieren lasse, sieht es so aus (endzustand)

man erkennt sehr schön, dass der old space kräftig erweitert wurde (grünes ratser) als auch, dass der anteil an belegtem old space am ende der aktion deutlich höher liegt (oranger stapel im old space). dieser wird auch nicht mehr abgebaut bis cw geschlossen wird.
 
G

greiol

Geoguru
ich hab noch etwas weiter gespielt.

sun jvm 1.6.irgendwas mit defaultwerten (also max 64 mb)

basisbefüllung über die myfinds pq ohne bilder.

die zahl der caches die ich aktualisieren kann, hängt scheinbar von Einstellungen / Max Logs spidern ab (degault ist 250 :schockiert:). nachdem ich im ersten durchgang ein paar events dabei hatte, war nach 35 caches ende. den wert mal auf 5 reduziert und dem aktualisierer gelingt es knapp 600 caches zu laden.

der heap sieht dann so aus:

interessant war, dass auch die um 22:29 von mir händisch ausgelöste gc nicht wirklich platz gemacht hat.

der speicher wird dabei hauptsächlich mit char[] gefüllt. die sich hier

ansiedeln.

ein paar überlegungen:

den defaultwert für maxlogsspidern könnte man evtl. niedriger wählen und in der doku vermerken, dass man einiges an speicher haben haben sollte wenn man den hochsetzt. ich vermute mal, dass auch die nativen versionen ähnlich viel platz brauchen, bloss unterliegen die halt nicht den restriktionen der jvm und nehmen sich den einfach.

wenn ich mich durch die liste der char[]-objekte klicke fällt mir auf, dass der quelltetxt der seite verdammt oft im speicher liegt, da scheinbar jedem objet das etwas aus der seite extrahieren soll immer die komplette seite übergeben wird. wenn ich das mit einem fetten listing mit vielen logs mache, ist die zeit bis mir der speicher explodiert natürlich endlich. wäre es sinnvoll die seite "vorzuzerlegen" (z.b. in die bereiche description und logs) bevor die seite an die jeweiligen "fachparser" übergeben wird? das würde den speicherbedarf eines einzelnen caches sicherlich reduzieren.

wo wird eigentlich die neue index.xml aufgebaut? im memory?

das verghältnis der "lebendigen" objekte zu den allozierten ist im bereich der zeichenketten sehr ungünstig - muss/sollte man evtl. der GC auf die sprünge helfen indem mehr objektreferenzen am ende ihres daseins explizit auf null gesetzt werden?

nach dem spidern / aktualisieren, sollte man cw schliessen und neu starten. er wird dann auch wieder schön schlank und schnell.

die daten stammen aus dem profiler von netbeans. im wesentlichen lässt sich cw damit analog der eclipse anleitung bauen.
 
MiK

MiK

Geoguru
Kannst Du es noch mal mit Maxlogs=6 versuchen? Bis 5 laden wir nur die einfache Seite. Danach die mit allen Logs. Wenn es an der Seite an sich liegt und nicht daran, wie viele Logs wir speichern, sollte es bei 6 schon das gleiche Verhalten wie bei 250 zeigen.
 
MiK

MiK

Geoguru
greiol schrieb:
ich hab noch etwas weiter gespielt.

der speicher wird dabei hauptsächlich mit char[] gefüllt. die sich hier

ansiedeln.
...
wenn ich mich durch die liste der char[]-objekte klicke fällt mir auf, dass der quelltetxt der seite verdammt oft im speicher liegt, da scheinbar jedem objet das etwas aus der seite extrahieren soll immer die komplette seite übergeben wird. wenn ich das mit einem fetten listing mit vielen logs mache, ist die zeit bis mir der speicher explodiert natürlich endlich. wäre es sinnvoll die seite "vorzuzerlegen" (z.b. in die bereiche description und logs) bevor die seite an die jeweiligen "fachparser" übergeben wird? das würde den speicherbedarf eines einzelnen caches sicherlich reduzieren.
Zum Vergrößern anklicken....
Wenn ich die Grafik richtig verstehe, dann ist das doch in jeder Zeile immer wieder der gleiche Speicher. Nur auf verschiedenen Ebenen zusammengefasst. Interessant wäre dabei, wo das ganz unten endet.
 
G

greiol

Geoguru
MiK schrieb:
Interessant wäre dabei, wo das ganz unten endet.
Zum Vergrößern anklicken....
bei der jvm selber. das problem ist, dass diese listen so endlos lang sind, dass es schwer ist das alles in einem screenshot zusammen zu bekommen. je weiter man den dargestellten baum verfolt um so abstrakter wird es erst mal. in weiteren eigenen bäumen kommen dann die anderen objekte die die restlichen 10% der char[] belegen.
 
OP
R

realhuette

Geocacher
Da ich doch mal wieder probieren wollte, ein paar Caches mehr zu spidern, bringe ich das Thema noch einmal hoch.
Wieder ist cachewolf bei mir kurz vor dem Ziel bei 206 Caches stehen geblieben. Wieder heap out of memory. Nun habe ich wegen eines ähnlichen Problemes in einem anderen Forum gelesen, dass man den heap-Speicher mit der Option -Xmx erhöhen kann.
Habe die cachewolf.bat also angepasst: java -Xms32m -Xmx256m ...
Und siehe da, es geht! :D

Man kann den Speicherbedarf von cachewolf auch ganz gut im Windows Task Manager sehen. Es fängt an mit gut 30 MB und geht beim Spidern kräftig hoch. Aber nicht kontinuierlich, sondern irgendwie in Sprüngen. Da waren nach dem Spidern eines caches (so ca. der 205. von 226) schon mal 5 MB weg. Vorher brauchten 30 nur 2 MB usw.
Nach 226 Caches waren es dann gut 120 MB Speicher. Die wurden auch nach Beendigung des Spidern nicht mehr weniger.

greiol schrieb:
es sei denn man setzt den speicher den sich die jvm nehmen darf so brutal hoch wie in anderen freds vorgeschlagen.
Zum Vergrößern anklicken....
Wieviel ist denn brutal hoch? Sind diese Optionen die richtigen?

Na, auf jeden Fall läuft es so besser.

Vielen Dank für die Hinweise!
Jürgen
 
G

greiol

Geoguru
realhuette schrieb:
Wieviel ist denn brutal hoch? Sind diese Optionen die richtigen?
Zum Vergrößern anklicken....
die optionen sind die richtigen und wenn die parameter der optionen für dich zum ziel führen sind sie wohl auch richtig. der benötigte speicher hängt zusammen mit der anzahl der gespidern caches, der größe der jeweiligen cachebeschreibungen und der anzahl der logs. wenn du all die werte vorher kennst kannst du den bedarf vermutlich ausrechnen, wenn du die formel kennst.

interessanter finde ich immer noch die frage nach der ursache für den speicherverbrauch, denn "normal" ist das nicht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben