neue IndexCell Datenstruktur

[Orbiter]

seit Januar bereite ich eine neue Index-Datenstruktur vor, die weniger IO braucht, schneller ist und man einfach von einem Peer zum anderen kopieren kann.
in http://www.yacy-websuche.de/wiki/index.php/Dev:Segments sind die neuen IndexCell Datenstrukturen eine wichtige Komponente, nun sind sie fertig zum Testen (SVN 5760). Bitte macht mit und schaut mal wie das funktioniert. Dazu müsst ihr folgendes machen:
- entweder mit einem leeren Peer starten, die IndexCell ist dann automatisch default.
- oder in DATA/SETTINGS/yacy.conf den Wert useCell=true setzen, dann wird eine IndexCell generiert und die IndexCollections langsam darein migriert.

in 0.74 soll das dann schon per default an sein. Ich teste nun schon seit drei Wochen und denke es wird nicht mehr so viel schlimmes passieren, aber meistens bringt der 'Flächentest' dann doch wieder einiges hervor.

Bitte macht ein Backup vom DATA/INDEX/freeworld/TEXT Verzeichnis, bevor ihr die Umstellung macht. Nachdem ihr useCell=true gesetzt habt, wird dann ein neues Verzeichnis DATA/INDEX/freeworld/TEXT/RICELL angelegt, der Cache dorthin migiert (wird nur verschoben!) und das Verzeichnis RICACHE gelöscht.

Dann ist es empfehlenswert, den Index Cache zu _verkleinern_ da dieser nicht mehr langsam geflusht, sondern als Dump weggeschrieben wird. Dann geht das schreiben schneller. Ich nehme 50000 Einträge.

Auf meinem Notebook habe ich damit bereits über 2000 PPM bei einer lokalen Indexierung von einem apache auf dem gleichen Rechner geschafft!

[RocketTurtle]

So ist umgestellt auf meinen Peers Hoffe es passiert nichts mit meinem lieben Index

[thq]

SVN5760 lieferte nach 12 Minuten nur noch OOM. Bis dahin hatte ich 3 Suchanfragen abgeschickt. SVN5762 wollte dann nicht mehr starten, die Fehlermeldungen landeten aber nicht im Log. Da das sichern und wiederherstellen ~30 Minuten dauert werde ich das so schnell nicht mehr testen

Edit: Konnte es nicht lassen, eine Seed.db war kaputt, mach dem löschen ist SVN5762 zumindest hochgefahren, vielleicht haben wir ja Glück und die OOMs sind auch weg.

[Orbiter]

5760 lief leider nur unter Windows, aber nicht unter Mac & Linux. Hab ich erst in der S-Bahn gemerkt. Man mag glauben das solche Unterschiede bei pure-java nicht sein können, ist aber trozdem so. Ein schneller Fix hat leider einen neuen Bug eingebaut, der nun mit 5762 auch gefixt sein sollte.

Aber war ja irgendwie klar das es rappelt. Mehr Speicher brauch das ganze aber nicht, eher weniger. Das Problem ist die Migration, das füllt den Cache sehr stark, das könnte die Ursache für die OOM sein. Ich gucke mal ob ich da einen Schutz einbauen kann.

eine ganz einfache Hilfe gegen OOM bei der Migration wird durch Runterstellen der Cache-Größe erziehlt. Hatte ich oben schon geschrieben dass das vorteilhaft ist. thq, wie groß ist dein RWI Cache?

[PCA42]

Kurzes Feedback nach etwas Spielerei:
Auf einem neu aufgesetzten Peer läuft das Ding richtig gut. Hab den Cache mal bei 200.000 gelassen. Ist auch ausreichend Speicher vorhanden. Bin dann mal gespannt, wie lange der Merge der Blobs dauert, wenn die etwas größer werden. Muss wohl mal ein paar GB crawlen

