Peers mit Beschränkungen im Speicherverbauch

Ideen und Vorschläge sind willkommen.

Peers mit Beschränkungen im Speicherverbauch

Beitragvon PCA42 » So Dez 16, 2007 1:45 pm

Auch wenn ich leider wenig Kommentare bekomme, lasse ich einfach mal meine nächste Idee los. Ich hoffe, ich verstehe die bisherige Funktionsweise von Yacy richtig, denn sonst können grade die unter Punkt 2 beschriebenen Funktionsweise überflüssig sein.

Im Forum ist gelegentlich schon Unmut über den nicht zügelbaren Verbrauch an Speicherplatz aufgekommen. Das betrifft sowohl die Festplatten- als auch den RAM-Speicherplatz. Daher sollte es für den Benutzer möglich sein, Höchstgrenzen für diese beiden Parameter vorzugeben, auf die Yacy auch angemessen reagiert. Reagieren heißt hier, dass die Funktionalität erhalten bleibt und der Peer weiterhin sinnvoll, für mich bedeutet das z.B. DHT-In + -Out, zum Netz betragen kann.

Um diese Zielsetzung zu erreichen sind meiner Meinung nach zwei Schritte notwendig:

1. Anpassen der "Zuständigkeit" eines Peers

Bisher wird für jeden Peer pauschal ein Bereich gesetzt, in dem er Entries entgegennimmt und natürlich dann auch im Rahmen von Suchanfragen angesprochen wird. Dieser pauschale Wert, er liegt im Augenblick bei einer Distanz von ca. 0.2, sollte als Startwert für eine Optimierung genommen werden. Erreicht der Peer einen bestimmten Schwellenwert der zugewiesenen Resourcen, sollte diese Distanz in bestimmten Schritten verkleinert werden. Anderen Peers könnte dies im Rahmen des Seed bzw. Ping mitgeteilt werden. So wird erreicht, dass sich die Peers mit der Zeit spezialsieren und aber funktionsfähig bleiben. Mit dieser Funktionsweise kann dann auch die Skalierbarkeit der gesamten Yacy-Netzes sehr dynamisch erfolgen.

2. Optimieren der Datenbanken

Bisher kennen die Datenbanken leider nur eine Richtung: sie wachsen. Für die RWI-Datenbanken stellt das in der Regel kein Problem dar. Da die Daten jedoch auf verschiedene Dateien verteilt sind, sollten die einzelnen Dateien auch schrumpfen können. Da im Normalfall nur wenige frei Einträge vorhanden sind, kann beim Start des Peers ein Ausgleich in der Form erfolgen, dass die freien Stellen in der Datei mit Einträgen vom Ende der Datei gefüllt werden und die Datei anschließend verkleinert wird.

Für die URLs ist es etwas Problematischer. Hier würde ich grundsätzlich den selben Ansatz wählen. Zusätzlich sollte die Nutzung einer URL im Collection-Cache einfach gezählt werden. Ist der letzte Entrie für die jeweilige URL nicht mehr auf dem Peer vorhanden, kann die URL gelöscht werden. Bisher stellt das auch kein großes Problem dar, bei max. 100 Peers hat fast jeder Peer auch von einer geparsten Seite einen Entrie zu halten, aber für die Zukunft mit hoffentlich einen weitaus größeren Zahl an Peers sollte das unabdingbar sein.
PCA42
 

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon thq » So Dez 16, 2007 2:14 pm

Auch wenn ich solche Beiträge wie meinen jetzt als Spam bezeichne, stimme ich dir 100% zu.
thq
 
Beiträge: 651
Registriert: So Jul 08, 2007 12:23 pm

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Fuchs » So Dez 16, 2007 7:40 pm

PCA42 hat geschrieben:1. Anpassen der "Zuständigkeit" eines Peers

Bisher wird für jeden Peer pauschal ein Bereich gesetzt, in dem er Entries entgegennimmt und natürlich dann auch im Rahmen von Suchanfragen angesprochen wird. Dieser pauschale Wert, er liegt im Augenblick bei einer Distanz von ca. 0.2, sollte als Startwert für eine Optimierung genommen werden. Erreicht der Peer einen bestimmten Schwellenwert der zugewiesenen Resourcen, sollte diese Distanz in bestimmten Schritten verkleinert werden.


Es wäre vermutlich schon ausreichend einen DB-DHT-Distanz-Wert manuell konfigurierbar zu machen.

Dieser würde dann zu einer Eigenschaft eines Peers, denn für die Suche ist wichtig zu wissen, an welchen Peer sie geschickt werden kann. Für ein Wort mit einem Abstand von 0.15 zum Peer-Hash, aber einer Peer-DB-DHT-Distanz von 0.1 würde der Peer ohne diese global bekannte Eigenschaft als mögliches Ziel für die Suchanfrage ausgewählt werden, obwohl er nicht dafür zuständig ist.

Eine dynamische Anpassung anhand der Größe des Gesamtnetzes (wenn der Peer keine eigenen Vorgaben macht), oder der lokal zur Verfügung stehenden Resourcen auf dem Peer würde ich erst danach als nächsten Schritt in Erwägung ziehen, um mögliche Seiteneffekte auszuschließen.

2. Optimieren der Datenbanken

Bisher kennen die Datenbanken leider nur eine Richtung: sie wachsen. Für die RWI-Datenbanken stellt das in der Regel kein Problem dar. Da die Daten jedoch auf verschiedene Dateien verteilt sind, sollten die einzelnen Dateien auch schrumpfen können.


AFAIK ist/war es ja so angedacht, dass nicht mehr benötigte RWI-Einträge (also solche ohne URL-Referenzen) für neue RWI wiederverwendet werden. Das hätte zur Folge, dass die DB ab einem bestimmten Punkt nicht mehr bzw. nur noch sehr selten wächst. Aber hier gab/gibt es wohl ein Problem, das bei dieser Operation zu Fehlern in der DB führte.

@orbiter:
1. Wie funktioniert das momentan mit RWI-Datensätzen ohne URL-Referenz?
2.1. "Upgrade" der RWI-Partition:
Ein RWI hat 4 URLs liegt also in der KCA-0, bekommt eine neue URL und wandert in KCA-1. Was passiert in dem Fall mit der Zeile in KCA-0 auf der Platte (nicht aus YaCy-Sicht)?
2.1. "Downgrade" der RWI-Partition
Ein RWI hat 5 URLs liegt also in KCA-1. Eine URL wird entfernt und es wandert ins KCA-0. Was passiert mit der alten Zeile in KCA-1 auf der Platte?


Da im Normalfall nur wenige frei Einträge vorhanden sind, kann beim Start des Peers ein Ausgleich in der Form erfolgen, dass die freien Stellen in der Datei mit Einträgen vom Ende der Datei gefüllt werden und die Datei anschließend verkleinert wird.


Das würde sich bei einer funktionierenden Wiederverwendung nahezu erübrigen und müsste/könnte nur noch bei Bedarf (die DB-Größe schrumpft im Laufe der Zeit tatsächlich, es kommen also weniger neue RWI als alte gelöscht werden) in einem manuellen DB-Rebuild (orbiter hatte irgendwo nebenan laut darüber nachgedach) angestoßen werden.


Alternativ-/Ergänzungsvorschlag

Grundsätzlich hatte ich mir auch schon einige Gedanken dazu gemacht, wie man das ganze etwas resourcenschonender gestalten könnte. Es passt hier sicher ganz gut, den aktuellen Gedankenstand dranzuhängen:

Durch die Verteilung der RWIs auf die Peers in Abhängigkeit des Abstandes zwischen RWI- und Peer-Hash, entsteht virtuell schon ein zweigeteilter Index. Es gibt also RWIs, die für eine globale Suche wichtig sind (innerhalb des Abstands) und solche, die dafür vollkommen irrelevant sind, und die nur darauf warten irgendwann per DHT auf passende Peers verteilt zu werden.

Die Idee ist nun, diese virtuelle Teilung auch in der Struktur der Datenbank umzusetzen. Ergebnis wäre eine Teilung der DB in einen primären und einen sekundären Teil.

Beide sind identisch aufgebaut. Die konkreten Datenstrukturen müssen nicht verändert werden, sondern bleiben wie sie jetzt sind in den KCAs. Nur gibt es dann zwei Verzeichnisse mit KCAs.

Die primäre RWI-DB enthält nur diejenigen RWI, die zum eigenen Peer passen, also einen maximalen Abstand zum Peer-Hash haben. Dieser würde für die globale Suche herangezogen. Gleichzeitig kann aufgrund der im Vergleich zur gesamten DB geringeren Anzahl der enthaltenen Elemente sehr viel schneller darauf zugegriffen werden, was sowohl Suchoperationen als auch Einfüge und Merge-Operationen mehr oder weniger beschleunigen würde.

Die sekundäre RWI-DB beinhaltet nur diejenigen RWI, welche nicht zum Peer passen und nur dafür gespeichert werden, damit sie später per DHT verteilt werden können. Ein effizienter Lesezugriff auf diese Dateien ist zweitrangig.

Damit würde die DB also äquivalent zu den DHT-In/Out Caches physisch voneinander getrennt. Somit wären also auch diese Caches nur für jeweils eine DB zuständig. Diese Entkoppelung hätte darüber hinaus den Vorteil, dass Zugriffkonflikte leichter verhindert werden können: Das Wegschreiben von DHT-Out-RWIs (sekundärer Index) würde z.B. kaum Lese-Operationen blockieren, da aus diesem Index nur sporadisch gelesen werden muss, wenn der Cache für die DHT-Verteilung leer ist.

Diese Trennung ermöglicht dann auch verschiedene Performance-Optimierungen in Bezug auf den Speicherverbrauch:

a) Als drastische Maßnahme wäre es möglich die sekundäre DB komplett zu leeren, ohne Auswirkungen auf die globale Suche befürchten zu müssen. Es werden zwar Daten gelöscht, die auf einem anderen Peer relevant sein könnten. Sie werden aber momentan nicht benutzt und belegen auf dem Peer nur Resourcen ohne irgendeinen Mehrwert zu erbringen.
Einsparung Plattenkapazität: geschätzt 60-80%.

b) Wichtiger ist vermutlich die Möglichkeit, den Bedarf an Arbeitsspeicher zu minimieren, indem für die Sekundäre DB auf einen RAM-Index verzichtet wird. Für einen Crawler ist diese Methode allerdings nicht geeignet, da dieser auch schnellen Schreibzugegriff auf die sekundäre DB benötigt um den DHT-Out Cache zu leeren. Für sporadisches Crawlen über den Proxy mag ein File-basierter Index aber ausreichend sein.
Einsparung minimaler RAM-Bedarf: Je nach Index-Größe 40-80%.


Man könnte also verschiedene Klassen von Peers definieren, die je nach Bedarf unterschiedliche Cache- und Index-Strategien haben. Gleichzeitig mit der reparierten (?) Wiederverwendung von Löchern in der DB und einem regelbaren max. DHT-Abstand sollte sich so der Ressourcen-Verbrauch steuern lassen. Eine Einstellung auf eine konkrete Größe halte ich nicht für sinnvoll, weil sie sich mit der DB-Struktur kaum effizient realisieren lässt, weil nicht genau vorhersagbar ist, wieviel Platz ein Index mit z.B. 1000000 Wörtern braucht. Man würde es aber mit der Zeit aus Erfahrungswerten in etwa Abschätzen können, so dass der User die Möglichkeit hätte zu bestimmen, ob er lieber einen 3-6GB großen Index hätte, oder ob auch ein 30-60GB großer nicht weh täte.

Einziger größerer Knackpunkt der Idee ist, dass es eine rein auf die globale Suche ausgerichtete Optimierung wäre, aber darum geht es bei YaCy ja auch primär. ;) Und natürlich könnte man den Peer auch mit einer geteilten DB so konfigurieren, dass er sich 100% identisch mit heutigen verhält.

------

Für die URLs ist es etwas Problematischer.


Für die URLs ist es eigentlich viel einfacher. Hier können bei Platzmangel einfach die URL-DB-Verzeichnisse mit den ältesten Daten gelöscht werden.

Eine direkte Steuerung ist hier sowieso nicht möglich, da die URLs immer von RWI-Elementen referenziert werden und nicht als eigenständige Einheiten betrachtet werden können. Sie sind quasi Bestandteile eines RWI-Eintrags, die nur deshalb extern in einer eigenen "Tabelle" gespeichert werden, um Redundanz zu vermeiden.


Das soll dann erstmal genug sein. Jeder der es bis hierher geschafft hat gewinnt ein Grinsen von mir. ;)
Fuchs
 
Beiträge: 250
Registriert: Mi Jun 27, 2007 11:39 am
Wohnort: Rostock

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon PCA42 » So Dez 16, 2007 8:18 pm

Die Trennung der Datenbanken kann man sicherlich auch noch für weitere Optimierungen im Rahmen des DHT-Verteilens einsetzten. So können z.B. dort zunächst vielleicht alle geparsten Daten landen, damit sie dann verteilt werden, um die für das Funktionsprinzip notwendige Redundanz herzustellen.

Fuchs hat geschrieben:Man könnte also verschiedene Klassen von Peers definieren, die je nach Bedarf unterschiedliche Cache- und Index-Strategien haben. Gleichzeitig mit der reparierten (?) Wiederverwendung von Löchern in der DB und einem regelbaren max. DHT-Abstand sollte sich so der Ressourcen-Verbrauch steuern lassen. Eine Einstellung auf eine konkrete Größe halte ich nicht für sinnvoll, weil sie sich mit der DB-Struktur kaum effizient realisieren lässt, weil nicht genau vorhersagbar ist, wieviel Platz ein Index mit z.B. 1000000 Wörtern braucht. Man würde es aber mit der Zeit aus Erfahrungswerten in etwa Abschätzen können, so dass der User die Möglichkeit hätte zu bestimmen, ob er lieber einen 3-6GB großen Index hätte, oder ob auch ein 30-60GB großer nicht weh täte.


Hier sollten schlicht und ergreifend zwei Werte vom Benutzer erfragt werden: maximaler Speicher (schon erledigt :D ) und der Festplattenplatz. Und diese Werte kann ja schließlich über die Größe der vorhandenen Datensätze berechnet werden. Die Anzahl der Worte bzw. Links sollte für diese Einstellungen im Benutzerinterface keine Bedeutung haben.

Wenn dann sich die reelen Werte den maximalen annäher, können ja verschiedene Strategien zum Tragen kommen: crawlen einstellen, DHT-In abstellen und ggf. Teile der Daten verwerfen (schlecht aus meiner Sicht).
PCA42
 

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Orbiter » Mo Dez 17, 2007 1:28 am

wow. also:

PCA42, zu 1)
Die Beobachtung der 0.2 DHT-Distanz führt dich zu dem Schluss, das alle Peers mit dieser Distanz einen RWI bekommen. Das ist nicht so, es werden nur Peers mit optimaler Distanz (d.h. das Minimum der Distanz aller Peers) ausgewählt. Werden hier allerdings Peers mit Distanz > 0.2 ausgewählt, werden diese aussortiert. Das ist also gewissermaßen nur eine Notsicherung und könnte beispielsweise bei sehr kleinen Netzen oft greifen. Daher ist DHT in kleinen Netzen (< 16 Peers) sowieso aus, hier wird gar nicht verteilt und bei einer Suche alle Peers gefragt (siehe Sciencenet)

Das Thema ist aber damit nicht beendet, wie alle hier richtig beobachtet haben kann man dazu sich Verbesserungen einfallen lassen. Ich habe dazu auch ein Redesign im Radar, darin ist insbesondere etwas wie Fuchs' 2-Teilung drin. Momentan denke ich über eine n+1 - Teilung nach (n = Anzahl der Peers), so dass die n Peer-Indexe gleich Vorräte sind für die Verteilung, und nicht mehr selektiert werden muss. Hätte massig weniger IO, geht aber nicht so einfach weil Peers gerne oft mal da sind, oder nicht, oder neue kommen. Hier muss also eine Peer-Verteilungs-Abstraktionsebene dazwischen, das würde gehen, skaliert aber nicht so leicht mit großen Peeranzahlen. Auch wenn wir uns vor rapiden Wachstum auf 1000ende Peers nicht gerade fürchten (und nicht gerade befürchten müssen), so ist das aus Architektursicht nicht gerade gut. Sobald ich weiss wie ich hier eine sinnvolle Skalierung hinbekomme gehts wohl weiter.

Fuchs, dazu deine Fragen:
1) es gibt kein periodisches catch-up, allerdings werden solche Referenzen dann, wenns auffällt (bei der Suche oder DHT-Versand) gelöscht.
2.1) wird als gelöscht markiert, wird wieder ein Slot benötigt wird von den markierten allociert (File wächst nicht). Man kann das beim Start-up beobachten, hier gibts (vergessen zu entfernen) debug-Meldungen über deleted entries
2.2) das gleiche wie bei 2.1

Was du mit primär/sekundär bezeichnet gibts ja schon als RWI-RAM-Cache und heisst ja DHT-in und DHT-out. Was wir hier brauchen ist eine solche Trennung auf Filebasis. Es ists aber insgesamt nicht ganz so einfach, denn mal abgesehen von dem n+1 - Konzept oben plane ich die Erweiterung des Target-Konzeptes auf x-Targets. D.h. nicht mehr ein Peer wird verantworlich sein für einen RWI, sondern eben x verschiedene. Das hat den Vorteil das die Suche dann in x Peers parallel abläuft, und hier ist nicht das IO das was am längsten braucht, sondern die CPU-Time beim Sortieren der Ergebnisse. Die x-Targets werden also die Suche parallelisieren und eben x-fach beschleunigen (minus netzlatenz). So macht es sowei ich weiss Google auch.

PCA42, zu 2)
Umkopieren von gelöschten Einträgen von Mitte nach hinten (ist ja eigentlich ein Umkopieren von Einträgen von hinten in die Lücken) während der Laufzeit verbietet sich weil das ja höllisch den IO aufbläst, ich denke das läuft auf eine Verdopplung hinaus. Beim Startup würde ich das auch nur machen wenns richtig viele sind, sonst ists leicht vergebene Mühe weil die Lücken eh wieder geschrieben werden.
Dazu kommt aber das die kca-Dateien über den kca-Index verschränkt sind, d.h. während ich in kca schrumpfe muss ich in der Index-Datei die Referenzen ändern. Macht also viel IO. Man muss überlegen ob sich das lohnt.
Bei der LURL-Datei glaube ich nicht das es sich überhaupt lohnt, in diesen Dateien wird gar nicht gelöscht. Hier bin ich das Konzept so angegangen das LURL-Einträge nach Monat geordnet in einzelne Dateien geschrieben werden. Wenn man hier also einen alten Index von letztem jahr löschen will, löscht man eben die ganze Datei. Das ist aber noch nicht implementiert.

Das Problem das LURL-Dateien bei allen anwachsen, weil über die DHT-Verteilung quasi alle Peers alle URLs bekommen will ich angehen. Hier greift das was ich oben über x-Targets geschrieben habe, denn die x DHT Positionen müssen aus einem RWI ja nach einem bestimmten Schlüssel erfolgen. Hier will ich über den URL-Hash die targets bestimmten, also sowas wie eine URL-DHT. Hier wird sich das Problem eben auch um den Faktor x mindern. Das ist zwar auch noch keine komplette Lösung, aber immerhin ein weiterer Schritt. Komplett hochskalierbar wäre nur, beim RWI-DHT keine URLs mehr mitzusenden, sondern auch noch eine URL-DHT anzulegen. Dann hat man bei einer Suche aber wieder viel Netztraffic zur Auffindung der URLs. Da mir momentan an der Suchzeit mehr liegt gehe ich dieser Idee weniger nach.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon thq » Mo Dez 17, 2007 2:36 am

Orbiter hat geschrieben:Komplett hochskalierbar wäre nur, beim RWI-DHT keine URLs mehr mitzusenden, sondern auch noch eine URL-DHT anzulegen. Dann hat man bei einer Suche aber wieder viel Netztraffic zur Auffindung der URLs. Da mir momentan an der Suchzeit mehr liegt gehe ich dieser Idee weniger nach.
Das liest sich so als ob ein URL-DHT in kürzester Zeit fertig ist. Da das aber bestimmt nicht so schnell geht finde ich das schade das es nicht umgesetzt wird, je eher umso schneller ist es ausgereift. Ich glaube nicht das der Netzverkehr bis dahin noch eine Rolle spielt, selbst jetzt dürfte die Kapazität und Geschwindigkeit ausreichen.
thq
 
Beiträge: 651
Registriert: So Jul 08, 2007 12:23 pm

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon PCA42 » Mo Dez 17, 2007 6:02 am

Danke Orbiter für die erleuchtenden Informationen zu den Datenbanken. Dann ist es mir auch klar, das eine Optimierung dort nicht so einfach ist.

Was bitte dieser Diskussion jetzt nicht in den Hintergrund rücken sollte: es sollte gewährleistet werden, dass für die Peers einstellbare Parameter für den Speicherverbrauch vorhanden sind. Der Weg dahin ist mir vollkommen egal. Ich hab dazu eine Möglichkeit aufgezeigt und bin aber auch für alle anderen Ideen dankbar. Und wenn weitere Verbesserungen anfallen: auch gut. :D

Was ich aber auch schon eine Weile mit mir als Idee rumschleppe ist die Verteilung der URL's nach Peerhash. Mir ist auch klar, dass das beim Suchen einen enorm erhöhten Aufwand und durch das zweistufige Abfragen auch mehr Zeit kostet. Auch werden zwangsläufig mehr Peers belastet. Aus meiner Sicht gibt es dort aber wichtige Pro's. Ich schreib das aber mal extra ins Forum was mich da umtreibt.
PCA42
 

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Fuchs » Di Dez 18, 2007 12:43 am

Orbiter hat geschrieben:Umkopieren von gelöschten Einträgen von Mitte nach hinten (ist ja eigentlich ein Umkopieren von Einträgen von hinten in die Lücken) während der Laufzeit verbietet sich weil das ja höllisch den IO aufbläst, ich denke das läuft auf eine Verdopplung hinaus. Beim Startup würde ich das auch nur machen wenns richtig viele sind, sonst ists leicht vergebene Mühe weil die Lücken eh wieder geschrieben werden.


Ich hatte neulich mal geschaut, wie der Füllstand der RWI-DB und die Verteilung auf meinem Peer (>20 Millionen RWI) aussieht. Dazu hab ich einfach über den Index iteriert und die Zahl der RWI mit X URL-Referenzen (für jedes X: 0 <= X <= 2^16) durchgezählt. Das Ergebnis bei insgesamt 20.800.961 RWI (nur die ersten 20 Ergebnisse):

Code: Alles auswählen
0       1269665
1       12750417
2       2395997
3       1021563
4       588253
5       386041
6       281745
7       211423
8       169714
9       136566
10      117857
11      94485
12      80883
13      69553
14      61816
15      53809
16      49439
17      43834
18      39671
19      35538


Der Peer lief die ersten Wochen im Crawl-Modus und die letzten Monate nur noch als Proxy/Remote-Indexer + DHT-Peer. Also ca. 6% der RWI sind leer, macht für das Beispiel also etwa 20 MB für den Speicher-Index. Die Optimierung hätte an dieser Stelle also nur marginale Auswirkungen.


Die zweite Zeile zeigt aber, dass es noch einen vielversprechenderen Ansatz für die Optimierung gibt. Ich bin überzeugt, dass bei der Indexgröße dieses Peers, darauf geschlossen werden kann, dass 95% der RWI mit nur 1 URL-Referenz reiner Datenmüll und für eine Suche nicht relevant sind -- immerhin mehr als 50% der RWI.

Erst vor ein paar Wochen hab ich den Indexer dabei erwischt, dass er sich über irgendeine Uni-Seite her machte, auf der hunderte PGP-Keys in "armored ASCII". Jeder Key war also eine Datei mit mehreren hundert "Worten" (aus YaCy-Sicht) Datenmüll.

Das gleiche Problem hat man mit den Unmengen an MD5/SHA/etc. Hashes, die im Web zu finden sind.

Wenn man für solche Sachen eine klevere und effiziente Möglichkeit finden würde könnte man wirklich massiv Daten sparen und die Performance steigern.
Fuchs
 
Beiträge: 250
Registriert: Mi Jun 27, 2007 11:39 am
Wohnort: Rostock

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Orbiter » Di Dez 18, 2007 12:54 am

ok, URL-DHT -> anderer Thread.

Speicherbeschränkung: das Thema ist schwierig. Das ganze Thema hat ja was damit zu tun das wir wachsen wollen, wir haben nicht gesagt wir wollen xhundertmillionen URLs und Ende. Das Problem liegt hier bei 2 Punkten:
- mit der Anzahl der URLs müsste eigentlich die Anzahl der Teilnehmer wachsen
- Bei Wachstum des netzes müssen bislang allocierte Resourcen eines Peers wieder an andere Peers weiter gegeben werden.

an beiden Punkten hapert es. Das Wachstum stagniert zur Zeit, und Abgabe von Resourcen mit gleichzeitiger Schrumpfung des lokalen Indexes ist nicht implementiert. Das wundert aber nicht, es würde nur bei starker Teilnehmerzahl sinn machen.

Abseits dieser exakt-skalierungs-eigenschaften wäre es auch einfach möglich, beschränkungen und Blockierungen von Index-Empfang bei Überschreitung von Limits einzubauen. Das ist aber sicher nicht im Sinne der Teilnehmer. Wenn man also alle Varianten oben durchprobiert sieht man das hier eine gewisse Zwickmühle ist und das unbeschränkte Wachstum am Konfliktfreiesten ist.

Fehlt es denn an GB auf der Platte? So wie momentan die Plattenpreise sind kann ich mir das nicht vorstellen. Seit es das YaCy-Projekt gibt wächst doch die Speicherverfügbarkeit schneller als der YaCy-Globalindex.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon PCA42 » Di Dez 18, 2007 6:12 am

Ich habe vor einiger Zeit Yacy auf einem V-Server laufen lassen. Und da sind Arbeitsspeicher und Festplattenplatz ein rares Gut. Es gibt derzeit zum Glück ausreichend Peers, die mit den Einstellungen ohne Limit leben können, ich auch. Aber wenn wir wollen, dass Yacy wieder ein Wachstum erfahren kann, sind solche Einstellungen für den Peer notwendig. Im Augenblick wären auch noch genug alte Peers vorhanden, die die Datenmengen verkraften.

Kann man hier im Board nicht mal ne Umfrage machen, das geht doch:
Frage: Sollte Yacy Einschränkungen bieten für
1. Arbeitsspeicher
2. Festplatte
3. Arbeitsspeicher und Festplatte
4. nicht notwendig
PCA42
 

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Orbiter » Di Dez 18, 2007 12:29 pm

Umfrage gut und schön aber macht nicht Sinn wenn eine Beschränkung von Plattenplatz nicht vorher genau definiert ist. Um das nochmal zu wiederholen:

- wenn man den Plattenplatz beschränkt heisst das unmittelbar, das irgendwann kein DHT-Empfang mehr gemacht wird
- Beschränkung des Plattenplatzes führt also unmittelbar zum Einschränken der Suchfunktion am teilnehmenden Peer

Man kann nicht darüber abstimmen ob man bestimmte Funktionen will wenn man nicht weiss was diese dann bedeuten (und dann Sinn machen).

Oder um es anders auszudrücken: alle Resourcen lassen sich bereits jetzt beschränken:
- RAM sowieso, dazu gibts eine Konfiguration
- Platte auch, man stellt dazu einfach alle Funktionen die den Peer wachsen lassen aus (DHT Empfang und remote indexing)

Es ist ja nicht so dass man mit einer Plattenplatzbeschränkung 'zaubern' kann, also Daten empfangen und trotzdem nicht mehr Platz benötigen.
Der einzige Ausweg aus dieser Situation wäre die Definition von Löschzyklen, d.h. man definiert das man beim Empfang von Daten auch gleichzeitig (alte) Daten löscht, um so bei einer festgelegten Platzgröße bleibt. Hier kann man also erst dann über eine Beschränkung sinnvoll 'abstimmen' wenn man weiss wie Löschregeln aussehen sollen, und diese dann implementiert sind.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Fuchs » Di Dez 18, 2007 12:41 pm

Orbiter hat geschrieben:Speicherbeschränkung: das Thema ist schwierig. Das ganze Thema hat ja was damit zu tun das wir wachsen wollen, wir haben nicht gesagt wir wollen xhundertmillionen URLs und Ende.


Das ist theoretisch OK. Praktisch sieht es aber so aus, das es bei 100 aktiven Peers eine praktische Obergrenze gibt. Einige Peers haben mehr Resourcen als andere. Ich hab aber keine Ahnung, wie man das "einstellen" könnte, da ja nicht der eigene Peer entscheidet, was in seinem Index per DHT landet, sondern die versendenden Peers.

Fehlt es denn an GB auf der Platte?


Der Plattenplatz ist aus dem was ich hier lese eher das kleinere Problem. Der RAM-Verbrauch ist schwieriger. An meinem Beispiel: YaCy wächst auf der Platte hier momentan nur noch sehr langsam mit insgesamt gut 45 GB inklusive allem (auch commons collections), der RAM-Bedarf dürfte aber nicht mehr viel weiter steigen: momentan läuft java mit 900 MB Heap und braucht insgesamt knapp 1GB, davon sind rund 600 MB dauerhaft durch RAM-Index und andere dauerhaft im Speicher gehaltene Daten belegt.
Fuchs
 
Beiträge: 250
Registriert: Mi Jun 27, 2007 11:39 am
Wohnort: Rostock

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Orbiter » Di Dez 18, 2007 1:42 pm

bei wieviel URLs?
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon miTreD » Di Dez 18, 2007 1:52 pm

Orbiter hat geschrieben:bei wieviel URLs?
Links: 10,846,998
RWIs: 15,941,309
RAM: 620MB immer voll. Hin und wieder short mem cycle und häufiger GC.
miTreD
 
Beiträge: 1241
Registriert: Mi Jun 27, 2007 11:35 am
Wohnort: /home

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Low012 » Di Dez 18, 2007 2:52 pm

Ich bin derzeit bei 640MB RAM und in den letzten Tagen häufen sich die GC-Hinweise im Log.
Links: 13.585.583
Words: 17.629.312

Ich kann leider nicht viel mehr RAM zur Verfügung stellen, weil sonst die JVM abschmiert. Warum auch immer, RAM habe ich mehrfach überprüft und konnte keine Fehler finden. HDD ist kein Problem, YaCy darf sich bei mir auf 250GB austoben.
Low012
 
Beiträge: 2214
Registriert: Mi Jun 27, 2007 12:11 pm

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Fuchs » Di Dez 18, 2007 5:06 pm

Orbiter hat geschrieben:bei wieviel URLs?


gut 14,5 Millionen.
Fuchs
 
Beiträge: 250
Registriert: Mi Jun 27, 2007 11:39 am
Wohnort: Rostock

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon PCA42 » Di Dez 18, 2007 5:42 pm

Um den Festplattenplatz mal aus der Diskussion zu nehmen: dem Arbeitsspeicherproblem können wir dann vielleicht mit der URL-Verteilung beikommen. Kommt auf den Versuch an. Und ich denke auch, wenn das gut funktioniert, sollten auch die Wortzahlen sinken, da die DHT-Verteilung sich beschleunigen würde.
PCA42
 

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Huppi » Di Dez 18, 2007 6:59 pm

Meine YaCy-Kistchen lassen sich schlicht nicht auf mehr als 512MB RAM aufrüsten, haben aber jeweils eine 200GB Festplatte spendiert bekommen. HDD ist also keine Limitierung, RAM schon.
Huppi
 
Beiträge: 898
Registriert: Fr Jun 29, 2007 9:49 am
Wohnort: Kürten

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Orbiter » Di Dez 18, 2007 8:53 pm

ok für knapp 15 mio urls ist der speichervebrauch ja ok. versuche das mal mit einer google-kiste, da ist bei 3 millionen urls schluss, und 0.5 millionen kosten schon 28000 euro.
http://www.google.com/enterprise/gsa/pr ... odels.html

wenn ich also hier betriebwirtschaftlich argumentieren würde, müsste ich sagen 'bei den preisen kann es nicht an ein paar gigabyte ram hängen'. aber das hilft ja hier nicht, ich wollte nur mal andeuten das ein 15 mio-peer mit solchen (kleinen) resourcen schon mal nicht so schlecht ist.

eine alternative datenbankarchitektur, die weniger auf ram setzt hatten wir zu beginn des projektes, da setzte ich auf io und das war nur schlimm.

es hilft also nix, man kann kein ram einfach so sparen, man muss darüber nachdenken was gelöscht werden soll. eine ram-begrenzung würde ich in der realisation in form einer löschung vorsehen, anders gehts eben nicht.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Low012 » Di Dez 18, 2007 9:11 pm

Ideal wäre natürlich zu löschen, was sowieso nicht mehr aktuell ist. Dazu müsste YaCy aber entweder eine Kristallkugel eingebaut bekommen oder aber für jedes Wort überprüfen, ob es sich noch in der/den entsprechenden URL(s) befindet, was einen relativ hohen Aufwand zur Folge hätte.

Alternativ könnte man alte oder selten benutzte Daten löschen. Dann könnte man die dazugehörigen URLs als RemoteCrawl verschicken und hoffen, dass möglichst viel veraltet war und wenig per DHT zurück kommt.

Was Besseres fällt mir nicht ein.
Low012
 
Beiträge: 2214
Registriert: Mi Jun 27, 2007 12:11 pm

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Fuchs » Di Dez 18, 2007 10:12 pm

Orbiter hat geschrieben:es hilft also nix, man kann kein ram einfach so sparen, man muss darüber nachdenken was gelöscht werden soll. eine ram-begrenzung würde ich in der realisation in form einer löschung vorsehen, anders gehts eben nicht.


Ja, sparsamer als jetzt geht es nicht.

"Aufklärung"

Vielleicht hilft es auch einfach, den Usern von vornherein genauer zu sagen, worauf sie sich in etwa einzustellen haben. Dazu wäre es hilfreich ein paar Daten zu haben. Aus meiner Sicht gibt es 3 Hauptklassen von Peers, die am globalen Index partizipieren:

1. Crawler Peer
Hier wächst die DB sehr schnell und kann in wenigen Monaten die oben angegebenen Größenordnungen erreichen.

2. Personal Proxy Peer
Ein DHT-Peer für den Hausgebrauch, der nebenbei als Web-Proxy benutzt wird und alles was durch den Proxy läuft indexiert.
2.1. mit Proxy-Indexierungstiefe von 0 (also nur die angesurften Seiten werden indexiert)
Wachstum je nach Surfverhalten: klein*

2.2. mit Proxy-Indexierungstiefe von 1
Wachstum nach Surfverhalten: moderat*
2.3. mehr als 2 macht IMO nicht viel Sinn, das Peer würde dann zu einem Klasse-3-Peer

3. DHT Peer
Ein Peer, das nur für DHT und Suche verwendet wird.
Wachstum: minimal*

(*) Frage an alle: Um "klein", "moderat", "minimal" genauer definieren zu können bräuchte es ein paar Daten von Beispielpeers die ausschließlich in diesen Modi arbeiten, und das möglichst seit einigen Monaten und ohne zwischenzeitliche Löschungen. Also, gibt es solche Peers, und wenn ja, wie sind deren Daten? (Laufzeit + Anzahl RWI/URL in DB + belegter Platz auf der Platte)


Viele User (ich auch) fangen ja erstmal wild mit dem Crawlen an und werden dann zwei Monate später wieder abgeschreckt, wenn sie bemerken, dass sie die Resoucenanforderungen eines "Crawler Peers" nicht erfüllen können.


Optimierung

Wie ich weiter oben schon angedeutet hatte, kann man die Optimierung auch von der anderen Seite her angehen. Anstatt also zu versuchen, die Implementierung des Indexes zu ändern, sollte man sich auch und vor allem Gedanken darüber machen, was im Index landet.

Für URLs müssen z.B. Doppelindexierungen verhindert werden. Das Thema Session-ID, das in einem anderen Thread diskutiert wird gehört hierzu, aber auch Methoden die erkennen ob hinter verschiedenen Hostnamen identische Inhalte stecken (http://www.foobar.xy und foobar.xy).

Für Worte hatte ich oben mit den PGP-Keys/Hashwerte schon ein Beispiel für mehrwertlose Daten erwähnt. Weitere sind:

Besonderheiten in Schriftsprachen:
In den verschiedenen japanischen Schriftformen wie Kanji, Hiragana, Katakana gibt es im Schriftbild keine Leerzeichen. Das hat zur Folge, dass jede Zeile eines japanischen Textes als ein "Wort", nach dem niemand suchen würde, im Index landet.

Fehlkodierungen:
Wenn ein "für" als "für" im Index landet oder ähnliches, dann hat auch dieser Datensatz keinen Wert und kann vermutlich nicht einmal wiedergefunden werden.

Es gibt sicher noch weitere Beispiele. Nochmal: hier sind von 20,5 Millionen Wörtern 12,5 Millionen (60%!) mit nur einer URL verknüpft. Bei 15 Millionen indexierten Seiten ist es unwahrscheinlich dass es sich bei vielen von diesen um "echte" bzw. brauchbare Wörter handelt. Mir ist es auch noch nie passiert, dass ich zu einer Suche in YaCy nur ein Ergebnis bekommen habe.
Fuchs
 
Beiträge: 250
Registriert: Mi Jun 27, 2007 11:39 am
Wohnort: Rostock

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Lotus » Mi Dez 19, 2007 11:10 am

Fuchs hat geschrieben:3. DHT Peer
Ein Peer, das nur für DHT und Suche verwendet wird.
Wachstum: minimal*

(*) Frage an alle: Um "klein", "moderat", "minimal" genauer definieren zu können bräuchte es ein paar Daten von Beispielpeers die ausschließlich in diesen Modi arbeiten, und das möglichst seit einigen Monaten und ohne zwischenzeitliche Löschungen. Also, gibt es solche Peers, und wenn ja, wie sind deren Daten? (Laufzeit + Anzahl RWI/URL in DB + belegter Platz auf der Platte)

Ja, hier!
Ich habe leider vor 2 Tagen gecrawlt, aber nichtsdestotrotz. ;)

