Quoth James Vanns <james.va...@framestore.com>, on 2013-02-07 16:32:49 +0000: > And I can confirm here that, over NFS, using just the sqlite3 CLI > the Linux page cache is cleared every time - all the damn pages that > were read in from disk are read in all over again; > > sqlite3 /nfs/file.db > $ select * from big_table # (vmtouch reports 163MB read and resident) > (don't even have to close sqlite3) > $ select * from big_table # (all pages evicted, SQLite begins to read 163MB > over NFS again)
If you don't even have to close the SQLite shell for that to happen, I'm guessing it's an interaction with POSIX/fcntl file locking, which theoretically works over NFS but as I recall has some oddities. What happens if you do this? pragma locking_mode = exclusive; select * from ...; select * from ...; If the database is write-once and read-only, then exclusive locking mode should not actually block any readers (since no write locks are ever taken). If that helps in the two-selects case, it still might not help if unlock at process termination triggers your performance issue as well. In that case, try specifying the "unix-none" VFS to sqlite3_open_v2 for those readers only, which should turn all locking off for them. My other guess would be an interaction with the early open calls; AFAIK, unless SQLite is explicitly told to open the database read-only, it will try an O_RDWR open first, which will fail on a 0444 file but might plausibly trigger unfortunate codepaths somewhere in the kernel in the process of failing. I'm interested to see whether any of the above does any good, to improve my own knowledge of NFS. :-) ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
