I'm afraid I couldn't disagree more. Everything else works fine and uses the 
*page cache*. We run 1000s of machines that do. You are getting confused 
between fs-cache and the kernels page cache.

Jim

----- Original Message -----
From: "Michael Black" <mdblac...@yahoo.com>
To: "james vanns" <james.va...@framestore.com>, "General Discussion of SQLite 
Database" <sqlite-users@sqlite.org>
Sent: Thursday, 7 February, 2013 1:47:03 PM
Subject: RE: [sqlite] Strange eviction from Linux page cache

Nothing to do with SQLite.  NFS won't use cache by default.  You have to
mount it with the "fsc" option.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/ht
ml/Storage_Administration_Guide/fscachenfs.html



-----Original Message-----
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of James Vanns
Sent: Thursday, February 07, 2013 3:56 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] Strange eviction from Linux page cache

Hello list. I'd like to ask someone with more SQLite experience than me a
simple question. First, some background;

Distribution: Scientific Linux 6.3
Kernel: 2.6.32-279.9.1.el6.x86_64
SQLite version: 3.6.20

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).

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. This is quite
detrimental to performance because our resulting data files (SQLite DB
files) are between 100 to 400 MB in size. We *want* it to be cached - the
whole thing. The page cache would do this nicely for us and allow multiple
processes on the same machine to share that data without any complication.

I understand that SQLite implements it's own internal page cache but why, on
a standard desktop machine, will it not use the page cache. Is there anyway
of forcing it or bypassing the internal page cache in favour of the job that
Linux already does? I cannot find any reference to O_DIRECT or madvise() or
favdise() etc. in the code. The following PRAGMAs don't help either;

PRAGMA writable_schema = OFF
PRAGMA journal_mode = OFF
PRAGMA synchronous = OFF

PRAGMA cache_size = -<size of DB file in kbytes>

Obviously that last one works - but only for a single process and for the
lifetime of that process. We want the pages to reside in RAM afterwards.

Anyone out there know how to correct this undesirable behaviour?

Regards,

Jim Vanns

-- 
Jim Vanns
Senior Software Developer
Framestore
_______________________________________________
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