私は気づいたのですがWAL (先行書き込みログ)Firefox Web ブラウザで使用される SQLite データベース (*.sqlite) に関連付けられたファイル (*.sqlite-wal) は、非常に大きくなることがよくあります。文字通り、関連付けられた SQLite データベースの 150 倍を超えるサイズになり、数か月 (数年? 永久に?) そのサイズのままになることがあります。
によるとこのStackOverflowの回答考えられる解決策としては、影響を受ける各ストレージ データベースで次の SQLite プラグマ コマンドを実行することが挙げられます。
PRAGMA schema.wal_checkpoint(TRUNCATE);
理論的には、Firefoxの外部にあるSQLiteツールを使用してこの操作を実行することもできますが、内で一般的に、Firefox を使用すると最良の結果が得られます。 (たとえば、omni.jarFirefox の外部で作業しようとすると、Mozilla は非典型的な JAR 構造を使用するため、面倒な作業になる可能性があります。)
Firefox 内で、すべての SQLite ストレージ データベースをフラッシュして、その内容が対応するファイル内に完全に書き込まれるようにする方法はありますか.sqlite?
アップデート：
この質問を投稿する主な目的の1つは、storage-sync-v2.sqlite-walFirefoxプロファイルごとに32MBに達するまで大きくなるファイルを安全に処理することです。対応するデータベースにstorage-sync-v2.sqliteもstorage-sync-v2.shmファイルがありますが、かなり小さいままになる傾向があります。質問ごとに1つのトピック、私は書いたその目標に具体的に取り組むための関連質問。
答え1
問題のデータベースを含むプロファイルを使用している Firefox インスタンスを終了します。
一時プロファイルからFirefoxを起動します。ブラウザコンソールを開き、次のスニペットを貼り付けます。パス文字列を編集して、ターゲットプロファイルを指すようにします。Enter
すべての sqlite データベースに対して繰り返します。
うまくいけばうまくいくでしょうが、何かを試す前にプロファイルをバックアップしておいても問題ありません。
(()=>{
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();
})();
答え2
これは実は非常に良い質問ですが、あまり多くの人が尋ねません。
ファイル.sqlite-walは 32 MB の制限まで大きくなりますが、これはおそらく、Firefox の sqlite のコンパイル時にユーザー (またはパッケージ作成者) が定義したトランザクション ジャーナルの制限です。
コンパイル時にトランザクションジャーナルの制限を調整できるディレクティブは、SQLITE_DEFAULT_JOURNAL_SIZE_LIMITそしてそれは次のように定義される。バイトあなたの場合は32MBです。
また、SQLite で後からトランザクション ジャーナルの制限を調整することもできます。
PRAGMA schema.journal_size_limit = N ;（またいいえはバイト負の数は制限なし）
これを理解する必要があるのはソフト制限難しいことではありません。ジャーナルに書き込んでいるアクティブなプロセスがある場合、指定された制限に達した後も書き込みが続行されます。20 MB の制限を定義した場合でも、簡単に 2 GB に達する可能性があります。
この制限は非活性トランザクション ジャーナル。Firefox 開発者は、先行書き込みログと速度のバランスとして 32 MB が適切であると判断したと思います。
コンパイル後に PRAGMA サイズを調整する場合は、プロファイルごとに調整する必要があります。多くのプロファイル/データベースを使用する予定の場合は、セットで再コンパイルすることをお勧めしますSQLITE_DEFAULT_JOURNAL_SIZE_LIMIT。
この男性から有効な部分を引用すると、次のようになります。
WAL モードでは、先行書き込みログ ファイルはチェックポイント後に切り捨てられません。代わりに、SQLite は、上書きの方が追加よりも高速であるため、後続の WAL エントリに既存のファイルを再利用します。
journal_size_limit プラグマは、トランザクションまたはチェックポイント後にファイルシステムに残されるロールバックジャーナルおよび WAL ファイルのサイズを制限するために使用できます。トランザクションがコミットされるか WAL ファイルがリセットされるたびに、SQLite はファイルシステムに残されたロールバックジャーナルファイルまたは WAL ファイルのサイズをこのプラグマで設定されたサイズ制限と比較し、ジャーナルまたは WAL ファイルの方が大きい場合は制限に合わせて切り捨てられます。
上記のプラグマの 2 番目の形式は、指定されたデータベースの新しい制限をバイト単位で設定するために使用されます。負の数は制限がないことを意味します。ロールバック ジャーナルと WAL ファイルを常に最小サイズに切り捨てるには、journal_size_limit を 0 に設定します。上記のプラグマの 1 番目と 2 番目の形式はどちらも、1 つの整数列 (ジャーナル サイズ制限のバイト単位の値) を含む単一の結果行を返します。デフォルトのジャーナル サイズ制限は -1 (制限なし) です。SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT プリプロセッサ マクロを使用すると、コンパイル時にデフォルトのジャーナル サイズ制限を変更できます。
このプラグマは、プラグマ名の前に指定された単一のデータベース (または、データベースが指定されていない場合は「メイン」データベース) でのみ動作します。 単一の PRAGMA ステートメントを使用して、接続されているすべてのデータベースのジャーナル サイズ制限を変更する方法はありません。 サイズ制限は、接続されているデータベースごとに個別に設定する必要があります。
アップデート：
重要なSQLiteパラメータについて言及するのを忘れていました wal_autocheckpoint=N;（ここでNは番号32KiBのページ512KiB のジャーナルに。（OP はデータの切り捨て時にすでに言及しています）
より小さな自動チェックポイントを使用するように設定できます。ただし、これは SQLite のパフォーマンスに影響し、ブラウザにも影響します。チェックポイントが多すぎると、ブラウザの速度が低下します。
正しく自動チェックポイントを設定するリンクをたどってください。
また、このようにして開始された検問所は受け身つまり、SQLite はブロックせずに可能な限り多くのことを実行するはずです。
パッシブモードの男性の言葉を引用します:
SQLITE_CHECKPOINT_PASSIVE は、データベースのリーダーやライターが終了するのを待たずに、できるだけ多くのフレームをチェックポイントし、ログ内のすべてのフレームがチェックポイントされた場合はデータベース ファイルを同期します。SQLITE_CHECKPOINT_PASSIVE モードでは、ビジー ハンドラ コールバックは呼び出されません。一方、パッシブ モードでは、同時リーダーやライターが存在する場合、チェックポイントが未完了のままになる可能性があります。
上記のアップデートノートと同様に、このオプションはコンパイル時に設定することもできます。SQLITE_DEFAULT_WAL_AUTOCHECKPOINT=<pages>。
男性より:
このマクロは、WAL 自動チェックポイント機能のデフォルトのページ数を設定します。指定しない場合、デフォルトのページ数は 1000 になります。