On 14 August 2017 at 17:11, J Decker <d3c...@gmail.com> wrote: > I monitored the process with ProcMon (I'm on windows 7 BTW) > > 12:55:34.7416316 AM node.exe 9012 WriteFile > \Device\HarddiskVolume17\javascript\gun.db\gun.db-wal SUCCESS Offset: > 188,416, Length: 20,480, I/O Flags: Non-cached, Paging I/O, Synchronous > Paging I/O, Priority: Normal > > this is the last in a block of writes that goes to -wal (which I thought > was memory mapped anyway and shouldn't even see writes to the file). It's > got the extra flags of non-caches, paging, synchrous etc... and takes the > significant portion of the time. >
AFAIK sqlite only ever uses mmap for read paths, never for writing. Anyway, durability is not free. The synchronous write you are seeing is part of sqlite's protocol to ensure robustness even across a machine crash or power loss event. You can play with pragmas etc. but turning off synchronous is a surefire way to end up with a corrupted DB if one of those occurs. The balanced strategy is to minimise the number of synchronous writes, by minimising the number of transactions as you've been advised. Where you draw the line depends on how much data you're willing to lose. > This is curious... locking at 1G of filespace? the db after 375k records > is only 24M. > That's allowed, and completely normal for sqlite. > There doesn't appear to be a way to disable locking? In this usage, the > database is used by Javascript from Node.exe which is single threaded. > There are no other processes that will access the database at any time > while the process is running, it's(sqlite) just a persistance layer that > provides indexing of values for partial updates of simple fields. "PRAGMA locking_mode = EXCLUSIVE" will eliminate most locks (there'll just be a few at the start and end). -Rowan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
