Mir ist aufgefallen, dass dieWAL (Write Ahead-Log)Dateien (*.sqlite-wal), die mit den vom Firefox-Webbrowser verwendeten SQLite-Datenbanken (*.sqlite) verknüpft sind, werden oft ziemlich groß. Sie können buchstäblich über 150 Mal so groß werden wie die zugehörigen SQLite-Datenbanken und diese Größe über Monate (Jahre? ewig?) behalten.
Entsprechenddiese StackOverflow-Antwort, eine mögliche Lösung könnte darin bestehen, den folgenden SQLite-Pragma-Befehl auf jeder betroffenen Speicherdatenbank auszuführen:
PRAGMA schema.wal_checkpoint(TRUNCATE);
Theoretisch könnte man ein SQLite-Tool außerhalb von Firefox verwenden, um diese Aktion auszuführen, aber ich habe gelernt, dass die Durchführung von AktioneninnerhalbFirefox liefert im Allgemeinen die besten Ergebnisse. (Versuchen Sie beispielsweise, omni.jaraußerhalb von Firefox zu arbeiten. Das kann ein Ärgernis sein, da Mozilla eine untypische JAR-Struktur verwendet.)
Gibt es in Firefox eine Möglichkeit, alle SQLite-Speicherdatenbanken zu leeren, sodass ihr Inhalt vollständig in die entsprechenden .sqliteDateien geschrieben wird?
AKTUALISIEREN:
Ich möchte erwähnen, dass eines der Hauptziele beim Posten dieser Frage darin besteht, sicher mit der storage-sync-v2.sqlite-walDatei umzugehen, die wächst, bis sie in jedem Firefox-Profil 32 MB erreicht. Die entsprechende Datenbank, storage-sync-v2.sqlite, hat auch eine storage-sync-v2.shmDatei, bleibt aber eher klein. Um die Dinge auf das Wesentliche zu konzentrierenein Thema pro Frageschrieb ich einedamit verbundene Frage, um speziell auf dieses Ziel einzugehen.
Antwort1
Beenden Sie die Firefox-Instanz, die das Profil verwendet, das die betreffenden Datenbanken enthält.
Starten Sie Firefox von einem temporären Profil aus. Öffnen Sie die Browserkonsole und fügen Sie den folgenden Ausschnitt ein. Bearbeiten Sie die Pfadzeichenfolge so, dass sie auf das Zielprofil verweist. Drücken SieEnter
Wiederholen Sie dies für jede SQLite-Datenbank.
Hoffentlich klappt das wie am Schnürchen, aber es kann nicht schaden, Ihr Profil zu sichern, bevor Sie etwas versuchen.
(()=>{
let file = new FileUtils.File("/pathToTargetProfile/places.sqlite"); // edit this string
let db = Services.storage.openDatabase(file);
let stmt = db.createStatement("PRAGMA wal_checkpoint(TRUNCATE)");
stmt.executeStep();
console.log(stmt.row); //this might provide useful info
stmt.finalize();
db.close();
})();
Antwort2
Das ist tatsächlich eine wirklich gute Frage, die nicht viele Leute stellen.
Die .sqlite-walDatei wächst auf die 32 MB-Grenze an, da dies wahrscheinlich die Grenze des Transaktionsjournals ist, die Sie (oder Ihr Paketersteller) während der Kompilierung des SQLite Ihres Firefox definiert haben.
Die Direktive, mit der Sie das Limit des Transaktionsjournals während der Kompilierung anpassen können, heißtSQLITE_DEFAULT_JOURNAL_SIZE_LIMITund ist definiert inBytes. In Ihrem Fall sind es 32 MB.
Sie können das Limit des Transaktionsjournals später auch in SQLite wie folgt anpassen:
PRAGMA schema.journal_size_limit = N ;(wiederNist inBytes, negative Zahl setzt keine Grenze)
Was Sie verstehen müssen, ist einweiche Grenze, keine schwierige. Wenn Sie einen aktiven Prozess haben, der in das Journal schreibt, wird er auch dann weiterschreiben, wenn das angegebene Limit erreicht ist. Es können leicht 2 GB erreicht werden, selbst wenn Sie ein Limit von 20 MB definiert haben.
Diese Grenze gilt fürinaktivTransaktionsjournal. Ich denke, die Firefox-Entwickler haben entschieden, dass 32 MB das richtige Gleichgewicht zwischen einem Write-Ahead-Log und Geschwindigkeit sind.
Wenn Sie die PRAGMA-Größe nach der Kompilierung anpassen möchten, müssen Sie dies für jedes Ihrer Profile tun. Wenn Sie vorhaben, viele Profile/Datenbanken zu verwenden, möchten Sie es wahrscheinlich mit dem SQLITE_DEFAULT_JOURNAL_SIZE_LIMITSet neu kompilieren.
Um gültige Abschnitte aus dem Buch zu zitieren:
Im WAL-Modus wird die Write-Ahead-Logdatei nach einem Checkpoint nicht gekürzt. Stattdessen verwendet SQLite die vorhandene Datei für nachfolgende WAL-Einträge erneut, da das Überschreiben schneller ist als das Anhängen.
Das Pragma journal_size_limit kann verwendet werden, um die Größe von Rollback-Journal- und WAL-Dateien zu begrenzen, die nach Transaktionen oder Prüfpunkten im Dateisystem verbleiben. Jedes Mal, wenn eine Transaktion festgeschrieben oder eine WAL-Datei zurückgesetzt wird, vergleicht SQLite die Größe der im Dateisystem verbleibenden Rollback-Journal- oder WAL-Datei mit der durch dieses Pragma festgelegten Größenbeschränkung. Wenn das Journal oder die WAL-Datei größer ist, wird sie auf die Beschränkung gekürzt.
Die zweite Form des oben aufgeführten Pragmas wird verwendet, um ein neues Limit in Bytes für die angegebene Datenbank festzulegen. Eine negative Zahl bedeutet kein Limit. Um Rollback-Journale und WAL-Dateien immer auf ihre Mindestgröße zu kürzen, setzen Sie das Journal_size_limit auf Null. Sowohl die erste als auch die zweite Form des oben aufgeführten Pragmas geben eine einzelne Ergebniszeile zurück, die eine einzelne ganzzahlige Spalte enthält – den Wert des Journalgrößenlimits in Bytes. Das Standard-Journalgrößenlimit ist -1 (kein Limit). Das Präprozessormakro SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT kann verwendet werden, um das Standard-Journalgrößenlimit zur Kompilierzeit zu ändern.
Dieses Pragma funktioniert nur mit der einzelnen Datenbank, die vor dem Pragmanamen angegeben wurde (oder mit der „Haupt“-Datenbank, wenn keine Datenbank angegeben wurde). Es gibt keine Möglichkeit, die Journalgrößenbeschränkung für alle angeschlossenen Datenbanken mit einer einzigen PRAGMA-Anweisung zu ändern. Die Größenbeschränkung muss für jede angeschlossene Datenbank separat festgelegt werden.
Ein Update:
Ich habe vergessen, einen wichtigen SQLite-Parameter zu erwähnen wal_autocheckpoint=N;(wobei N istNummervon 32KiBSeitenin einem 512-KiB-Journal). (Was OP bereits beim Kürzen der Daten erwähnt hat)
Sie können es so konfigurieren, dass kleinere Autocheckpoints verwendet werden. Beachten Sie, dass dies die Leistung von SQLite und damit des Browsers beeinträchtigt. Zu viele Checkpoints verlangsamen den Browser.
Um richtigAuto-Checkpoint konfigurierenFolge dem Link.
Wichtig ist auch, dass auf diese Weise initiierte KontrollpunktePASSIV. Das bedeutet, dass SQLite so viel wie möglich tun sollte, ohne zu blockieren.
Um den Mann für den PASSIVEN Modus zu zitieren:
SQLITE_CHECKPOINT_PASSIVE Prüfpunkte für so viele Frames wie möglich, ohne darauf zu warten, dass Datenbankleser oder -schreiber fertig sind. Synchronisieren Sie dann die Datenbankdatei, wenn alle Frames im Protokoll geprüft wurden. Der Busy-Handler-Callback wird im SQLITE_CHECKPOINT_PASSIVE-Modus nie aufgerufen. Andererseits kann der passive Modus den Prüfpunkt unvollendet lassen, wenn gleichzeitige Leser oder Schreiber vorhanden sind.
Wie oben im Update-Hinweis können Sie diese Option auch während der Kompilierung mitSQLITE_DEFAULT_WAL_AUTOCHECKPOINT=<pages>.
Vom Menschen:
Dieses Makro legt die Standardseitenanzahl für die automatische Checkpointing-Funktion von WAL fest. Wenn nichts angegeben wird, beträgt die Standardseitenanzahl 1000.