io_uring ohne Readahead: Warum Turso 4,8 Millionen Cache-Misses mehr kassiert

Interessanter Artikel, aber er hat mir einen kleinen Panikanfall beschert. Benchmarking (mit TPC oder anderem) ist NICHT der richtige Weg, um hier den korrekten Ansatz zu bestimmen; das ist streng genommen nur für Datenbanken (typischerweise RDBMS) gedacht, die die gesamte Hardware, auf der sie laufen, effektiv "besitzen". Eine eingebettete Datenbank könnte auf diese Weise verwendet werden, wenn sie als Backend für eine reine CRUD-Anwendung dient, die so gut wie kein serverseitiges Rendering, Parsen, Validieren usw. durchführt und im Wesentlichen nur eine asynchrone HTTP-zu-SQLite-Schnittstelle ist. Aber eher wahrscheinlich wird eine eingebettete DB auf Maschinen (nicht unbedingt Servern) verwendet und bereitgestellt, die vielen Zwecken dienen, und sie muss sowohl innerhalb der Grenzen der verfügbaren Ressourcen der Maschine als auch in relativer Hinsicht am besten abschneiden, wobei notwendigerweise Kompromisse eingegangen werden, die Leistung für "Wert" in Bezug auf CPU- oder Speichernutzung opfern könnten.

Dies gilt nicht nur im Hinblick auf Benchmarking, sondern ist eine wesentliche Überlegung, *jedes Mal*, wenn Sie die Kontrolle über den Cache vom Kernel übernehmen, der das einzige Stück im Stack ist, das Einblick in den globalen Zustand hat und dem man vertrauen kann, dass er Speicher unter Druck zurückgibt, um sicherzustellen, dass alles gut zusammenspielt. Es beschränkt sich nicht nur auf Datenbanken oder sogar nur auf Speicher; zum Beispiel hatte FreeBSD mehr als genug Probleme, die auf ZFS mit einem separaten Cache vom Kernel zurückzuführen sind (trotz der engeren Integration zwischen den beiden und des Vorhandenseins verschiedener Mechanismen zur Bewältigung pathologischer [...]