/api/termlist_p.xml

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.

/api/termlist_p.xml

Beitragvon sixcooler » Di Aug 30, 2011 2:13 am

Hallo,

das mein Peer in letzter kaum lange stabil läuft hatte ich, glaube ich, schon in ein paar Beitrage hier geschrieben.

Angeregt durch Orbiters werk /api/termlist_p.xml hatte ich das ja wie hier beschrieben schon etwas ausprobiert.

Weil das bisher noch nicht so recht die Wende brachte, hab ich heut also noch mal /api/termlist_p.xml?mincount=250000&delete= ausgeführt:

W 2011/08/29 17:26:24 TERMLIST finished termlist_p -> terms: 17
W 2011/08/29 17:26:24 TERMLIST maxterm: E7W_6W8-L-QR
W 2011/08/29 17:26:24 TERMLIST maxcount: 625040
W 2011/08/29 17:26:24 TERMLIST termnumber: 24462790
W 2011/08/29 17:26:24 TERMLIST totalmemory: 23342034

Das davon schon wieder so vielevorhanden waren, nach nur 2 Tagen, überaschte mich schon sehr. Noch mehr aber das der Term 'E7W_6W8-L-QR' schon wieder ganz vorne war - wo er doch schon beim ersten Versuch mit einem count von gut 4.5 Mio als einer der ersten gelöscht wurde.

In diesen 2 Tagen crawlte der Peer so gut wie nix - das muss also alles via DHT reingekommen sein.
@Orbiter: ich denk wir brauchen hier eine grunsätzlichere Lösung. Ich würde mir ja auch eher ein Shrink (by date?), als diesen Haircut wünschen.

Nach dem das alles längst durch war, stand ein "RICELL-shrink4/rewrite" an, der leider auch prompt nach ca 10% aufgab:
ReferenceIterator lost entry '[B@19958bf9' because of too low memory: net.yacy.kelondro.index.RowSpaceExceededException: 40 bytes needed for importRowSet: alloc != b.length - exportOverheadSize: 1606359376 free
Das 'alloc != b.length' sieht für mich eher nach einem defekten Blob aus, denn wie ein Speichermangel.

Gut das ich ein Backup hab - also zurück gespielt, das Zeuch und da kam dann natürlich auch das "RICELL-shrink4/rewrite" - und leider auch mit dem Fehler.

Der Fehler war also schon vor meinen /api/termlist_p.xml-Versuchen da.
Weil andere Blobs ja auch welche haben könnten, hab ich dann mal die Blobs in ihren Dateinamen 'zurückdatiert' - auf das sie alle mal 'geshringt' werden.
Es kam natürlich wie es musste - vorallem die dickeren Blobs hatten Fehler.

Nun hatte ich also zwar meine Blobs um ca 30G erleichtert - aber immerhin das 'Gefühl' halbwegs brauchbares zurückbehalten zu haben.
Mit diesem 'Gefühl' der sauberen Blobs hab ich dann also noch mal /api/termlist_p.xml?mincount=250000&delete= ausgeführt, da große URL-Mengen nach dem zurückspielen des Backups wieder wieder vorhanden sein sollten:

W 2011/08/30 01:58:57 TERMLIST finished termlist_p -> terms: 181
W 2011/08/30 01:58:57 TERMLIST maxterm: AbbiA0S2iDXF
W 2011/08/30 01:58:57 TERMLIST maxcount: 2174368
W 2011/08/30 01:58:57 TERMLIST termnumber: 8272846
W 2011/08/30 01:58:57 TERMLIST totalmemory: 4023405740

Um nun noch mal zu prüfen ob die Blobs gelitten haben, habe ich nochmal die Blobs in ihren Dateinamen 'zurückdatiert' und 'shrinken' lassen.
Im groben sieht es nun alles fein aus lediglich 2-3x etwas wie
kelondroRow row not well-formed: rowinstance[0] = �=�^DS�^@^@hde^C / [-32, 61, -28, 4, 83, -101, 0, 0, 104, 100, 101, 3,]
war aufgetaucht.
Evtl findet ja jemand die Zeit mir zu berichten ob das besorgnisseregend ist.