Konzeptbedingt sollte dann ja auch das Busy-Flag nicht mehr kommen, wenn mehr Peers umgestellt werden. Das sollte der DHT-Verteilung dann richtig zu gute kommen.

[Orbiter]

ich glaube die supergroßen Caches sind nicht unbedingt so gut, aber das muss man mal sehen. Wie lange das merge dann bei richtig großen Files dauert weiss ich auch nicht, muss man sehen. Als weiteren Schritt habe ich ja auch noch einen Split vorgesehen, der dann die großen Files wieder kleiner macht, und in so eine art lokale hashtable versetzt. Das Konzept ist fertig, ist nur eine Zeitfrage.

Zu dem Speicherverbrauch: patch dazu ist nun in SVN 5763.

[PCA42]

Wenn wir schon mal am Basteln sind: Kann vielleicht wieder eine Funktion alla "StoragePeerHash" wieder Einzug halten? -> Der Cache wird samt zugehöriger URLs auf einen anderen Peer geschrieben. Schon habe wir Remote-Crawl-Only-Peers.

[Orbiter]

ich weiss nicht, hier würde ich das anders machen. Mann kann ja die IndexCell-Dateien einfach auf einen anderen Peer in dessen RICELL-Verzeichnis kopieren, und schon sind sie quasi gemerged. Da fehlen nur noch die URL-db Dateien, die müsste man auch mergen können, indem man sie besser (unterscheidbar) benennt. Das 'Rüberkopieren der Index-Dateien halte ich für viel besser als nur kleine Stücke zu schicken. Man könnte also besser sowas wie einen buld-transfer Prozess aufbauen.

[Huppi]

4 Peers umgestellt, bisher sieht alles gut aus. Cache-Einstellungen auf 50.000

Ich kann aktuell nur sporadisch in die Logs hereinschauen, vermutlich erst am Sonntag wieder.

[PCA42]

Ich möchte die Datenpakte, die da den Besitzer wechseln, auch nicht zu groß haben. Sie sollen schon die Größe des üblichen DHT-Transfer sprengen, aber nicht in die zig-MB gehen.
Grund: Man könnte so einen Peer an einer DSL2000 Leitung munter crawlen lassen und immer wenn der Puffer voll ist (10000 RWI entsprechen so ca. 2-3 MB ungepackt) alles versenden. Einfach als "großen" DHT-Transfer. Das gibt ein überschaubaren Zeitraum zwischen den Transfers. Und wenn der PC einfach ausgeschaltet wird oder Yacy unsanft beendet wird ist auch nix passiert. Der Peer sollte beim Start, wenn der Parameter gesetzt ist, komplett zurückgesetzt werden und dann als Remote-Crawler loslegen. Diese Funktionalität war ja schon mal gefragt. Siehe auch mal den Thread "Sonntagcrawl".

[thq]

thq, wie groß ist dein RWI Cache?

Den hatte ich direkt nach dem Start von 60.000 auf 50.000 geändert.

SVN5763 läuft besser, aber der Speicher sollte noch etwas früher "freigegeben" werden, hatte schon wieder ein OOM. Den Peer um die 20MB mehr Speicher lassen und es dürfte keine Probleme mehr geben.

[Orbiter]

hab den minimalen Speicher weiter vergrößert und noch ein paar andere Sachen eingebaut, u.a. Doppelaufwendung beim Fingerprint-Berechnung rausgemacht. SVN 5764

[Orbiter]

Intranet-Indexierung (apache auf gleichem Notebook):

PerformanceGraph.png (17.87 KB) 1348-mal betrachtet

mit rund 1/2 Gigabyte Index:

Code: Alles auswählen

admins:RICELL admin$ ls -l
total 1352968
-rw-r--r--  1 admin  staff  546742940  1 Apr 21:52 20090401195006.index.blob
-rw-r--r--  1 admin  staff  145970400  1 Apr 22:07 20090401200656.index.blob
admins:RICELL admin$


