<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I've set up a sqlite3 cache using addition pragma statements to set journal mode to WAL and journal mode to normal.  <div><br></div><div><div>   <cache name="sqlite" type="sqlite3"></div><div>      <pragma name="synchronous">1</pragma></div><div>      <pragma name="journal_mode">wal</pragma></div><div>      <dbfile>./{tileset}.sqlite3</dbfile></div><div>   </cache></div></div><div><br></div><div>These setting "should" increase performance however I've noticed that when seeding the cache the wal file is growing excessively over time (+50GB) which would result in slower reads.  I believe this is being caused by seeding the cache using multiple threads (-n 4) causing checkpoint starvation as defined here (<a href="https://www.sqlite.org/wal.html">https://www.sqlite.org/wal.html</a>) as:</div><div><br></div><div>"</div><div><div>Checkpoint starvation. A checkpoint is only able to run to completion, and reset the WAL file, if there are no other database connections using the WAL file. If another connection has a read transaction open, then the checkpoint cannot reset the WAL file because doing so might delete content out from under the reader. The checkpoint will do as much work as it can without upsetting the reader, but it cannot run to completion. The checkpoint will start up again where it left off after the next write transaction. This repeats until some checkpoint is able to complete.</div><div><br></div><div>However, if a database has many concurrent overlapping readers and there is always at least one active reader, then no checkpoints will be able to complete and hence the WAL file will grow without bound</div><div>"</div><div>This is verified by manually attempting to force the checkpoint in the command line while the seeder is running :</div><div><div>sqlite> PRAGMA wal_checkpoint(TRUNCATE);</div><div>1|-1|-1</div></div><div>The first column is usually 0 but will be 1 if a RESTART or FULL or TRUNCATE checkpoint was blocked from completing, for example because another thread or process was actively using the database.<br></div><div><br></div><div>.</div><div><br></div><div><br></div></div><div><br></div></div></div></div></div></div></div>