On 5 Dec 2012, at 8:11am, Keith Chew <keith.c...@gmail.com> wrote: > Ah, do you think the read on the OS level is starving the writes? > There are not many DB selects from the app, but there are other read > IO activities happening in the background. Still it doesn't make > sense, because WAL mode ensures from sqlite's point of view, the > reader will not be blocked by the writer. So, sqlite is subjected to > similar levels of read IO activity as Mysql (because there are very > few DB selects).
You may be right. If your cache is big enough, some storage setups prioritise all reads ahead of writes. They'll accumulate write commands in cache but won't actually do them until nothing is asking to read data any more. The theory is that all programs, sooner or later, will need some writes to happen before they know what to read next. In these days when programs do several things simultaneously the theory is wrong, and many programs do things like constantly updating one window while allowing another to be used to input new information. If they ask for data to be read fast enough, the writes never get done. This is called 'write starvation'. I can verify that there's nothing in SQLite that makes this assumption or works this way. What you're seeing must be provided by some subset of your firmware, networking protocol, framework or database library. The cures you've already discovered: don't use that combination of PRAGMAs on that setup. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