[Huppi]

doch ein Blick vor Sonntag:
mit SVN5762 viele Short Mem Cycles auf 2 der vier Peers:

W 2009/04/01 22:27:22 PLASMA Thread 'de.anomic.plasma.plasmaSwitchboard.deQueueProcess' runs short memory cycle. Free mem: 8991 KB, needed: 16144 KB

I 2009/04/01 22:27:23 MEMORY performed necessary GC, freed 0 KB (requested/available/average: 16144 / 7643 / 0 KB)

W 2009/04/01 22:27:23 PLASMA Thread 'de.anomic.plasma.plasmaSwitchboard.deQueueProcess' runs short memory cycle. Free mem: 7640 KB, needed: 16144 KB

I 2009/04/01 22:27:24 MEMORY performed necessary GC, freed 0 KB (requested/available/average: 16144 / 6904 / 0 KB)

W 2009/04/01 22:27:24 PLASMA Thread 'de.anomic.plasma.plasmaSwitchboard.deQueueProcess' runs short memory cycle. Free mem: 6902 KB, needed: 16144 KB

I 2009/04/01 22:27:25 MEMORY performed necessary GC, freed 0 KB (requested/available/average: 16144 / 6899 / 0 KB)

W 2009/04/01 22:27:25 PLASMA Thread 'de.anomic.plasma.plasmaSwitchboard.deQueueProcess' runs short memory cycle. Free mem: 6897 KB, needed: 16144 KB

I 2009/04/01 22:27:26 MEMORY performed necessary GC, freed 0 KB (requested/available/average: 16144 / 6892 / 0 KB)

W 2009/04/01 22:27:26 PLASMA Thread 'de.anomic.plasma.plasmaSwitchboard.deQueueProcess' runs short memory cycle. Free mem: 6890 KB, needed: 16144 KB

I 2009/04/01 22:27:28 MEMORY performed necessary GC, freed 2073 KB (requested/available/average: 16144 / 8961 / 0 KB)

Ich versuche ein Update

1 Peers mit kleinem Index läuft prima, 1 Peer ist über das Webinterface nicht mehr erreichbar.

Die Performance-Werte sind ja echt beeindruckend. Wenn man das mit den Anfangswerten in der Frühphase des Projektes vergleicht, ist das der Hammer!

[Huppi]

Update auf 3 Peers auf SVN5767, zwei sind über das Webinterface nicht zu erreichen, einer läuft zunächst super.
Ich warte darauf, ob sich die zwei bis morgen abend berappelt haben.

[sixcooler]

Die geringere IO-Last ist enorm!
Wieder einmal eine riesen Verbesserung - Super!

Der peer auf dem ich die IndexCell Datenstruktur probiere läuft super smooth

Mir viel auf, das der Wert für die Anzahl der Wörter sich stark unterscheidet
zwischen dem was PerformanceGraph.png anzeigt und dem was WatchCrawler_p.html
und Banner.png anzeigen.
Der wert der letzteren Beiden scheint trotz nur DHT-out nicht zu fallen.
Kann ich irgendwie erkennen wann die Migration abgeschlossen ist?

Cu, sixcooler.

[Huppi]

Ich denke, bei mir ist's die Migration, die den Speichermangel verursacht. Evtl. migriere ich einfach auf einem anderen Rechner mit mehr Speicher (4GB statt 512MB).

[RocketTurtle]

Migration war ein voller Reinfall auf allen Peers, aber wohl aus Speichermangel

Trotzdem - habe mich entschieden das neue indexCell ab jetzt trotzdem zu benutzen. Meine Erfahrung ist auch: läuft soft und meine Peers hören nicht mehr auf zu crawlen und crawlen schneller.

[Orbiter]

eiei, vielleicht hilft es auch, den cache agressiv klein zu stellen, das sollte trotzdem gehen. sagen wir 10000 Einträge? ggf. auch weniger.

