2 Min. Lesezeit KI-generiert

14 CPU-Kerne nur für Scraper: Was Crawler bei git.kernel.org anrichten

Artikel als Markdown kopieren

Konstantin Ryabitsev hat nachgerechnet, was der Kernel-Server für Crawler ausgibt. Das Ergebnis: Auf fünf Maschinen laufen 14 Kerne durchgehend nur dafür, Git-Commits als HTML zu rendern – mehr Rechenzeit als für alle echten Zugriffe zusammen.

Featured image for "14 CPU-Kerne nur für Scraper: Was Crawler bei git.kernel.org anrichten"

Konstantin Ryabitsev betreut die Infrastruktur hinter git.kernel.org, dem offiziellen Zuhause der Linux-Kernel-Repositories. Am 7. September hat er eine Zahl in Umlauf gebracht, die in Entwicklerkreisen ziemlich schnell die Runde gemacht hat.

Die Rechnung

Über fünf geografisch verteilte Server hinweg sind 14 CPU-Kerne durchgehend damit beschäftigt, Git-Commits als HTML-Seiten zu rendern – für Scraper. Sein Satz dazu, sinngemäß: Sie verbrennen mehr CPU-Zyklen damit, Commits für Scraper zu rendern, als für alle anderen legitimen Zugriffe zusammen, Git-Clones eingeschlossen.

Das ist der Punkt, der wehtut. Dass Crawler Last erzeugen, war ja immer so. Neu ist, dass die Bot-Last die Last der eigentlichen Nutzer überholt hat. Ein Git-Clone ist verglichen damit billig: eine Anfrage, ein Packfile, fertig. Ein Crawler geht stattdessen jeden einzelnen Commit als eigene HTML-Seite durch, und jede dieser Seiten muss der Server frisch bauen.

Warum das jeden betrifft, der etwas hostet

Simon Willison, der die Sache aufgegriffen hat, denkt dabei an sein eigenes Projekt: Datasette baut Seiten dynamisch aus Datenbanken. Jede Filterkombination ist eine eigene URL, und jede davon sieht für einen Crawler aus wie eine weitere Seite, die man mitnehmen sollte. Gleiches gilt für Wikis, Issue-Tracker, Kartendienste, Archive – für alles, was mehr URLs hat als Inhalte.

Ich finde die Geschichte deshalb wichtig, weil sie eine Rechnung sichtbar macht, die sonst nirgends auftaucht. Trainingsdaten sind für die eine Seite ein Rohstoff und für die andere eine Serverrechnung. Bei einem Projekt mit Sponsoren wie kernel.org fällt das auf. Bei der Person, die abends ein Archiv auf einem kleinen Server betreibt, fällt es aus.

Robots.txt hilft dabei nur, solange sich jemand daran hält. Was praktisch hilft, ist unangenehmer: teure Ansichten hinter Rate Limits, statische Exporte statt On-Demand-Rendering, und die Bereitschaft, ganze Pfade für alles zu sperren, was keinen Browser mitbringt. Das ist keine Lösung, das ist Schadensbegrenzung – und im Moment die einzige, die funktioniert.

Quellen: Simon Willison: Creepy crawlies