> This is likely a naive response, but on Linux have you thought >using /dev/shm? It's a tmpfs ramdisk that is needed by POSIX shared memory >calls shm_open and shm_unlink in glibc 2.2 and above. It grows and shrinks as >required and uses almost no memory if it's never populated with files. > >As a simple test I created /dev/shm/test.d using sqlite3, created a simple >table and populated it with a couple of rows of data. I connected to the >database from another sqlite instance, and I was able to read the data just >fine. After closing down both instances the test database was still there (no >surprise, it's a filesystem after all). > > Dunno if that helps any. > > Glenn McAllister > SOMA Networks, Inc.
Hmm, great idea! I forgot that .... This solves the problem with little databases, really. But as I said in another e-mail, I need to use shared memories greater than 5GB .... :-) The problem with lots of RAM is the work the kernel has to do to control all this memory .... Think: each memory page (in linux) is 4kbytes. How many pages are necessary to map 8GB of memory ? So, using shared memory created with the flag SHM_HUGETLB (HugeTLB file system support), each memory page has the size of 4M (with kernels compiled with 4GB option) and 2M (with kernels compiled with 64GB option). Using pages with 2M or 4M saves a lot of kernel work. The tmpfs doesn't use this strategy, having the same performance of malloc'ed memory (but the locks will work and it's possible to share the database with other processes :-) []'s Mateus Inssa