[Phiber]

So habe das jetzt auch mal ausprobiert und bin am migrieren. Nachdem er sich am Anfang immer wegen OOM festgefahren hat, hab ich dann einfach wirklich RWI-Cache auf 4'000 runtergesetzt und die Timings hochgesetzt, jetzt gehts fein. Vielleicht ist das jetzt wieder zu tief, 10k könnten auch fein sein.

Also Peer: 2GB Java-VM, 26Mio Links, 4000RWI-Cache -> Er braucht 800-1700MB RAM, CPU 20-30% gut belastet stärker als sonst.

[Orbiter]

kleiner Hinweis zur Migration: das ist kein 'full flush' sondern ein sanftes Aufsammeln. Das geht so, dass jedesmal wenn ein Wort in der alten collection gefunden wird, dieses dort gelöscht und bei der index cell zugefügt wird. Es wird also nur was migriert, wenn auch was abgefragt wird. Speziell beim Indexieren ist das so.

Wie weit das ist kann man an der Größe der collections.index sehen, die schrumpft nämlich. Wenn sie auf null ankommt, wird das ganze RICOLLECTIONS Verzeichnis gelösch!

Das wird aber bei der langsamen Migration nicht passieren, weil immer was übrig bleibt. Hier hilft nur ein forciertes Aufsammeln, das wollte ich aber nicht einbauen weil dann die IO hoch geht und hoch bleibt, bis die Migration durch ist.

[PCA42]

Das wird aber bei der langsamen Migration nicht passieren, weil immer was übrig bleibt. Hier hilft nur ein forciertes Aufsammeln, das wollte ich aber nicht einbauen weil dann die IO hoch geht und hoch bleibt, bis die Migration durch ist.

Kann man das vielleicht wieder als externen Aufruf realisieren? Das hat doch auch gut mit der URL-Bereinigung funktioniert. Dann ist auch mehr Speicher vorhanden, da für die Umstellung auf die Cell-Struktur die URLs ja nicht geladen werden müssen.

[Orbiter]

ich glaube das die eine Methode, die da ist ausreicht und für alle die beste Lösung ist. Ich muss ja auch woanders noch viel bauen.

[thq]

SVN5768 hat bei mir mehrere GB an Daten gelöscht. Hatte eine 4.5GB, eine 2,7GB und ein bis zwei kleinere Blob-Dateien. Der Peer lief nur mit DHT-In bis das im Log stand

Code: Alles auswählen

W 2009/04/03 08:02:00 HeapReader verification of idx file for E:\yacy\DATA\INDEX\freeworld\TEXT\RICELL\20090403055914.index.blob failed, re-building index

Jetzt liegt im RICELL Ordner nur noch eine 2.9GB große Blob-Temp-Datei und eine mit 70KB. Auf beiden wurde seit Stunden nicht mehr zugegriffen.

[Orbiter]

mehr Meldungen im Log dazu?
Die BLOBs sollten übrigens nicht so groß werden. Dazu gab es eine Sperre, die allerdings nicht funktionierte und in SVN 5773 gefixt wurde.
idx-files sind übrigens echte Wegwerfware, das macht der auch bei jedem Startup, denn sie sind nur dazu da schneller starten zu können. Wenn die IDX-Files nicht passen werden sie auch weggeworfen, das sagt dein Log aus. Allerdings sollten diese nicht so sehr groß werden.
Da jetzt ja ständig gemerged wird, flukturiert die verzeichnisgröße auch stark, wenn zwei 100MB große Dateien gemerged werden, ist temporär eben 200MB mehr da. Hast du das beobachtet oder was anderes?

[thq]

Nein, das Log gibt nicht mehr her. Das war die letzte "Blob-Zeile" im Log, bis auf die von beenden des Peers, nach ein weiteren Neustart gibt es nur noch eine Blob-Datei mit 129KB. Ob die großen Blob-Dateien vorher Index-Dateien waren weiß ich jetzt nicht. Auf der Festplatte sind noch gut 200GB platz, Temp-Dateien sollten also nicht stören.

