Mono had two issues we hit in production for server processes:
1. The GC was poor. There's actually a couple of pieces to this one: it's non-compacting, so your app gradually slows down; and (because it's Boehm) it has to guess at what's a pointer, and sadly just doesn't do a good job, so you gradually leak RAM through no fault of your own. The new GC, which I think is called SGen, is a precise collector, so I assume that it fixes the memory leaks, but it's still non-compacting, meaning you're probably going to want to restart the process every once and awhile to prevent serious heap fragmentation.
2. Mono gradually became unstable the longer it ran. This grew exponentially worse as you added threads.
Both of these issues can be circumvented by having multiple processes in a load-balanced configuration and simply restarting them every once and awhile. Heck, IIS does that with App Pool recycling anyway, and it doesn't have these issues.
The FogBugz team still uses Mono to host FogBugz on Unix systems, I believe by going the reboot-every-so-often route, so I assume they've found ways of living with the above two constraints.
How long ago did you experience those issues? I still have some time to go until I launch whatever it is I decide to build. I hope the Mono team finds a solution for them eventually.
1. The GC was poor. There's actually a couple of pieces to this one: it's non-compacting, so your app gradually slows down; and (because it's Boehm) it has to guess at what's a pointer, and sadly just doesn't do a good job, so you gradually leak RAM through no fault of your own. The new GC, which I think is called SGen, is a precise collector, so I assume that it fixes the memory leaks, but it's still non-compacting, meaning you're probably going to want to restart the process every once and awhile to prevent serious heap fragmentation.
2. Mono gradually became unstable the longer it ran. This grew exponentially worse as you added threads.
Both of these issues can be circumvented by having multiple processes in a load-balanced configuration and simply restarting them every once and awhile. Heck, IIS does that with App Pool recycling anyway, and it doesn't have these issues.
The FogBugz team still uses Mono to host FogBugz on Unix systems, I believe by going the reboot-every-so-often route, so I assume they've found ways of living with the above two constraints.