RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

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.

RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon dulcedo » Di Feb 09, 2010 5:55 am

Tritt am Ende des Hochfahrens von SVN6656 auf. Vorher auch im Betrieb noch knapp 1GB frei.
Code: Alles auswählen
I 2010/02/09 05:47:06 TABLE initialization of text.urlmd.20090101000002119.table. table copy: no, available RAM: 948MB, needed: 14705MB, allocating space for 11628210 entries
I 2010/02/09 05:47:06 TABLE /home/yacy/yacy-b/DATA/INDEX/freeworld/SEGMENTS/default/text.urlmd.20090101000002119.table: TABLE /home/yacy/yacy-b/DATA/INDEX/freeworld/SEGMENTS/default/text.urlmd.20090101000002119.table has table copy DISABLED
I 2010/02/09 05:47:06 TABLE initializing RAM index for TABLE text.urlmd.20090101000002119.table, please wait.

W 2010/02/09 05:47:21 StackTrace 37821436 bytes needed for RowCollection grow after OutOfMemoryError Java heap space: 994643296 free at Tue Feb 09 05:47:21 CET 2010
net.yacy.kelondro.index.RowSpaceExceededException: 37821436 bytes needed for RowCollection grow after OutOfMemoryError Java heap space: 994643296 free at Tue Feb 09 05:47:21 CET 2010
   at net.yacy.kelondro.index.RowCollection.ensureSize(RowCollection.java:236)
   at net.yacy.kelondro.index.RowCollection.addUnique(RowCollection.java:347)
   at net.yacy.kelondro.index.RowCollection.addUnique(RowCollection.java:325)
   at net.yacy.kelondro.index.ObjectIndexCache.addUnique(ObjectIndexCache.java:158)
   at net.yacy.kelondro.index.HandleMap.putUnique(HandleMap.java:206)
   at net.yacy.kelondro.table.Table.<init>(Table.java:154)
   at net.yacy.kelondro.table.SplitTable.init(SplitTable.java:207)
   at net.yacy.kelondro.table.SplitTable.<init>(SplitTable.java:122)
   at net.yacy.kelondro.table.SplitTable.<init>(SplitTable.java:95)
   at de.anomic.search.MetadataRepository.<init>(MetadataRepository.java:79)
   at de.anomic.search.Segment.<init>(Segment.java:131)
   at de.anomic.search.Segments.segment(Segments.java:140)
   at de.anomic.search.Segments.segment(Segments.java:132)
   at de.anomic.search.Switchboard.<init>(Switchboard.java:349)
   at net.yacy.yacy.startup(yacy.java:221)
   at net.yacy.yacy.main(yacy.java:1029)
E 2010/02/09 05:47:21 STARTUP FATAL ERROR: null
java.lang.NullPointerException
   at net.yacy.kelondro.index.Cache.init(Cache.java:84)
   at net.yacy.kelondro.index.Cache.<init>(Cache.java:79)
   at de.anomic.search.MetadataRepository.<init>(MetadataRepository.java:84)
   at de.anomic.search.Segment.<init>(Segment.java:131)
   at de.anomic.search.Segments.segment(Segments.java:140)
   at de.anomic.search.Segments.segment(Segments.java:132)
   at de.anomic.search.Switchboard.<init>(Switchboard.java:349)
   at net.yacy.yacy.startup(yacy.java:221)
   at net.yacy.yacy.main(yacy.java:1029)
S 2010/02/09 05:47:21 SHUTDOWN goodbye. (this is the last line)
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon sixcooler » Di Feb 09, 2010 12:43 pm

ist das nicht wie in OOM nach dem Laden der Index-Dumps?