Werde jetzt das Backup wiederherstellen und erstein mal auf Cell verzichten.

[Orbiter]

wäre mir lieber das noch ein wenig zu analysieren. Die Größe der Dateien finde ich übrigens enorm, wir brauchen doch sonst monate um auf eine ähnliche Collection-Größe zu kommen. Da muss die Migration ja rasant abgelaufen sein.
Ich hoffe die neue Datenstruktur und die Handhabung der Dateien wurde nicht missverstanden: die werden ständig neu geschrieben, eben gemerged und dann gelöscht. Alle idx- und gap- Dateien dienen nur für einen schnellen Start-Up und werden immer gelöscht.

[thq]

Also ich habe den Ordner ja hier und da mal beobachtet wenn was zusammengefügt wurde, also die großen Dateien waren schon die Finals und keine Temps ...

Das einzige was ich gemacht habe waren so 60 Suchanfragen wo ich wusste das mein Peer viele Daten davon hat. Diese musste ich aber auch gut verteilen, vorher konnte ich mehr hintereinander absetzen, aber ok, die Migration braucht halt auch Speicher ... Jetzt kommt es, mir ist gerade eingefallen das mein Peers mit maxCollection 8 läuft, das könnte die Größe der Dateien erklären aber deswegen sollte keine Datei oder ein Index Problem bekommen (Größe).

Auf die maxCollection 8 möchte ich nicht verzichten, weil mit 7 mir zu viele Daten aussortiert werden. Das ändert sich zwar mit Cell aber in wie weit das identisch ist weiß ich nicht. So gesehen ist mein Peer vielleicht nicht der richtige zum finalen testen der nächsten YaCy Version.

[Orbiter]

vielleicht eignet er sich gerade deswegen gut. maxCollection 8 bedeutet natürlich, dass einzelne RWIs nicht mal so um die 20 MB brauchen, sondern das vierfache, 80 MB. Das erklärt dann auch deine OOM, da ich ja aufgrund der Annahme dass immer 30 MB frei sein sollten um die 20MB zu schaffen bei dir dann zu wenig da ist.

Bei den IndexCell Daten gibt es keine Begrenzung der Index-Größe. Das könnte natürlich dann in Zukunft für neue Probleme sorgen. Ggf. muss man hier wieder eine neue künstliche Begrenzung einbauen, oder die RWIs nur laden wenn genügend Speicher da ist. Kommt auf meine Liste.

Du hast aber doch eh schon total viel Speicher drin, wundert mich dann doch dass es da hapert.

[thq]

Was heißt viel Speicher, der Peer hat 1,4GB. Die Speicherverwaltung für die "alte" Collections hatte ich mir etwas umgebaut, von der Seite hatte ich Ruhe was die OOM angeht. Aber durch das den Wechsel oder dem verschieben nach Cell greift der ja auch nicht mehr und daran habe ich nicht gedacht.

Ich kann zur Zeit auch nicht einfach updaten weil ab SVN5771 ich wahrscheinlich Probleme mit FlexTable.java / SplitTable.java bekomme und ich nicht wirklich Zeit habe mich da durchzuwurschteln.

Mit SVN5768 hatte ich auch keine Probleme mehr was die OOM angeht, ok ich war etwas vorsichtiger beim Suchen, aber vielleicht hatte ich auch die dicken Brocken schon durch.

[Orbiter]

oh, ich sehe gerade..

Code: Alles auswählen

// access the file and read the container
        file.seek(pos);
        final int len = file.readInt() - index.row().primaryKeyLength;
        if (MemoryControl.available() < len) {
            if (!MemoryControl.request(len, true)) return null; // not enough memory available for this blob
        }

