SVN6730 wieder Speicherleck

Hier finden YaCy User Hilfe wenn was nicht funktioniert oder anders funktioniert als man dachte. Bei offensichtlichen Fehlern diese bitte gleich in die Bugs (http://bugs.yacy.net) eintragen.
Forumsregeln
In diesem Forum geht es um Benutzungsprobleme und Anfragen für Hilfe. Wird dabei ein Bug identifiziert, wird der thread zur Bearbeitung in die Bug-Sektion verschoben. Wer hier also einen Thread eingestellt hat und ihn vermisst, wird ihn sicherlich in der Bug-Sektion wiederfinden.

SVN6730 wieder Speicherleck

Beitragvon dulcedo » Di Mär 09, 2010 12:19 pm

Nach ca 6 Stunden geht ihm der Speicher aus, danach keine Portreaktion mehr, zuvor war 6679 (initial 0.94) installiert.
Dateianhänge
yacy_100309 .jpg
yacy_100309 .jpg (69.61 KiB) 1234-mal betrachtet
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: SVN6730 wieder Speicherleck

Beitragvon sixcooler » Di Mär 09, 2010 1:22 pm

wie viel hast Du dem peer an Heapspeicher zugewiesen? 3,3G?
wie viel hast Du nach einem Manuellen GC frei - ändert ein manueller GC etwas an der Geschichte?
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: SVN6730 wieder Speicherleck

Beitragvon Orbiter » Di Mär 09, 2010 2:34 pm

ok, probier mal SVN 6734
- guckt öfters ob speicher voll ist um dann die table copy zu löschen
- herabsenkung der Schwelle wann der table cache gelöscht wird: nun bei 10% des im Anfang verfügbaren Speichers (vorher bei 20mb)
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: SVN6730 wieder Speicherleck

Beitragvon dulcedo » Di Mär 09, 2010 4:37 pm

Zugewiesen sind 4000MB eine Diskrepanz die ich schon ein paarmal beschrieben habe. Ich versuche die aktuelle SVN, ein zweiter peer auf der selben Maschine hat das Problem auch; das wohl weniger ein Leck als ein nicht ausgelöster GC ist?
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: SVN6730 wieder Speicherleck

Beitragvon sixcooler » Di Mär 09, 2010 9:41 pm

sorry hatte diese Diskrepanz nicht mehr auf dem Schirm

Nee ich denke nicht das ein expliziter GC 'fehlt' - die sind eigentlich nie notwendig - das macht java besser alleine.
Aber evtl. ist die 'Berechnung' der Vorhandenen Speichers in deinem Fall nicht so korrekt.
OOMs hast Du keine - oder?
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: SVN6730 wieder Speicherleck

Beitragvon dulcedo » Di Mär 09, 2010 10:06 pm

Das mit der falschen Berechnung hatte ich auch schon vermutet, manchmal verschwinden solche Probleme wenn ich 200MB mehr oder weniger zuweise. OOMs kommen vor, ich dokumentiere die laufend.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: SVN6730 wieder Speicherleck

Beitragvon dulcedo » Mi Mär 10, 2010 4:11 am

Nach 7 Stunden.
YaCy Version: 0.94/6734
Assigned Memory = 3868917760
Used Memory = 3367273440
Available Memory = 501644320


THREADS WITH STATES: BLOCKED

Thread= Session_124.217.239.196:28508#0 id=65707 BLOCKED
Thread= Session_84.73.145.212:56643#0 id=65751 BLOCKED
at net.yacy.kelondro.index.Cache.has(Cache.java:219) [if (readMissCache != null) {]
at de.anomic.search.MetadataRepository.exists(MetadataRepository.java:172)
at transferRWI.respond(transferRWI.java:192)
at sun.reflect.GeneratedMethodAccessor26.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.anomic.http.server.HTTPDFileHandler.invokeServlet(HTTPDFileHandler.java:1203)
at de.anomic.http.server.HTTPDFileHandler.doResponse(HTTPDFileHandler.java:760)
at de.anomic.http.server.HTTPDFileHandler.doPost(HTTPDFileHandler.java:244)
at de.anomic.http.server.HTTPDemon.POST(HTTPDemon.java:587)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at de.anomic.server.serverCore$Session.listen(serverCore.java:735)
at de.anomic.server.serverCore$Session.run(serverCore.java:629)


Thread= de.anomic.crawler.CrawlQueues.coreCrawlJob id=203 BLOCKED
at java.lang.Object.wait(Native Method)
at de.anomic.crawler.Balancer.pop(Balancer.java:428)
at de.anomic.crawler.NoticedURL.pop(NoticedURL.java:244)
at de.anomic.crawler.NoticedURL.pop(NoticedURL.java:211)
at de.anomic.crawler.CrawlQueues.coreCrawlJob(CrawlQueues.java:225)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at net.yacy.kelondro.workflow.InstantBusyThread.job(InstantBusyThread.java:98)
at net.yacy.kelondro.workflow.AbstractBusyThread.run(AbstractBusyThread.java:147)



THREADS WITH STATES: RUNNABLE

Dateianhänge
yacy-100310a.jpg
yacy-100310a.jpg (237.27 KiB) 1158-mal betrachtet
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: SVN6730 wieder Speicherleck

Beitragvon Orbiter » Mi Mär 10, 2010 10:19 am

im Prinzip ist das im grünen Bereich denn du hast 3.8 GB zugewiesen, die neue Limitierung des Table Copy Cache sieht vor dass 1/10 des zu Beginn verfügbaren Speichers frei sein muss bis eine Table copy gelöscht wird. Das waren vor der 1/10 Regel nur 20 MB, jetzt sind es durch deine 3.8 GB verfügbaren Speicher zu beginn eben 380 MB die frei bleiben müssen. Deine Statistik zeigt aber 500 MB freien Speicher, da zieht die Löschbremse noch nicht. Es sieht halt nur so aus als sei dein Speicher am Anschlag weil die Maßstäbe so verzerrt sind.

Wenn du ein OOM hast bitte den hier posten, dann kann ich daran weitere Löschregeln knüpfen.
Ansonsten: mehr RAM nuzen auch bis zum Anschlag ist ja gut das hilft der Peformance.
Orbiter
 
Beiträge: 5796
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: SVN6730 wieder Speicherleck

Beitragvon dulcedo » Mi Mär 10, 2010 11:37 am

Mir ist lediglich unklar warum ich 3800 zugewiesen habe wenn der JVM 5000 zugewiesen sind.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: SVN6730 wieder Speicherleck

Beitragvon Quix0r » Mi Mär 10, 2010 10:00 pm

Ich hoffe, diese Exception (SVN 6739) passt dazu:
Code: Alles auswählen
W 2010/03/10 21:55:45 StackTrace null
java.lang.reflect.InvocationTargetException
        at sun.reflect.GeneratedMethodAccessor22.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at net.yacy.kelondro.workflow.InstantBusyThread.job(InstantBusyThread.java:98)
        at net.yacy.kelondro.workflow.AbstractBusyThread.run(AbstractBusyThread.java:147)
Caused by: java.lang.OutOfMemoryError: Java heap space
W 2010/03/10 21:55:45 StackTrace Java heap space
java.lang.OutOfMemoryError: Java heap space
E 2010/03/10 21:55:45 BUSYTHREAD Runtime Error in serverInstantThread.job, thread 'de.anomic.search.Switchboard.dhtTransferJob': null; target exception: Java heap space
java.lang.OutOfMemoryError: Java heap space

Wenn nicht, bitte mir sagen. Dann mache ich neunen Thread auf. :)

Nur als Notiz:
Code: Alles auswählen
500 Internal Server Error

Unexpected error while processing query.
Session: Session_192.168.1.17:36366#0
Query: /yacysearch.html
Client: 192.168.1.17
Reason: java.lang.reflect.InvocationTargetException

Exception occured: java.lang.reflect.InvocationTargetException

TRACE:
      java.lang.reflect.InvocationTargetException
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at de.anomic.http.server.HTTPDFileHandler.invokeServlet(HTTPDFileHandler.java:1203)
   at de.anomic.http.server.HTTPDFileHandler.doResponse(HTTPDFileHandler.java:760)
   at de.anomic.http.server.HTTPDFileHandler.doGet(HTTPDFileHandler.java:236)
   at de.anomic.http.server.HTTPDemon.GET(HTTPDemon.java:454)
   at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at de.anomic.server.serverCore$Session.listen(serverCore.java:735)
   at de.anomic.server.serverCore$Session.run(serverCore.java:629)
Caused by: java.lang.OutOfMemoryError: Java heap space

Habe einfach einen Suchbegriff eingegeben. Speicherverbrauch laut Statistik (Performance_p.html): ~1600M (etwas mehr), zugewiesen sind 3300M (Xms und Xmx jeweils), der Speicherverbrauch (free) meiner Linux-Maschine zeigt 88988K an, also ist physikalisch noch Luft.
Quix0r
 
Beiträge: 1345
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld


Zurück zu Fragen und Antworten

Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 4 Gäste