Shared Memory to make objects of an application persistent?

Hello,

I have a question concerning shared memory (in linux-environment). In our company we currently have an application that is restarted once in a while. There are multiple instances running of this application (on different physical machines), and all access the same centralized database. Because of IO and Network bottleneck the start gets very slow, and takes about 10 Minutes. Besides some new data, most of the data stays the same, so reading from the database again is quite redundant. An idea is to write all relevant object to a shared memory segment, when the application is shut down. A second dummy process attaches to the same shared memory (just so that some process is still attached). If the application is restarted, it is attached again to its shared memory, and reads it to its own adress range again. There might occur a difference regarding the data so it might me necessary to load some new data afterwards, but that is different problem.

The current idea is to serialize all Objects (could be about 1-2 Gigabyte) with Apache Thrift, and write them into shared memory. With Thrift the data is more or less ordered, so creating the objects anew is possibly easier (not sure here).

My Question is:
- Does it even make sense to consider shared memory in this scenario. I've read a lot stuff about in the last few days, and for now I don't see big disadvantages (except if the application crashes, in this case I've to read from database again). On the other hand I don't know how to really implement this functionality (as I'm no experienced Developer)
- Should I aim for Boost::Interproces, considering even memory mappable files, or stay with the traditional shmat (and stuff..)?
- I guess 1-2 Gigabyte shared memory will be necessary. This amount is only needed in the gap between application shutdown and restart. Will the sheer amount of needed shared memory be a problem (all examples I found just used a few Bytes or Kilobytes)
- Does it make sense to use Thrift in this scenario?

If I am missing any information, please inform me.

Thanks in advance

Michael

shared memory only works for applications running on the same physical machine. Typically, the apps also need to be running under the same instance of the OS if you're virtualizing multiple OSes on a single PC, though there are a few exceptions where it's possible to used shared memory across OS boundaries (I know this can be done with Windows. I don't know if Linux has something similar).

If the database is updated infrequently. it might be feasible to have a separate instance of the DB on each computer and use a synchronisation system to keep all the DB's on the different computers in check. This can be anything from very simple to complex depending on how 'hard' or 'tight' you want the synchronisation to be and if updates need to be transaction safe across all instances.

1GB of shared memory could be problematic if it needs to be available in a single contiguous chunk and you need this on a 32bit OS.


another alternative might be some kind of client side caching so you don't actually fetch any date from the remote DB unless the cached data you have has become invalid (this requires some form of mechanism to validate/update the cache).

Thanks for the fast answer.
Although there a multiple instance of the application on different machines, each machine would use its own shared memory (with its own dummy process attaching to it), so the communication only occurs within a machine. The distributed database approach was already discarded (guess we don't have the time to implement it in a satisfying way) and the client side caching is the other alternative we are currently discussing.

Shared Memory doesn't have to be in one big chunk (as I heard a few ours ago), I just have to make sure an object is not splitted between to chunks. If I am remembering all my Keys somewhere, I can just iteratively attach to the shared memory area again, and deserialize my data back into my application, right? So technically shared memory would be a working alternative?

Quote:

---

Originally Posted by micbeh

In our company we currently have an application that is restarted once in a while.

---

wouldn't be easier to avoid restarting the process altogether? that is, why do you need to restart in the first place ? for example, if you need to restart in order to update some parts of the program, then some kind of "component" dynamic linking mechanism ( ala COM ) would be more appropriate, ain't it ? I mean, that dummy process looks like more an hack than a real solution, especially on the long run ...

Hello,

it is a high performance application, and as such, dynamic linking proved to be slower than our current solution (as far as I am informed). Additionally, from an organizational point of view the already quite complex application would get much more complex with dynamic linking.

When the program starts up, can you start up the program and background load parts of the database?

Ansynchronous load from database is already done for some objects. However, the application is a http-Server and needs to answer request based on the current state of the database. If it takes 10 Minutes to load the data ansynchronous, the server would send wrong http-responses during this period. We allow this misbehaviour under special circumstances, but loading all in background would make it worse.

Isn't the first question that needs to be answered is why do you have the need to keep restarting the process(s) as asked by Superbonzo in post #4? If this is due to planned maintenance then couldn't this be planned for a time when 10 minutes downtime would be acceptable? If it is due to other issues wouldn't time be better spent investigating why and fixing these so that unplanned restarts are not needed? :confused:

I have to agree, that restarting the process is not the best idea in the first place. However, as we all now bugs may occur and lead to a crashing process. Though the main problem is the error and has to be fixed asap, restarting the process is inevitable. Some kind of maintenance plan would be a good idea for standard updates, though it would not help in case of bugs. See it more like an addition for special problems. If you have to restart only once per month (because you have stuff like a maintenance plan) it would be still quite annoying, if you have to restart 100 applications and every restart takes 5-10 Minutes.

Quote:

---

Originally Posted by micbeh

Ansynchronous load from database is already done for some objects. However, the application is a http-Server and needs to answer request based on the current state of the database. If it takes 10 Minutes to load the data ansynchronous, the server would send wrong http-responses during this period.

---

Another approach might be to go with a layered architecture and rather than having your http-server access the database, you might consider moving the data access into a web service pool (with multiple nodes). Under this approach, a node can be taken offline for any updates and isn't brought into the pool until after it completes its initial cache load. That way, the http-Server would always have access to data from one or more web service nodes.