I guess the problem with those modules is, that they are all too general/generic and shared memory is a fairly OS specific thing.

One "solution" could be to fork() your second server after you have opened all necessary files in your first server, but this won't be a LRU cache then but simply shared file descriptors and won't help with your problem. Maybe you could rethink your problem and rearrange the hashes and files into one big (SQL) database to offload that burden to the database, but the "free" databases aren't really better than tied hashes I guess.

One thing you could maybe do is, instead of splitting up your application into two identical processes, split up your application into two different parts, a server part that acts (more or less) like a database server and one (or more, depending on the number of CPUs you get) client that submits the requests to the server. Depending on the data size, the data could be moved via shared memory - but the bottleneck would still be with that one database server process ...

Update:A few people have said that (at least in their opinion) a free database should be at least on par if not better than a tied hash. This can be (IMO) only true if the whole database structure is also changed and the access is moved completely to SQL (that is, JOINs are used and other stuff that allows the database to optimize the query).