Die BLOBs schützen sich selbst vor OOM. Wenn zu viel drin ist folgt temporäre demenz durch ignorieren bis wieder mehr RAM da ist. Das könnte dazu führen, dass man häufige Wörter nicht mehr findet .. als wären sie in einer dynamischen stopwordliste.

[soleil]

Sehe ich es richtig, daß die alten Ricollection-Dateien selbst bei der Migration nicht kleiner werden? Die etwa 14GB des RICOLLECTION-Verzeichnisses bleiben bei mir gleich, nur die Datei collection.index wird langsam kleiner. Gleichzeitig ist das RICELL-Verzeichnis sehr schnell auf 2GB angewachsen. Bloß habe ich auf der Platte nicht genug Platz, um den Index zweimal zu speichern...

[Phiber]

Sehe ich es richtig, daß die alten Ricollection-Dateien selbst bei der Migration nicht kleiner werden? Die etwa 14GB des RICOLLECTION-Verzeichnisses bleiben bei mir gleich, nur die Datei collection.index wird langsam kleiner. Gleichzeitig ist das RICELL-Verzeichnis sehr schnell auf 2GB angewachsen. Bloß habe ich auf der Platte nicht genug Platz, um den Index zweimal zu speichern...

Jup der alte Index nimmt nicht ab. Der neue aber schon zu, nach so 3x12h online (dht + remote100ppm):

RICOLLECTION: 29GB -> 29GB
RICELL: 0 -> 9.1GB

Der Graph scheint sich bedeutend flinker zu bewegen, RWI's immer in Bearbeitung. Ob jetzt alles wirklich schneller läuft und was es bisher gebracht hat ist noch schwer zu urteilen, da ich schon lange nimmer lokal Crawle.
Gibt es irgendwo Statistiken für DHT?

Ps. Und an alle die eben jetzt auch noch migirieren wie gerade zum Beispiel bluumi: WIrklich RWI-Cache runter auf x000 und erstmal nen halben Tag laufen lassen nur mit DHT ohne Crawls, auch keine Remote. Und dann in nem zweiten Schritt erst wieder erhöhen, dann sollte es auch mit wenig RAM klappen.

[PCA42]

Sorry, das ich das nochmal aufwärme: kann man da nicht vielleicht doch eine Offline-Funktion für die Konvertierung in die Cell-Struktur einbauen? Einigen hätte das viel Zeit fürs ausprobieren erspart.
Einmal umwandeln und fertig. Nicht mit Try'n'Error die passenden Speichereinstellungen suchen.

[anomica]

Ich war gestern abend zu optimistisch und hielt es für eine gute Idee, yacy einen Neustart ausführen zu lassen, sozusagen bevor der Memory-Mangel wiederkommen konnte. Leider stellte ich am Morgen fest, dass der Neustart mit Fehlern im Log abgebrochen worden war. Weitere Starts führten nur zum gleichen Ergebnis.
Mit dem Backup fing ich nochmal an. Am Anfang längere Zeit laufend Beschwerden über nicht genügend Speicher durch GC freigemacht. Irgendwann beendete ich, um von 5779 auf 5782 zu wechseln. RWI-Cache auf 1.000 und Remote-Crawls auf 10, nach Phibers eindringlicher Warnung jetzt erstmal auf "aus" bis morgen früh.

Viel Glück allen Migrierenden!

[Orbiter]

die ricollection-Dateien werden nicht kleiner, sorry. Nur der Index. in den collection-Dateien werden die Dinger nur als gelöscht markiert. Wenn der Index ganz auf null steht wird alles gelöscht. Ansonsten empfehle ich das manuell zu tun, wenn der Index auf eine kleine Größe angekommen ist und nicht weiter schrumpft.

[Phiber]

die ricollection-Dateien werden nicht kleiner, sorry. Nur der Index. in den collection-Dateien werden die Dinger nur als gelöscht markiert. Wenn der Index ganz auf null steht wird alles gelöscht. Ansonsten empfehle ich das manuell zu tun, wenn der Index auf eine kleine Größe angekommen ist und nicht weiter schrumpft.

