I am developing this solution for an AIX machine. I am not sure if it does any such optimization for the temp file system. As someone recommended, I can probably implement a VFS for Shared-memory, but that seems to be too much work :)
I am inclining towards a file-based DB with syncs turned off. If the performance is not satisfactory, then I might look at implementing a VFS. Thanks, ~Manuj On Tue, May 11, 2010 at 8:39 AM, Eric Smith <eas....@gmail.com> wrote: > Manuj Bhatia wrote: > > > I do not have a requirement of persistence in my current design, but I > > expect that we might extend this shared-queue solution to more areas of > > the server and will require some sort of persistence then. > > That is one of the main reasons I do not want to use IPC queues (there > are > > other reasons like fixed message sizes, minimal support for queue/message > > level metadata). > > OP might consider creating a database file on a tmpfs filesystem. > The OS tricks SQLite (and everything in user space) into thinking the > file is a normal file with all the usual properties thereof -- but > it's backed by RAM and not any persistent medium. You'll get the perf > benefits you wanted, along with the relatively easy ability to make the > DB persistent later. > > Fedora 12 has one of these mounted at /dev/shm by default, though I > presume any modern Linux will support this. > > Caveat (1). I ran 'make test' on SQLite 3.6.23.1 on my box (Linux ___ > 2.6.32.11-99.fc12.i686 #1 SMP Mon Apr 5 16:32:08 EDT 2010 i686 athlon > i386 GNU/Linux) from within a tmpfs filesystem and 23 tests failed: > > shared-1.1.1 shared-1.2.1 shared-1.4.1.1 shared-1.4.1.2 shared-1.4.1.3 > shared-2.1.1 shared-2.2.1 shared-2.4.1.1 shared-2.4.1.2 shared-2.4.1.3 > stmt-1.2 stmt-1.3 stmt-1.4 stmt-1.5 stmt-1.6 stmt-1.7 stmt-2.1 stmt-2.2 > stmt-2.3 stmt-2.5 tempdb-2.2 tempdb-2.3 tkt2565-1.X > > I wanted to investigate to see why but haven't had the time -- it has > to do with the global Tcl variable sqlite_open_file_count. Running the > fixture on just those test files yields passes (every time), but running > the whole 'veryquick' suite yields failures (every time). I see there's > machinery to try to clear all state between test runs -- obviously this > is not successful in my test. > > The testfixture is dynamically linked against these libraries: > linux-gate.so.1 => (0x00511000) > libtcl8.5.so => /usr/lib/libtcl8.5.so (0x005cb000) > libdl.so.2 => /lib/libdl.so.2 (0x00d1f000) > libm.so.6 => /lib/libm.so.6 (0x00d42000) > libpthread.so.0 => /lib/libpthread.so.0 (0x00d26000) > libc.so.6 => /lib/libc.so.6 (0x00ba9000) > /lib/ld-linux.so.2 (0x00b87000) > > Caveat (2). I don't claim this is the best solution for the OP -- just > a possibility. > > Eric > > -- > Eric A. Smith > > I think there's a world market for about five computers. > -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943 > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
