typo: should have been "around 700MB and 500MB"
On 09/25/2015 03:58 PM, gunnar wrote: > Hi Clemens, > > Here are some of the settings and the integrity check that we always > prints at start up of our process: > > [query:PRAGMA synchronous=OFF][changes:0][total changes:0] > [query:PRAGMA foreign_keys=ON][changes:0][total changes:0] > [query:PRAGMA cache_size=10000][changes:0][total changes:0] > [query:PRAGMA journal_mode=WAL][changes:0][total changes:0] > OrderCallbackStorage::checkDatabaseIntegrity: row 1 [ok] > > > No virtualization and also no network file system. > > What do you exactly mean with "But in any case, as others have already > said, it is not possible for a write transaction to lock out a read > transaction _in the middle_."? I do see that records are being > inserted while I made those stack traces. > > I have a fifteen minute window / 24hours, is it enough for VACUUM? the > database file and wal file are at the moment around 700KiB and 500KiB > resp. Probably that can't be answered and I should just try it. > > We'll check the disk for bad sector(s). > > > Thanks for your help! > Gunnar > > > > On 09/25/2015 03:40 PM, Clemens Ladisch wrote: >> gunnar wrote: >>> (select uuid from session where date = (select max(date) from session)) >> This can be optimized to >> (select uuid from session order by date desc limit 1) >> but the speed of this subquery does not matter. >> >>> (SELECT max(cb_seq_num) FROM ordercallback WHERE >>> server_order_id=cb.server_order_id AND sessionuuid=cb.sessionuuid >>> AND working=1) >>> 3|0|0|SEARCH TABLE ordercallback USING INDEX ordercallback_index3 >>> (server_order_id=? AND sessionuuid=? AND working=?) >> You could try to speed this up with a covering index by adding the >> cb_seq_num column to the index. >> >> >> But in any case, as others have already said, it is not possible for >> a write transaction to lock out a read transaction _in the middle_. >> >> Are you using WAL? Some network file system? Virtualization? >> >> If neither the CPU nor the disk are busy, but SQLite is not sleeping, >> then what is it waiting for? This sounds like a defective disk sector. >> >> Try running "PRAGMA integrity_check" on (a copy of) the DB. >> Try VACUUM. >> >> >> Regards, >> Clemens >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users at mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >> > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