Hat eigentlich noch wer /api/termlist_p.xml probiert?

Cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon Orbiter » Di Aug 30, 2011 2:38 pm

ggf. wäre ein permanenter Haircut sinnvoll, das würde dann bei jedem index merge schauen ob die Ergebnismenge nicht zu groß ist. Das würde dann die Vorgehensweise wie bei der letzten Datenstruktur, wo sowieso immer ein aufgrund der Architektur notwendiger Haircut statt gefunden hat simulieren. Als Ergebnis würden dann die großen Indexmengen die so schnell anwachsen auch nicht mehr so arg schnell zugeschüttet werden.

Filter ist ok, aber was ist wenn ein Filter nicht mehr hilft?
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: /api/termlist_p.xml

Beitragvon sixcooler » Di Aug 30, 2011 3:31 pm

Hallo,

Orbiter hat geschrieben:Filter ist ok, aber was ist wenn ein Filter nicht mehr hilft?

warum sollte ein Filter nicht mehr helfen?

Ich würde jegliche automatisierte lösung begrüßen - schon weil ich denke das kaum jemand die Api nutzt.
Du weisst sicherlich am besten was sinnvoll zu machen ist.

Diese schnellwachsenden Index-Inhalte kommen zwar auch schnell wieder - dennoch ist es verwirrend nach einem Haircut für populäre Suchbegriffe keine lokalen Treffer zu haben. Daher meine Bevorzugung zum shrinken.
Stelle ich mir das zu einfach vor, die Menge der URL-Referenzen nach einem Sinnvoll erscheinenden Kriterium zu sortieren, die 10.000-100.000 besten zu behalten und den Rest nach /dev/null zu geben?
Evtl. könnte man dafür sogar das Ranking der Suche nutzen.

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon sixcooler » Di Aug 30, 2011 11:54 pm

Hallo,

ich habe nun mal ein wenig dazu herumgebastelt und einen Shrink nach Reference.lastModified() ausprobiert.
Könnte das nicht ein brauchbares Kriterium sein? - Es ist einfach schon so schön vorhanden :-)
Code: Alles auswählen
    private static <ReferenceType extends Reference> void shrink(final ReferenceContainer<ReferenceType> c) {
       final int max = 50000;
       if (c.size() < max) return;
       long mod;
       List<byte[]> urlhashes;
       ReferenceType r;
      final TreeMap<Long, List<byte[]>> tm = new TreeMap<Long, List<byte[]>>();
       final Iterator<ReferenceType> i = c.entries();
       while (i.hasNext()) {
          r = i.next();
          mod = r.lastModified();
          urlhashes = tm.get(mod);
          if (urlhashes == null) urlhashes = new ArrayList<byte[]>();
          urlhashes.add(r.urlhash());
          tm.put(mod, urlhashes);
       }
       for (final List<byte[]> hashes : tm.values()) {
          for (final byte[] urlhash : hashes) {
             c.remove(urlhash);
             if (c.size() < max) return;
          }
       }
    }

Den hier genutzte maximal-Wert von 50.000 hatte ich nur gewählt um auf meinem kleinen peer auch testen zu können - es scheint recht gut zu funktionieren.
Der Wert versteht sich in diesem Fall aber pro Blob-File - womit die Überlegungen zu einem geeigneten Wert wieder anstehen.

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon Orbiter » Mi Aug 31, 2011 10:43 am

das ist schon mal sehr gut, nur mit dem TreeMap killst du Doubletten die das gleiche Datum haben. Und die Daten sind im Index aufgrund von Platzgründen nur tagesgenau...

