A general game loop should suffice, regardless of how many "games" you're handling. I would suggest considering having a threadpool for your "games" and a separate thread pool for your I/O and DB stuff. Say a 16-core server would use 8 threads per pool would be a good start.
The concept is that your main thread runs through the current number of active games and runs a frame on them. The frame does everything from collecting current network messages, handling physics, updating objects, etc.... Then once that frame is done, the main thread runs a frame on the next game instance, and just constantly loops this.
This is how a little card game server concept of mine behaves, and it seems to work just fine with ~10 active sessions, 2-8 people per session, on a 4-core 2.66ghz system that I tested it on. One thing to look out for is that if one "frame" takes an abnormal amount of time, it will severely affect the performance of the rest.
Therefore if you're going with this solution I highly recommend that everything you update is able to take variable delta time steps with potentially large steps without breaking. It means making sure that your physics updates are done correctly, and placing certain limiters so as to avoid those possible slow downs.
As far as open-source solutions, not really the best place to ask for one. Who knows if someone might have something like that, but you're probably better off researching that bit on your own.