Ah Sorry ich habe mal wieder schlecht gelesen, typisch. Weiter oben hast du ja schon geschrieben, dass die collection.index schrumpft und nicht die einzelnen collection-Dateien.
Ist das nun so richtig oder wird eben auch in der collection.index nur markiert? Weil diese ist zwar geschrumpft aber wirklich marginal (307.3MB->295.7MB). Nunja, ist ja auch eine Soft-Migration

[bluumi]

Gibt es irgendwo Statistiken für DHT?

Würde mich auch "brennend" interessieren .. es ist ja ganz "schön" zu beobachten dass die Peers fleissigst wie Bienen/Ameisen Seitenweise "INDEX TRANSFER DISPATCHER" und "PLASMA Received xx Entries" Zeilen auflisten, aber ich würde gerne "vergleichen"

Vergleichen
- mit anderen Top10
- ob DHT Transfer zu oder ab nimmt

[soleil]

die ricollection-Dateien werden nicht kleiner, sorry. Nur der Index. in den collection-Dateien werden die Dinger nur als gelöscht markiert. Wenn der Index ganz auf null steht wird alles gelöscht. Ansonsten empfehle ich das manuell zu tun, wenn der Index auf eine kleine Größe angekommen ist und nicht weiter schrumpft.

Wäre es viel Arbeit, eine Routine zu schreiben, die die Ricollection-Dateien komprimiert, oder würde es nur ein paar Zeilen brauchen? Das könnte ja ebenso wie das Löschen nicht referenzierter URLs von außen angestoßen werden.

À propos, funktioniert das URL-Bereinigen nach der RWI-Migration noch? Falls mir der Platz zum Migrieren aller RWIs zu knapp wird und ich viele löschen muß, könnte ich auch gleich noch die nicht mehr benötigten URLs entsorgen...

[Phiber]

Sorry, das ich das nochmal aufwärme: kann man da nicht vielleicht doch eine Offline-Funktion für die Konvertierung in die Cell-Struktur einbauen? Einigen hätte das viel Zeit fürs ausprobieren erspart.
Einmal umwandeln und fertig. Nicht mit Try'n'Error die passenden Speichereinstellungen suchen.

Ist mir gerade eingefallen:

Vielleicht kann in die Blacklist DB-Überprüfungsfunktion eine Option reinbauen, bei welcher dann beim durchgehen alles migriert wird?
Also die Blacklist Linküberprüfung als Migration missbrauchen um längerfristig dann doch noch seinen kompletten Index migriert zu haben. Ich kenne mich ja zwar nicht so aus, aber bei der Softmigration vorallem durch DHT wird es wohl so enden, dass einige bestimmte Bereiche einfach überhaupt nie durch DHT oder ähnliches migriert werden, oder es braucht exponentiell lange
Oder ist da die vertikale DHT-Verteilung schon so stark, dass sicher alles früher oder später (sagen wir <6 Monate) softmigriert wird?

[Quix0r]

So nebenbei gefragt - ich weiss, ich durchloechere euch schon, sorry: Ich habe useCell=true gesetzt, kann ich das wo im Logfile nachvollziehen? Wuerde mich mal interessieren.

[Orbiter]

im Log steht nur was über das Öffnen der BLOBs in DATA/INDEX/freeworld/TEXT/RICELL. Speziell in das Verzeichnis kannst du auch gucken um zu sehen was da bislang produziert wurde.

[Quix0r]

Danke fuer den Tipp.

[bluumi]