Es gibt aber da geeignete Datenstrukturen in YaCy um so zu sortieren, bsp. OrderedScoreMap<E>, wobei E das <ReferenceType extends Reference> sein muss und du die OrderedScoreMap<ReferenceType extends Reference> dann mit einem Comparator auf <ReferenceType> initialisieren musst. Dieser Comparator bildet dann den Datumsvergleich ab. Hört sich kompliziert an, ist es aber gar nicht.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: /api/termlist_p.xml

Beitragvon Orbiter » Mi Aug 31, 2011 10:49 am

was fasel ich da, du brauchts nur eine TreeSet mit so einem Comparator. Und einem Max-Element das du benutzt um keine größeren Elemente mehr in das Set einzufügen wenn es schon 'voll' ist und ein neues Element größer als das Max ist.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: /api/termlist_p.xml

Beitragvon sixcooler » Mi Aug 31, 2011 1:15 pm

Hallo,

da werden keine Doubletten die das gleiche Datum haben gekillt.
Ich nutze eine TreeMap<Long, List<byte[]>> mit dem lastModified() als Key für die Sortierung und einer Liste der UrlHashes um eben nix zu killen.
Soweit ist das schon in Ordnung.

Sicher lässt sich das noch eleganter erledigen, immerhin werden so alle UrlHashes noch mal gespeichert, wobei wir eigentlich nur die Menge derer bräuchten, die auch gelöscht werden sollen.

Meine Eigentlich Frage war ja aber, ob das lastModified() auch eine sinnvolle Größe ist.
Und wie man das Maximum setzen könnte - als Referenzmenge / Blob.

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon Orbiter » Mi Aug 31, 2011 4:22 pm

au mann du hast natürlich recht, dein Code sieht sehr ordentlich aus!
Für das ArrayList<byte[]> gäbe es ggf. einen Ersatz der weniger Platz braucht (ggf. RowSet geeignet weils nicht den Object Overhead für jedes byte[] hat) aber ansonsten ist das genau richtig.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: /api/termlist_p.xml

Beitragvon sixcooler » Mi Aug 31, 2011 5:08 pm

Hallo,

wie das RowSet da einzusetzen ist blicke ich leider nicht spontan, werde es aber später mal genauer ansehen.
Wenn Du da schon eine Vorstellung hast - nur zu.

Hast Du Dir schon zum Maximum der Referenzen Gedanken gemacht?
Da hier nur die Referenzanzahl eines Blobs betrachtet wird, ist die Abschätzung eines Sinnvollen Wertes ja nicht so einfach.
(Das war es ja schon nicht beim Haircut, wo die Gesamtmenge betrachtet wurde)

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon sixcooler » Di Sep 06, 2011 11:59 pm

Hallo,

ich wollt nur mal kurz berichten das ich an diesm Ding noch dran bin.
Die Idee an sich halte ich nach wie vor für sehr gut geeignet Stabilität und nicht zu letzt auch die Suchperformance zu erhöhen.
Aktuell limitiere ich die die Refernzen pro Blob und Term zu 100.000 - das scheint mir ein gut funktionierender Wert zu sein und andere Meinungen dazu scheint es ja nicht zu geben?

Nur das Löschen unter Beibehalt der Sortierung hat sich als zu kostspielig erwiesen: ich hatte schon Merges von einigen Stunden.
Nun hab ich einen Versuch des löschens ohne den Beibehalt der Sortierung gestrickt - sortiert wird aber natürlich abschliessend.

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon Orbiter » Mi Sep 07, 2011 12:45 pm

ich vermute dass das "c.remove(urlhash);" hier ein Performanceproblem ist, weil das intern so funktioniert dass der ReferenceContainer ein byte[] ist und die References darin ebenfalls byte[]-Stücke sind. Werden diese gelöscht, so muss die Lücke sofort geschlossen werden und zwar mit einem arraycopy. Das wird viel Performance kosten.

