Mongodb – Too many open connections with MongoDB 2.6 + PyMongo 2.7.2

Does the same data take more storage space in version 2.6?

As noted in the MongoDB 2.6 release notes, the default storage allocation strategy changed from using exact-fit allocation with padding factor to usePowerOfTwoSizes. The powerOfTwoSizes allocation may take up more initial space, but generally results in less storage fragmentation and better reuse of space from deleted documents.

One notable exception is if you are using GridFS and have data saved with older drivers. The original GridFS chunk size was 256KB (an exact power of 2) which resulted in rounding up to 512KB (the next power of 2). Drivers were updated to lower the GridFS chunk size to 255KB, but this is a common reason your database size to grow if you resync with the powerOf2 allocation (see SERVER-13331 in the MongoDB issue tracker).

Changing the allocation strategy

In MongoDB 2.6 you can change the allocation strategy on a collection level using the collMod command, or on a server level with the newCollectionsUsePowerOf2Sizes configuration parameter. If you change the allocation strategy for an existing collection, this will only affect new documents created or moved in storage after the change. You would have to resync, compact, or repair the database to rewrite all documents with new allocations.

If you are using GridFS and have older documents with the 256K chunk sizes, it would make sense to change the allocation strategy for any gridfs chunks collections to not use PowerOf2Sizes. Similarly, if your data use case for a collection happens to be insert-only (or does not grow in size via updates) then the exact fit allocation will be more efficient.

Otherwise, the powerOf2Sizes allocation is recommended.

WiredTiger storage engine supports compression in MongoDB 3.0+

If storage size on disk is a concern, you should also consider testing the new WiredTiger storage engine in MongoDB 3.0, which includes support for index & data compression. Upgrading to MongoDB 3.0 & WiredTiger will require you to use updated drivers & tools, and as with any major version upgrade you should review the upgrade procedures relevant for your deployment as well as any compatibility changes.

RAM, mainly. Every connection gets a stack allocated, at the size of 1MB. The more connections you have, the more RAM is needed for them and the less RAM is available for keeping indices or the working set of data in RAM.

So with your 19314 connections, roughly 19GB of RAM is used for connections. That's roughly a third of your available RAM – which is too much, from my point of view. What is acceptable has very much to do with your use cases, performance needs and whatnot. Finding out an acceptable RAM utilization is out of scope of an answer and can take many hours of analysis and optimization.