Ich habe dieses scheitern von 'ensuresize()' beim mergen von größeren blobs, dachte schon ich hätte da ne Löung...
... wurde aber gerade eines Besseren belehrt :-(
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon dulcedo » Di Feb 09, 2010 3:12 pm

Hier 200MB mehr zugewiesen; Erst nochmal 300MB mehr lässt ihn starten, im Betrieb dann 1,5GB frei.
Code: Alles auswählen
I 2010/02/09 15:04:26 TABLE initializing RAM index for TABLE text.urlmd.20090101000002119.table, please wait.
W 2010/02/09 15:04:51 StackTrace 74130044 bytes needed for RowCollection grow after OutOfMemoryError Java heap space: 1505690016 free at Tue Feb 09 15:04:51 CET 2010
net.yacy.kelondro.index.RowSpaceExceededException: 74130044 bytes needed for RowCollection grow after OutOfMemoryError Java heap space: 1505690016 free at Tue Feb 09 15:04:51 CET 2010


Ergänzung: Ja das sieht wie das von dir gezeigte Problem aus. Was mich irritiert sind die Zahlen in den Fehlermeldungen hier, es müsste ja passen.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon Quix0r » Do Feb 11, 2010 9:59 pm

Solch ein Verhalten habe ich auch bereits hier im Forum dokumentiert, dass beim Mergen grosser Blobs deutlich mehr Speicher benoetigt wird, als fuer den Normalbetrieb noetig ist. Vielleicht kann das Mergen hier so umgeschrieben werden, dass nun weniger benoetigt wird.

Welche Klassen/Methoden sind denn dafuer verantwortlich? Dann schaue ich mir das mal an, vielleicht kann man dort einen FIFO o.ae. schreiben - nicht schimpfen wenn ich mit FIFO gleich ganz daneben liege, ich muss mich noch weiter einarbeiten. :)
Quix0r
 
Beiträge: 1347
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon dulcedo » Fr Feb 12, 2010 5:56 am

sixcooler hat geschrieben:ist das nicht wie in OOM nach dem Laden der Index-Dumps?

Ich habe dieses scheitern von 'ensuresize()' beim mergen von größeren blobs, dachte schon ich hätte da ne Löung...
... wurde aber gerade eines Besseren belehrt :-(


Kann ich ihn irgendwie dazu bewegen die blobs unmittelbar zu verkleinern nachdem ich maxFilsize heruntegesetzt habe? Dann könnte ich das Problem umgehen, der peer hat einige blobs mit knapp 32GB.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon sixcooler » Fr Feb 12, 2010 9:59 pm

Sobald die maxFilsize kleiner der summe zweier blobs ist werden diese schon mal nit miteinander gemerged.
Blobs >256MB werden nur miteinander gemerged wenn deren Großenverhältniss kleiner 2 ist.

Um also Blobs von ca 32GB nicht mehr mit was anderem zu mergen sollte die maxFilsize < 46GB sein.

Sind blobs nach dem Datum Ihres Dateinamens älter als ein Monat werden sie alleine Konsolidiert (oder wie man dazu sagt).
Das ist der letzte dann verbleibende Weg die Blobs kleiner zu bekommen.
Ausprobieren kannst Du das in dem du Blob, idx und gap -Files entsprechend umbenennst.

Gutes gelingen :-)
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon dulcedo » Mi Feb 17, 2010 12:14 pm

Funktioniert soweit und spart nach langem DHT-Betrieb viel Speicher wenn alle blobs dadurch angefasst werden.
Es wäre recht praktisch wenn man dieses Umbenennen vereinfachen könnte, beispielsweise im Rahmen einer Löschfunktion die (automatisch) ältere tables löscht und dabei alle blobs mit einem Datum benennt das ihn veranlasst sie baldmöglichst aufzuräumen.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon sixcooler » Mi Feb 17, 2010 5:09 pm

warum und was willst Du löschen?
Das mit dem Umbenennen war ja nur um das Aufräumen schneller herbeizuführen - es passiert eh spätestens wenn blobs älter als ein Monat sind.
Bei der 'Dynamik' vom dht kann man aber evtl über kleiner Zeiten Nachdenken: ich hab das bei mir (eigentlich zum testen) wöchentlich laufen.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon dulcedo » Mi Feb 17, 2010 10:04 pm

Nun wenn einem peer der Speicher ausgeht kann man die älteste table löschen, oder sonstwie aufräumen. Dann eben auch unmittelbar die blobs aufräumen um den Speicher auch unmittelbar frei zu haben.

Dazu noch eine Grundsatzfrage ich teste gerade wieder das mergen mit unterschiedlichen Dateigrössen.
Was passiert mit einer Datei die grösser als filesizemax ist und deren Datum abgelaufen? Passiert bei der Migration linux/osx nach win oder manueller Änderung.
Eigentlich müsste sie ja in mehrere Teile aufgeteilt werden oder so aufgeräumt dass ihr Inhalt in filesizemax passt; Es entsteht auch immer eine Datei < filesizemax. Ist in diesen Dateien so viel Redundanz dass aus beispielsweise 5 mal 20GB dann 5 mal 5GB werden? So habe ich das mehrmals nun getestet.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon sixcooler » Mi Feb 17, 2010 10:40 pm

