Description of problem: When installing mongodb on a fixed size partition, it raises the need of having 3.4G reserved on /var space. This causes the base image to grow, and after some deployment it shows not being used. It is required for mongo journaling, and it can be avoided using the --small-files flag on mongo. Actual results: Mongo fails to deploy when /var space is lower than 3.4G claiming this space for journaling. Expected results: No hard disk requirement shall be needed for that, using the --small-files flag Additional info: We'd like to add this config to TripleO, but we are unsure of the pros/cons of it. We need advice on that, understand the advantages of not having --small-files, and the possible problems if we enable it.
I am no mongo expert, so take this with a pinch of salt. The option we talk about seems to be described here: https://docs.mongodb.com/manual/reference/configuration-options/#storage.mmapv1.smallFiles """ When true, MongoDB uses a smaller default file size. The storage.mmapv1.smallFiles option reduces the initial size for data files and limits the maximum size to 512 megabytes. storage.mmapv1.smallFiles also reduces the size of each journal file from 1 gigabyte to 128 megabytes. Use storage.mmapv1.smallFiles if you have a large number of databases that each holds a small quantity of data. The storage.mmapv1.smallFiles option can lead the mongod instance to create a large number of files, which can affect performance for larger databases. The storage.mmapv1.smallFiles setting is available only for mongod. """ So it seems to make sense only if we use many small databases as opposed to a few larger ones. Since we only have a very few dbs: tripleo:PRIMARY> show databases admin (empty) ceilometer 0.078GB local 48.055GB The tradeoffs for this options seem to be not in favour of performance here
So we better allocate enough disk space for the large journal when building the image?
That would be my take yes. Although I'd like we take a bit of higher-level approach on this and first do an estimation of how much data we need in /var in general. I mean we also store galera data there when galera and mongo exist on the same role, so a small /var would affect an environment quite a bit, no? Can we maybe take a step back and outline the reasons for your efforts here just to clarify the context a bit more?
That's the blueprint i'm working on , and that explains the needs for different volumes: https://blueprints.launchpad.net/tripleo/+spec/build-whole-disk-images