Ok dagegen versuche ich einen Hack, der das ganze massiv beschleunigen sollte: es gibt nun eine neue Methode delete(final List<byte[]> keys) die sehr schnell eine Liste von Keys löscht. Bitte probier mal
Code: Alles auswählen
for (final List<byte[]> hashes : tm.values()) {
          c.delete(hashes);
       }

Damit dieses delete dann nur unterhalb des 'max' wertes belibt, musst du die 'hashes' Menge schon vorher begrenzen.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: /api/termlist_p.xml

Beitragvon sixcooler » Mi Sep 07, 2011 12:59 pm

Hallo,

ich hatte mich evtl nicht ganz deutlich ausgedrückt - ich hab das auch schon alles am laufen.
Wie Du hab ich was um vom Ende her die Referenzen zu löschen gebaut - bin nur noch am Testen bevor ich es commite.

Ich bin auch dazu übergegangen nicht mehr die urlHashes zu speichern, sondern nur noch deren int-Positionen. Auf die Weise fällt auch das suchen weg.

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon sixcooler » Mi Sep 07, 2011 2:11 pm

Hallo,

ich hab das Zeuch gerade mal commited.
Von Dir inspiriert hab ich noch fix mein zeuch zur Nutzung eines int[] umgebaut - zuvor hatte ich aun TreeSet genutzt, aber das int[] ist natürlich viel effektiver.

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon Orbiter » Mi Sep 07, 2011 3:33 pm

dein svn 7934 sieht gut aus; habs noch nicht getestet aber das diff sieht so aus als sollte es ein effizienter hack sein. Es ist aber halt ein 'Hack' weil in der Klasse ArrayStack.java damit Know-How über die interne Konstruktion von ReferenceContainer Objekten verbaut ist. Es wäre mir ein wenig lieber wenn das Know-How und die Methoden dazu in ReferenceContainer sein würden. Mach aus den drei static Methoden in ArrayStack einfach Klassen-Methoden von ReferenceContainer.

Eines aber würde ich wichtig finden: das sollte nicht sofort für alle default sein, weil da manche ihre Produktionsdaten verlieren ohne das zu wollen. Man sollte über die yacy.conf einstellen können ob dieser Haircut stattfinden sollte und auch bei welcher Grenze.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: /api/termlist_p.xml

Beitragvon sixcooler » Mi Sep 07, 2011 8:10 pm

Hallo,

ich hab das nun in 7935 mal nach ReferenceContainer gepackt und über yacy.conf - index.maxReferences configurierbar gemacht.
Nur bin ich mir nicht sicher ob es wirklich gut ist den config-Wert auch in ReferenceContainer zu ermitteln.

@Orbiter: wie würdest Du das machen?

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm

Re: /api/termlist_p.xml

Beitragvon Orbiter » Mi Sep 07, 2011 10:50 pm

Hab den Wert dort in eine static variable gesetzt die vom Switchboard aus geschrieben wird, sonst gibts eine zirkuläre dependency und die kelondro Klassen sollen theoretisch nicht vom Switchboard abhängen.
In SVN 7936 hab ich auch eine Konfiguration des Wertes in IndexControlRWIs_p.html rein gemacht.

Das ist prima geworden und ich bin froh dass du das da eingebaut hast. Ich bin mal gespannt wie sich das auswirkt.
Orbiter
 
Beiträge: 5798
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: /api/termlist_p.xml

Beitragvon sixcooler » Mi Sep 07, 2011 11:21 pm

Hallo,

ja so ist das besser mit dem Konfigurationswert. Und mit dem UI finden das hoffentlich auch viele Anwender - danke!

So wie bei mir zuvor, dürften ja noch einige superdicke Referenzmengen existieren - so fix wie ich die nach dem löschen wieder im Index hatte.

cu, sixcooler.
sixcooler
 
Beiträge: 494
Registriert: Do Aug 14, 2008 5:22 pm


Zurück zu Fragen und Antworten

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron