De:Performance

YaCy's Leistungsfähigkeit beim crawln und indexieren kann dramatisch verbessert werden

Die Standardeinstellungen in einem YaCy Standardrelease sind nicht auf höchste Leistungsfähigkeit eingestellt. Der Grund ist, dass YaCy auf Computern ausgeführt werden soll, welche in erster Linie für andere Dinge als YaCy gedacht sind. Bei Einstellungen, die eine höhere Leistungsfähigkeit für YaCy ermöglichen, würde YaCy sämtliche CPU-Zeit, Speicher und IO-Bandbreite verbrauchen. Aber die Einstellungen in YaCy können so angepasst werden, dass die Maschine ein sehr leistungsfähiges YaCy Web-Such Produktionssystem ergibt.

In Abhängigkeit von Ihrer Systemlandschaft können einige oder alle der im Folgenden beschriebenen Änderungen umgesetzt werden. Man sollte sich allerdings bewusst sein, dass jegliche Änderungen an den Einstellungen unerwünschte Nebenwirkungen (sogenannte Seiteneffekte) haben kann.

Speicherzuweisung erhöhen

Damit ist gemeint, dass YaCy beim Start mehr Hauptspeicher vom Betriebssystem zugewiesen bekommt.

Wie wird's gemacht?

1. Administrations Konsole -> Leistungseinstellungen [http://localhost:8090/Performance_p.html] öffnen
2. im Abschnitt Speicher Einstellung den Wert im Feld Für JVM reservierter Speicher erhöhen und mit einem Klick auf Setzen bestätigen
3. YaCy neustarten

Effekt

Dies ist die Voraussetzung für die folgenden Einstellungsänderungen. Außerdem kann YaCy beschleunigt werden, denn wenn der Speicher knapp wird werden ansonsten jede Menge "Garbage Collection" Ereignisse ausgelöst. Diese kosten eine Menge Rechenzeit und bremsen YaCy aus.

Seiteneffekte

Der für andere Anwendungen verfügbare Speicher wird reduziert.

Warum wird diese Einstellung nicht per Standard gesetzt?

YaCy versucht zum Durchschnittsbenutzer und dessen Computersystem nett zu sein. Moderne Computer verfügen über 4096MB Hauptspeicher oder mehr. Die Entwickler glauben, dass für den Start maximal 600MB ein guter Kompromiss zwischen Leistungsfähigkeit und Ressourcenverbrauch darstellt.

Indexing Cache vergrößern

Indexierung ist der Prozess bei dem der Reverse Word Index (RWI) für eine gegebene Menge von Textdokumenten erzeugt wird. Dabei wird die Beziehung "Dokument zu Wort" in eine "Wort zu Dokument" Beziehung umgekehrt wird. Dieser Prozess kann durch einen Schreibcache beschleunigt werden. Es gibt aktuell zwei verschiedene Schreibcaches; einen für die RWI, welche an einen anderen Peer übertragen werden sollen (DHT ausgehend) und einen für diejenigen RWI Einträge, welche auf dem eigenen Peer gespeichert werden sollen (DHT eingehend). Allerdings ist es unglücklicherweise so, dass sich die Caches schneller füllen, als es möglich ist diese an andere Peers zu übertragen. Um dieses Problem zu lösen, werden die Einträge vorübergehend zusammen mit den RWI Einträgen des peereigenen Index abgespeichert. Das Übertragen der Dateiinhalte auf die Festplatte ist allerdings extrem IO-intensiv und je größer die Caches sind, um so weniger IO Ereignisse treten auf.

Wie wird's gemacht?

1. Administrations Konsole -> Erweiterte Einstellungen -> Performance Settings of Busy Queues [http://localhost:8090/PerformanceQueues_p.html] öffnen
2. Im Bereich Cache Einstellungen gibt es eine Reihe von Eingabefeldern. Die Maximale Wortzahl im Cache kann erhöht werden. Beispielsweise ist ein Wert von 90000 gut geeignet, wenn im ersten Schritt die Speicherzuweisung auf 1GB (1024MB) erhöht wurde.
3. Die Änderung wird wirksam sobald der Wert durch einen Klick auf Neue Cachegröße eintragen bestätigt wurde.

Zu beachten ist, dass der Wert automatisch verringert wird, wenn YaCy in eine Situation gerät, in welcher der verfügbare Hauptspeicher zur Neige geht. Dabei wird der Wert automatisch auf denjenigen Wert gesetzt, der im Eingabefeld Anfangsfreiraum im Word Cache eingetragen ist. Daher muss auch dieser Wert entsprechend erhöht werden. Die nächsten zwei Werte Word Flush Divisor werden benutzt, um festzulegen wie viele Worte nach der Indexierung eines Dokumentes auf Festplatte geschrieben werden sollen. Es gibt zwei Werte, einen für 'busy-cycles' und einen für 'idle-cycles'. Daher kann durch den Anwender entschieden werden, das der Cache schneller geleert wird, wenn der Peer beschäftigt ist. Wenn zum Beispiel der Busy Divisor auf 10000 gesetzt wird, werden nach dem Indexieren eines Dokumentes 5 Worte geschrieben, sofern der Wortcache mit 50000 Einträgen gefüllt ist.

Effekt

Die zur Indexierung notwendige Zeit wird reduziert, die Leistungsfähigkeit in Form von PPM (Seiten pro Minute) erhöht sich.

Seiteneffekt

Diese Änderung kostet eine große Menge Hauptspeicher. Wenn die Werte zu hoch gewählt werden, wird sehr häufig die "Garbage Collection" angestoßen und dies kostet auch wieder eine Menge Rechenzeit und IO Leistung. Wenn die Cachegröße verändert wird, sollte regelmäßig auf der performance page die Speicherauslastung bei 'Memory Settings for Database Caches' geprüft werden.

Warum wird diese Einstellung nicht per Standard gesetzt?

Voraussetzung für diese Einstellung ist eine erhöhte Speicherzuweisung für YaCy (siehe oben).

Verringerung der Wartezeit zwischen eingeplanten Aufgaben

YaCy hat eine ausgefeilte Organisation für die Abarbeitung mit Warteschlangen. Jede Warteschlage enthält dabei Einträge für einen bestimmten Typ von Aufgaben. Beispielsweise gibt es eine Warteschlange mit URLs welche darauf warten geladen zu werden, es gibt eine Warteschlange mit Dokumenten, die darauf warten Indexiert zu werden und so weiter. Zwischen jeder Ausführung einer Aufgabe wird eine kurze Pause eingelegt, um anderen Prozessen und Programmen auf dem Rechner eine Chance auf Abarbeitung zu geben. Dies muss durch kleine Pausen in YaCy gemacht werden, weil die meisten Betriebssysteme zwar die Rechenzeit gerecht zwischen verschiedenen Prozessen aufteilen, dies aber leider nicht für den IO Bereich gilt.

Wie wird's gemacht?

1. Administrations Konsole -> Erweiterte Einstellungen -> Performance Settings of Busy Queues [http://localhost:8090/PerformanceQueues_p.html] öffnen
2. Im Bereich Übersicht geplanter Aufgaben und Wartezeiteinstellungen gibt es eine ganze Reihe von Eingabefeldern in denen Verzögerungswerte hinterlegt sind. Man beachte die Spalte Verzögerung zwischen beschäftigten Durchläufen: hier sind die Verzögerungswerte in Millisekunden hinterlegt, welche als Pausenzeiten zwischen der Abarbeitung der Warteschlangen verwendet werden.
   • Wenn das Crawln beschleunigt werden soll, muss der Wert im Feld Local Crawl verringert werden.
   • BITE diesen Wert nicht auf 0 setzen, da dies zu einer Überlastung des HTTP Servers des Zieles führen kann.
   • Wenn das Indexieren beschleunigt werden soll, muss der Wert im Feld Indexing verringert werden.

Effekt

Die Warteschlangen werden schneller abgearbeitet. Wenn die Verzögerungswerte gut ausbalanciert sind, dann kann dies zu einer Erhöhung der Indexiergeschwindigkeit führen.

Seiteneffekt

Wenn das Laden der Seiten zu sehr beschleunigt wird, treten Denial-of-Service Effekte auf den betroffenen Webservern auf. Es gibt eine eingebaute Lastverteilung, die versucht das Laden auf die verschiedenen Webauftritte in der Warteschlage zu verteilen. Das funktioniert aber natürlich nur, wenn auch mehrere Webauftritte in der Warteschlage enthalten sind. Man sollte sehr bemüht sein, diese Situation zu vermeiden. Für alle anderen Werte: das verringern der Verzögerung führt zu einer deutlich erhöhten Auslastung des Computersystems auf dem YaCy ausgeführt wird, damit kommt die Ausführung der anderen Programme auf dem System gegebenenfalls zu kurz.

Warum wird diese Einstellung nicht per Standard gesetzt?

Um die Gefahr von DoS Effekten durch YaCy zu vermeiden und die IO Kanäle des Computers vor Überlastung zu schützen.

Umschalten auf den Robinson Modus

Falls die Ergebnisse der Indexierung lediglich in einem lokalen Suchportal verwendet werden sollen, können die Indexverteilung, der Indexempfang sowie die Remoteindexierung abgeschaltet werden. Diese Arbeitsweise wird als "Robinsonmodus" bezeichnet. Da die Verteilung des Index mit den Indexierungsaufgaben synchronisiert werden, verlangsamt sich die Indexierung sobald die Verteilung eingeschaltet ist. Es gibt auch keine Umgehung der Synchronisation durch eine Implementierung eines separaten DHT Übertragunsprozess, denn beide Prozesse würden zur gleichen Zeit auf die gleich Datenbank zugreifen. Die dadurch verursachten Zugriffskonflikte würden einen potentiellen Leistungsgewinn zu nichte machen.

Wie wird's gemacht?

1. Administrations Konsole -> Netzwerk Einstellungen [http://localhost:8090/ConfigNetwork_p.html] öffnen
2. den Abschnitt Robinson Modus aktivieren
3. zur Einstellung des Peer-Types eine der folgenden Optionen wählen:
   • Privater Peer, wenn eine komplette Trennung und Unsichtbarkeit für andere Peers gewünscht ist
   • Öffentlicher Peer, wenn eine inhaltliche Abtrennung gewünscht ist, aber andere Peers den Index zur Suche verwenden sollen
   • Öffentlicher Cluster, wenn der Peer Teil eines öffentlichen Clusters innerhalb des YaCy-Netzwerkes werden soll. Indexdaten werden nicht verteilt, aber Remotecrawl-Anfragen werden verteilt und akzeptiert Suchanfragen werden über alle Peers des Clusters verteilt und von allen Peers des Clusters beantwortet. Liste von .yacy oder .yacyh Domains der Peers des Clusters werden kommagetrennt in einem Eingabefeld hinterlegt.

Effekt

Da die DHT Übertragungen mit der Indexierung in der 'Parsing/Indexing' Warteschlange synchronisiert wird, wird die Indexierung beschleunigt, wenn es keine DHT Üertragung gibt. Darüber hinaus wird der eigene Index mit mit dem der anderen Peers vermischt.

Seiteneffekt

Wenn die Indexverteilung oder der Indexempfang ausgeschaltet sind, darf die YaCy Instanz keine globale Suche durchführen. Wenn eine Suche gestartet wird, wir ausschließlich der Index des eigenen Peers durchsucht. Diese Beschränkung wurde eingebaut, um ein Gleichgewicht zwischen dem "Nehmen und Geben" der YaCy Gemeinschaft sicherzustellen. Mit anderen Worten: wenn in den Robinson Modus gewechselt wird, kann YaCy nur als privates Indexier- und Suchportal genutzt werden.

Warum wird diese Einstellung nicht per Standard gesetzt?

Ohne Indexverteilung würde es keine globale, YaCy basierte Suchmaschine geben.

Erhöhung der Anzahl von Crawl-Prozessen

Wenn der Webcrawl gut ausbalanciert ist (viele verschiedene Webauftritte umfasst) und das crawlen immernoch zu langsam ist (die Indexierwarteschlage ist leer und wird nicht schnell genug durch den Crawler gefüllt), dann wird empfohlen die maximale Anzhl der aktiven Crawl-Prozesse zu erhöhen.

Wie wird's gemacht?

1. Administrations Konsole -> Erweiterte Einstellungen -> Performanceeinstellungen für Puffer und Prozesse [http://localhost:8090/PerformanceQueues_p.html] öffnen
2. Im Abschnitt Thread Pool Settings finden sich einige Eingabefelder
3. die in den Eingabefeldern eingetragenen Werte sollen erhöht werden, wobei die maximale Anzahl vom Router beschränkt wird

Effekt

Die Anzahl der konkurrierenden http-Seitenabrufe auf die gecrawlten Webauftritte erhöht sich. Dies kann das Crawlen beschleunigen.

Seiteneffekt

Der eingesetzte Router ist möglicherweise nicht in der Lage die Anzahl der konkurrierenden Zugriffe zu bewältigen.

Warum wird diese Einstellung nicht per Standard gesetzt?

Um die Funktionsfähigkeit auch mit billigem Netzwerkgerät zusichern zu können und die gecrawlten Webauftritte vor zu massiven Zugriffen zu schützen.

Monitoring des Crawlers einschränken

Nachdem ein Crawlauftrag gestartet wurde, wird die Crawler Puffer Seite angezeigt. Diese Seite verwendet Ajax Technologien, um verschiedene XML Fragmente from eingebauten Webserver nachzulanden. Diese XML Fragmenge werden mit Hilfe von Datenbankanfragen erzeugt. Dafür werden IO Ressourcen benötigt, die dann für das Crawling nicht mehr zur Verfügung stehen.

Wie wird's gemacht?

Nachdem ein Crawlauftrag gestartet wurde, solle die Crawler Puffer Seite nicht länger angezeigt werden als nötig. Stattdessen kann die PPM Performance auf der Peer Administrationskonsole [http://localhost:8090/Status.html] oder der Überblick über das 'freeworld' Netzwerk Seite [http://localhost:8090/Network.html] überwacht werden.

Effekt

Es werden keine zusätzlichen IO Ressource benötigt und das Indexieren wird beschleunigt.

Seiteneffekt

Die Crawler Puffer Seite wird nicht angezeigt.

Warum gibt es diese Funktion, wenn sie YaCy so verlangsamt?

Dies würde bedeuten auf die Funktionen der Crawler Puffer Seite komplett zu verzichten. Diese enthält jedoch einig von den Anwendern sehr oft gewünschte Informationen, dass sie trotz des hohen Ressourcenverbrauchs angeboten wird.

File Sharing ausschalten

Andere Anwendungen, welche die vorhandenen IO oder Netzwerkressourcen stark beanspruchen verlangsamen die Arbeit von YaCy. Besonders File Sharing Anwendungen erzeugen diese problematische Last. Es ist für den Betrieb von YaCy keine Voraussetzung das File Sharing abzuschalten, aber es kann YaCy stark beschleunigen.

Router neu starten

Billige Router sind nicht in der Lage viele offene Netzwerkverbindungen korrekt zu handhaben. Falls Netzwerkverbindungen verlorengehen, können sich diese sogar sogenannte 'Zombi-Threads' verwandeln. Wenn ein Webauftritt gecrawlt wird, trifft der Crawler typischerweise auch auf eine Menge von nicht auflösbaren Links, welche Probleme verursachen können. Wenn die Internetverbindung zunehmend langsamer wird, handelt es sich sehr wahrscheinlich nicht eine von YaCy verursachte starke Last die Ursache, sondern eine größere Anzahl von 'Zombi-Threads' im Router. Ein Neustart des Routers löst dieses Problem.

Mehrere Crawls starten

Es mag merkwürdig erscheinen, aber mehrere verschiedene Crawljobs zu starten kann die Leistung erhöhen. Der Grund dafür ist, dass YaCy die Zugriffe auf verschiedene Webauftritte sehr gut ausbalancieren kann. Wenn die Server der gecrawlten Auftritte sehr langsam sind, oder einen Zugriff nur mit Verzögerung gestatten, hilft eine Verteilung der Zugriffe die Gesamtgeschwindigkeit zu erhöhen.

DATA auf ein RAID verschieben

Es ist noch nie getestet worden, aber die RWE auf einem RAID abzulegen wird das Indexieren vermutlich start beschleunigen, da die Indexierung sehr viel IO Last verursacht und genau dieser Engpass durch ein RAID vermieden wird.

Teile des Index auf getrennten Festplatten ablegen

Dies wäre eine gute Alternative zur RAID Idee: unter Verwendung von symbolischen Links lassen sich Teile auf verschiedene Festplatten verteilen. Dadurch dass die IO Last auf verschiedene IO Kanäle verteilt wird, wird die IO Leistungsfähigkeit in Summe gesteigert. Ein Pfad der sich hierfür anbieten würde wäre 'DATA/INDEX/foo/TEXT/bar', dies ist das Verzeichnis in welchem die RWI abgelegt sind, wobei foo und bar fuer freeworld/default per Standarteinstellung steht.

Was zum Teufel passiert hier gerade?

Das Folgende hat nicht im Geringsten mit YaCy zu tun und ist trotzdem relevant. Die sysstat Werkzeuge sind ein nettes Paket welches für viele Varianten der GNU Betriebssysteme wie beispielsweise Linux verfügbar ist.

Die Ausführung der folgenden Kommandos…:

while true; do  clear; tail -n 26 DATA/LOG/yacy00.log;   vmstat; iostat; sleep 20s; done

oder einfach

tail -f DATA/LOG/yacy00.log

(mit CTRL-C kann die Darstellung abgebrochen werden, wenn die Menge der Informationen zu überwältigent ist.)

… liefert möglicherweise einige Informatioen, welche helfen gezielt die Einstellungen für YaCy auf dem System zu optimieren.

Falls man es vorzieht die Informationen direkt in einem Fenster mitzuschneiden und führen iostat 10 oder wmstat 10 aus.

vmstat

IO (In/Out) meint das Lesen und Schreiben der Daten auf Festplatte. Der Rest des Systems muss auf die Ausführung warten. Dies kann dazu führen, dass das gesamte System sehr langsam wird, wenn die IO Belastung sehr hoch ist.

Swap meint die Bytes die durch die Hauptspeicherein- und Auslagerung gelesen und geschrieben werden. Wenn solche IO Aktivität verstärkt auftritt, sollte die für YaCy zugewiesene Menge an Hauptspeicher reduziert werden.

IO zeigt die Anzahl der ein- und ausgehenden Blöcke. Hohe Zahlen sind hier sehr schlecht, denn sie lassen sich als sehr starke Festplattenaktivität interpretieren.

Der CPU Bereich zeit die durch (us)er (Benutzerprozesse), (sy)stem Systemprozesse bzw. (id)le (verfügbare) Rechenzeit und schlimmstenfalls: (wa)iting (Wartezeit auf IO Aktivität). Ein Beispiel zeigt:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  0  24600   3584   4624 383804    0    1   203   185    6     4  8  2 75 15
 0  0  24600   7284   4576 380064    0    0   625    60 2016   297 11  9 68 12
 0  1  24600   2472   4636 384516    0    0   749    49 1976   300  5  2 79 14
 0  1  24600   4072   4656 382756    0    0  1365   730 2048   347  6  1 65 28
 0  1  24600   2716   4672 384032    0    0  1373   398 2105   301 29 19 38 15
 0  1  24600   3712   4652 382844    0    0  1223    74 2085   325 15 16 60  9
 0  0  24600   4076   4600 383520    0    0  1959   639 2058   353  5  2 53 41

Dieses System scheint gut zu funktionieren, da es kaum (wa)iting IO Wartezeit zeigt.

Im Gegensatz dazu hat das folgende System…:

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa
 0  2  59104   2404   2528 143560    0    0  1247   110 2593   493 28  2  9 61
 0  0  59104   2292   2380 143520    0    0  1393    33 2679   442  9  8  5 77
 0  1  59104   1160   2180 145600    0    0  1403     3 2689   380  6  6 16 73
 0  2  59104   1380   2092 145716    0    0  1601   140 2503   431  4  2  6 87
 0  3  59100   1032   1892 145864   30    0  1580   179 2748   489 19  4  7 69
 0  2  59100   1996   1760 145136    0    0  1485    59 2770   447 12  2  0 86
 0  2  59100   2200   1768 144840    0    0  1124    10 2663   466  3  2 16 78

… einen erheblichen Teil der Zeit mit dem Warten auf zu lesende (und weniger auf schreibende) Festplattenzugriffe zugebracht. Darüber hinaus hat das System kaum Rechenzeit sinnvoll verbrauchen können. Dies ist sehr schade und meint, dass Änderungen der Einstellungen zur Verminderung der IO Aktivitäten eine Verbesserung der Leistungsfähigkeit bringen können.

There is an english version of this page.