Momentan 6,6GB, 6.4 Mio. Links/2.3Mio Words (Flex Table RAM Index 187 MB)
Nur DHT, Zeitraum 7.10.-7.12.: 5.5Mio Links/1.8 Mio. Words

Zum crawling kann ich sagen, dass es verdammt schnell geworden ist seit meinem letzten Versuch, Remote-Crawls jedoch sehr das Wachstum bremsen (selbst bei 10/min). Daher jetzt wieder nur DHT. ;)
Lotus
 
Beiträge: 1699
Registriert: Mi Jun 27, 2007 3:33 pm
Wohnort: Hamburg

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon celle » Mi Dez 19, 2007 11:28 am

Hallo,

neben der Flextable gibt es ja noch den Fileindex, welcher verwendet wird, wenn nicht genug Speicher vorhanden ist. Kann man diesen nicht optimieren, damit man auch mit weniger Speicher auskommt. Ich hab mal im Quellcode geschaut. Soweit ich das Verstanden habe ist das ein AVL Baum. Wäre es da nicht sinnvoll, sowas wie eine Hashtabelle zu verwenden? Das ist dann immer noch langsamer als wenn das im Speicher liegt, aber besser als jetzt. Und wenn der Index schon auf der Festplatte ist, sollten dann nicht alle URLs in einem Index sein und nicht je nach Datum, weil sonst muss doch in allen nacheinander gesucht werden oder?

tschüss

celle
celle
 
Beiträge: 47
Registriert: Mi Jun 27, 2007 11:52 am

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Low012 » Mi Dez 19, 2007 9:25 pm

Was noch gelöscht werden kann: Alles was sowieso per Blacklist ausgeschlossen werden soll, zumindest dann wenn alle Kreuzchen gemacht sind. Ich habe heute Morgen angefangen, mal die URLs zu bereinigen. Mittlerweile reagiert mein Peer dummerweise nicht mehr, schreibt aber noch weiter ins Log. Ich sehe also, dass bei mir schon über 30000 URLs gelöscht wurden, was 0,82% der bisher untersuchten URLs entspricht.Ich denke mal, dass es bei den Words dann auch ein bisschen was bringt. Das werde ich mal anstoßen, wenn die URL-Bereinigung durchgelaufen ist und ich meinen Peer neu starten kann.

Wie die ganzen Daten in meinen Peer gekommen sind, weiß ich auch nicht. Wahrscheinlich sind die auch schon älter. Meine Blacklisten sind ja auch erst mit der Zeit entstanden. Wenn man es irgendwie hinbekommen würde, dass das Bereinigen der Datenbank mit niedriger Priorität im Hintergrund ablaufen würde, könnte man das Wachstum der DB vielleicht auch etwas bremsen. Nur ob das die Mühe wert ist?
Low012
 
Beiträge: 2214
Registriert: Mi Jun 27, 2007 12:11 pm

Re: Peers mit Beschränkungen im Speicherverbauch

Beitragvon Orbiter » Sa Jan 19, 2008 3:11 am

celle hat geschrieben:Hallo,

neben der Flextable gibt es ja noch den Fileindex, welcher verwendet wird, wenn nicht genug Speicher vorhanden ist. Kann man diesen nicht optimieren, damit man auch mit weniger Speicher auskommt. Ich hab mal im Quellcode geschaut. Soweit ich das Verstanden habe ist das ein AVL Baum. Wäre es da nicht sinnvoll, sowas wie eine Hashtabelle zu verwenden? Das ist dann immer noch langsamer als wenn das im Speicher liegt, aber besser als jetzt. Und wenn der Index schon auf der Festplatte ist, sollten dann nicht alle URLs in einem Index sein und nicht je nach Datum, weil sonst muss doch in allen nacheinander gesucht werden oder?

tschüss

celle


hashtable: da gibt es das problem, das man erst die Table großzügig dimensionieren muss weil man ja ein Problem hat wenn der tablespace dann voll ist; dann muss umkopiert werden und das macht keinen Spass (wahnsinns IO)

URLs nach Datum: einzig gangbarer Weg für ein Löschkonzept, und darum geht es ja jetzt hier.

Was oben steht zu 'warum können die Dateien nicht schrumpfen?' ist nun mit den Eco-Tables umgesetzt, verfügbar ab 0.563
Eco-Tables schrumpfen wenn man was daraus löscht.
Orbiter
 
Beiträge: 5792
Registriert: Di Jun 26, 2007 10:58 pm
Wohnort: Frankfurt am Main


Zurück zu Wunschliste

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast

cron