dulcedo hat geschrieben:Nun wenn einem peer der Speicher ausgeht kann man die älteste table löschen, oder sonstwie aufräumen. Dann eben auch unmittelbar die blobs aufräumen um den Speicher auch unmittelbar frei zu haben.

Ältere Table-files einfach zu löschen finde ich weniger gut: darin könnten noch gut zu gebrauchende URLs sein
Besser, wenn auch leider nur manuell bei heruntergafehrenem Peer möglich, finde ich das Benutzen von de.anomic.data.URLAnalysis.
Dieses entfernt nur URLs zu denen auch keine Bindungen mehr exisitieren, die also eh nicht mehr gebraucht werden.

dulcedo hat geschrieben:Was passiert mit einer Datei die grösser als filesizemax ist und deren Datum abgelaufen? Passiert bei der Migration linux/osx nach win oder manueller Änderung.
Eigentlich müsste sie ja in mehrere Teile aufgeteilt werden oder so aufgeräumt dass ihr Inhalt in filesizemax passt; Es entsteht auch immer eine Datei < filesizemax. Ist in diesen Dateien so viel Redundanz dass aus beispielsweise 5 mal 20GB dann 5 mal 5GB werden? So habe ich das mehrmals nun getestet.

Blobs werden nicht aufgeteilt - dazu sehe ich auch keinen Grund.
Das dir immer Dateien <filesizemax entsehen halte ich für einen sehr warscheinlichen Zufall :-)
Redundanz ist in einem Blob meines Wissens nach keine. In mehreren Blobs können RWIs mehrfach vorkommen.

Ganz grob - soweit ich das Verstanden habe (mögen mich wissendere korregieren):
Beim DHT-out werden RWIs die erfolgreich verteilt wurden aus den Blobs entfernt in dem sie entsprechend gekennzeichent werden (mit '0' überschrieben).
Hierdurch wird aber das Blob-file noch nicht kleiner.
Beim Konsolidieren einzelner älterer Blobs wird alles was nocht nicht so gekennzeichnet ist, in ein neues Blob geschrieben.
Die 'Leerstellen' werden natürlich nicht kopiert und somit wird das neue Blob kleiner (wenn ordentlich DHT-out darus stattgefunden hat).
Beim Mergen zweier Blobs werden zusätzlich evtl. redundante Einträge zusammengeführt.
Das mit dem DHT ist mittlerweile sehr aktiv - da geht schon ne gute Menge raus :-)
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon Quix0r » Mi Feb 17, 2010 10:59 pm

Das mit DHT ist auch sinnig, Stichwort: Ausfallsicherheit. Was ist wenn mal eine Node wegbricht, also der Betreiber sie nicht mehr hat oder will. Mit weniger DHT-Transfer haette YaCy dann das Problem, dass zu den gecrawlten URLs die RWIs (URL<->Suchwort-Verknuepfung) fehlen und dann muesste aufgeraeumt und erneut gecrawlt werden. Ich denke, wir wollen alle irgentwann mit dem Crawlen fertig werden und nicht alles doppelt und dreifach crawlen... :) Redudanz ueber das gesamt YaCy-Netz ist also sinnig, nur beim einzelnen unnoetiger Platzverbrauch.

So meine 2 Euro-Cent dazu. ;)
Quix0r
 
Beiträge: 1347
Registriert: Di Jul 31, 2007 9:22 am
Wohnort: Krefeld

Re: RowSpaceExceededException: 37.821.436 needed / 994.643.296 f

Beitragvon dulcedo » Do Feb 18, 2010 9:53 am

sixcooler hat geschrieben:Beim Konsolidieren einzelner älterer Blobs wird alles was nocht nicht so gekennzeichnet ist, in ein neues Blob geschrieben.
Die 'Leerstellen' werden natürlich nicht kopiert und somit wird das neue Blob kleiner (wenn ordentlich DHT-out darus stattgefunden hat).

So habe ich das auch verstanden, was mich interessiert ist der spezielle Fall dass beispielsweise eine blob-Struktur mit maximal 32GB in eine mit maximal 2GB umgewandelt werden muss (Migration). Es können natürlich alle relevanten Daten einer 32GB-Datei in 2GB passen aber das muss nicht so sein. Was geschieht nun, er müsste in mindestens 2 Dateien aufteilen, was ich beim Konsolidieren allerdings noch nicht beobachtet habe.
dulcedo
 
Beiträge: 1006
Registriert: Do Okt 16, 2008 6:36 pm
Wohnort: Bei Karlsruhe


Zurück zu Fragen und Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste