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

Reply via email to