Hi Simon. Yes, the connection is closed - the process that writes the DB file isn't memory resident (meaning, it isn't a daemon). The connection is implicitly closed (and transaction committed?) by the process terminating. The problem only arises when the file is hosted by an NFS server - locally, we do not see the problem.
Hours can go by before the first read. Thanks, Jim PS. Using the vmtouch tool we can see that the page cache never really reads-in and retains any of the file data. ----- Original Message ----- From: "Simon Slavin" <slav...@bigfraud.org> To: "General Discussion of SQLite Database" <sqlite-users@sqlite.org> Sent: Thursday, 7 February, 2013 1:47:31 PM Subject: Re: [sqlite] Strange eviction from Linux page cache On 7 Feb 2013, at 9:56am, James Vanns <james.va...@framestore.com> wrote: > We have a single process that, given some data, does some processing and > writes it all to a single SQLite DB file. This is a write-once process. When > this task is finished, the file itself is marked as read only (0444). Can you verify that your connection to the file is closed, and any journal files relating to the database are already deleted before the protection on the file is changed ? > This file exists on an NFS share for multiple users to read - nothing further > is ever written to it. The problem we're seeing is that when this DB file is > read from (over NFS) none of the pages are cached (despite ~12GB free for > page cache use) or at least immediately evicted. SQLite uses very simple file calls and doesn't rely on a deep understanding of file systems. It may be that whatever NFS driver you're using never uses the cache even if the file is market read-only. In other words, this is done at the driver level rather than inside SQLite. Can you test this by, for example, accessing a long read-only text file over the same NFS connection and seeing if reads of different parts of this text file suggest that it is or isn't being cached ? Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- Jim Vanns Senior Software Developer Framestore _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users