This is quite an involved question, but I will give a brief answer on each. You should try these out, then ask a more specific question (like give details about RAM availability and utilization, with working data set size to diagnose page faulting for example).
Un-expected shutdown resulting as corrupt collections
You don't list your full version, but make sure you are on a later version of 2.0 at least and preferably 2.2 (2.2.3 is in release candidate status as of writing this). There were multiple Windows related fixes later in the 2.0 branch and several of them dealt with making the Windows build less susceptible to hard crashes (which can lead to corruption).
MongoDB not releasing disk space for deleted objects (currently its around 28-GB and growing)
This has been covered in numerous other posts and discussions - see my answer here:
https://stackoverflow.com/questions/13390160/does-mongodb-reuse-deleted-space
Increased number of Page Faults
No control over data in RAM (unable to pre-load required data in RAM and remove after few minutes)
As mentioned above, page faulting and data fitting into RAM requires more details - how much data do you have, what is your working set size, do your indexes fit into memory etc. There are also numerous discussions on the mongodb-user Google group as well as Stack Overflow on this, and how to track this in MMS - a bit of searching for common approaches here is advised before you submit a new question. You should also note that page fault reporting in Windows can be tough to interpret thanks to the OS reporting "soft" page faults (already in memory but not owned/touched by a process) and "hard" page faults (actually paged from disk) in pretty much the same way.
A note about pre-loading, you can do this with the touch command in 2.2+, for indexes, data or both (see the linked page for options).
Frequent DB Errors like: Unable to read data from the transport connection...
Again, this will require logs, an idea of the relative load on the system etc. More detail definitely required - you could just be hitting a timeout or similar because you are overloading the DB. I would advise a separate question if these errors persist after you resolve other problems
Move MongoDB to Linux (provided that my .Net application using this DB will reside on Windows Server within same LAN)?
More people use MongoDB on Linux than Windows so it is more extensively tested and used by the community on that platform, but there is significant usage on Windows and large installations. Moving OS will not necessarily solve or automatically fix issues. If your data will not fit in RAM on Windows, it will likely not fit on Linux either for example, nor will it change how MongoDB reuses deleted space.
Setup a 2-servers replica set with Master on Windows and Slave on Linux ? OR
You should always run a replica set (minimum primary, slave, arbiter), regardless of the OS. It's just a good idea in general, but particularly if you are seeing some of the issues you describe. While in theory you can mix OS like you mention, I would recommend picking one or the other and just using that.
You have few options here.
- Run DB command 'Compact' on the collection - This will not reclaim disk space, but will perform defragmentation over the specific collection.
- Perform a repairDatabase - This reclaims disk space back to the OS. the repairDatabase runs over the entire DB (or shard) and not just one collection (I would read the documentation, as repaireDatabase both locks the DB it's repairing and requires at least x2 of disk space than your DB size)
Please keep in mind that MongoDB always seeks to allocate more data files.
If indeed as you mentioned, you're deleting a lot of data, Mongo will reuse this space but it might contain 'junk' blocks which makes mongo use less than it actually has allocated. this is why Mongo is allocating more and more data files.
You can read more about it here: Managing disk space in MongoDB
Hope this helps a bit.
Best Answer
This is a known issue recently discovered in the MongoDB 3.6.3 release when using WiredTiger on Windows: SERVER-33982: Unbounded growth of pre-allocated log files.
This issue will be corrected in the 3.6.4 production release, so upgrading to MongoDB 3.6.4 (or newer) when available should resolve the issue.
In the interim, possible workarounds are:
Disable WiredTiger preallocation in 3.6.3
In your MongoDB config file:
Or, via command-line parameter:
Downgrade to MongoDB 3.6.2
mongod
to free up the preallocated space