On 2018/07/31 5:02 PM, Andrzej Fiedukowicz wrote:
Hi mailing list gurus!
I will start with TL;DR version as this may be enough for some of you:
* We are trying to investigate an issue that we see in diagnostic
data of our C++ product.
* The issue was pinpointed to be caused by timeout on
`sqlite3_open_v2` which supposedly takes over 60s to complete (we only
give it 60s).
* We tried multiple different configurations, but never were able to
reproduce even 5s delay on this call.
The only thing that comes to mind (others may know of more scenarios) is
that there was a hot journal file that needed to be rolled back. If
SQLite (or the host application) crashes in the midst of a transaction,
there will remain a journal file, which depending on the Journal mode,
will contain either the uncommitted or committed bits (I see you tried
both WAL and DELETE, so I assume the difference doesn't matter).
Rolling back a hot journal can take some time, granted, I haven't seen
many >60s time-frames, but I have seen several seconds, which means it
might be the case[*]. And if you limit the time to n where the journal
rollback cannot complete by n time, then every time you start the
program, you will probably have the hot journal again, and the rollback
starting again, which could explain the phenomenon where once triggered,
the time-out occurs constantly on re-starts - although, a computer
re-start shouldn't fix this (unless perhaps a cache-holdup is
responsible for slow IO before a restart or such, but that's just
guesswork).
Lastly, version 3.10 is ancient. You may well have researched that
change-logs for fixes, but I don't think this is a bug in SQLite, hence
not seeing any fixes. If the rollback is allowed enough time to
complete, it should get fixed, that said, if you DID update SQLite, the
simple fact that it runs probably around 50% faster than it used to back
at 3.10[**] might already have saved your system (in that the time-out
may have sufficed on a faster DB Engine).
[*] - I'm also not 100% that the open_v2 thing itself does the
detecting & rollback of hot journals, but I think so.
[**] - I'm just ball-park guessing here, I think Richard posted some
time-lines at some point with speed increases over versions, but I don't
have it handy.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