Hier steht ja des öfteren dass man mit der neuen RiCell Struktur einen kleineren Cache einstellen soll, gilt dies auch für einen komplett frischen Peer? Wenn ja, so sollte man an der Default Einstellung schrauben Denn als ich mir einen neuen SpielPeer eröffnet habe, habe ich nicht "schlecht" gestaunt, dass der ja noch bei 100'000 bei Cache steht. Zwar läuft er damit auch, da er noch kaum etwas zu tun hat, aber falls 100'000 nicht mehr gut für den Betrieb ist, währe diese vielleicht Default niedriger zu setzten.
Oder gilt dieses "auf 1'000" setzten nur während den Umstellungs Tagen?

[Phiber]

Also ich habe meinen peer jetzt auf etwa 30k RWI-Cache eingependelt bei 28 mio links bei 2.1gb. Nur Remotecrawlen und stark DHT.

Wenn ich etwas lokal crawle rennt er in nen üblen oom, aber habe das dann sein gelassen mit rumprobieren

Eben 1k ist wirklich eine Untertreibung, aber fürs erste mal booten mit Riccell bei nem vollen Peer eben durchaus angebracht da er damit trotzdem noch eine Weile lang den RAM hochjagt.

Zu den 100k, wenn es für einen neuen Peer passt ist das ja ok. Jemand der seinen Peer etwas länger betreibt muss eh auch den Vm-Ram erhöhen und Anpassungen machen. Will man den Betreiber eines Peers komplett vom Admin-Menü verschonen wird man einiges an dynamischen Anpassungen bringen müssen und auch wirksame Speicherplatzbegrunzungen einführen müssen, wie im andern Thread wieder mal diskutiert. Das ganze gabs ja schon vor 3-4 Monaten. Und einfach alles abschalten ist ja auch nicht die Lösung, wenn man damit nicht mehr Remote Suchen kann.

[Quix0r]

Ich denke, die Diskussion wird langsam OT? Soweit scheint die neue Cell-Struktur zu klappen, bis auf dieses:

I 2009/04/13 03:22:34 ECOTABLE /home/quix0r/yacy/DATA/INDEX/freeworld/TEXT/METADATA/urls.20090406143126714.table: EcoTable /home/quix0r/yacy/DATA/INDEX/freeworld/TEXT/METADATA/urls.20090406143126714.table has table copy DISABLED

Ist da schlimm?

[PCA42]

Also ich habe meinen peer jetzt auf etwa 30k RWI-Cache eingependelt bei 28 mio links bei 2.1gb. Nur Remotecrawlen und stark DHT.

Bin durch Probieren bei dem selben Wert gelandet. Kleinerer Cache wird zu oft geleert. Und wenn ich den größer mache, gehen die Ppm in den Keller.

@Quix0r: Nein, ist nicht schlimm. Die table copy bewirkt, dass die komplette Datenbank im Speicher abgelegt wird. Das ist für kleine DBs vorgesehen. Ohne table copy wird nur der Index im Speicher gehalten.

[Quix0r]

Okay, danke. Ich sollte mir also mehr RAM zulegen... Hab 2 GB schon.

[PCA42]

Okay, danke. Ich sollte mir also mehr RAM zulegen... Hab 2 GB schon.

So viel Speicher kann du garnicht haben. Beispiel: 1 Mio URLs ohne table copy: 16 MB, 1 Mio URLs mit table copy: 528 MB.

Btw: Das fällt mir ein alter Witz aus Windows 3.1-Zeiten ein. Kommt eine gute Fee zu einem Windows-User. Fee: Du hast drei Wünsch frei. User: Ich hätte gern einen RAM, der nie voll ist. Fee: *Pling.* So soll es sein. Und nun zu deinen zweiten Wunsch. User: Ich hätte zur Sicherheit gerne noch einen....

[Quix0r]

LOL.

Aber das hast du mich vielleicht nicht verstanden: Meine Linux-Maschine muss Speicher auslagern, wenn ich FF, YaCy, Pidgin und IceDove + Lighttpd + MySQL-Server (bin Webseiten-Entwickler) gleichzeitig gestartet habe. Deswegen will ich mir mehr RAM holen.