4 ms·

I don't like to sound negative, but it's hard to ignore the obvious. This technique is absolutely pointless because MongoDB and tmpfs actually are doing the sam

I don't like to sound negative, but it's hard to ignore the obvious. This technique is absolutely pointless because MongoDB and tmpfs actually are doing the same thing, i.e. nothing. The kernel does all the work. Both of them are mmapped regions, only MongoDB maps to its own files, while tmpfs maps to the system swap. Basically you're wasting RAM and introducing yet another moving part. What happens then is: on each "write" MongoDB touches a page in RAM which maps to a block in tmpfs file which maps back to the same RAM page which maps to a block in a swap. Why? If you have enough RAM to hold your working set, just use MongoDB directly with async writes and you won't be blocked by disk I/O. You will get blocked by the global DB lock, but that's another story. EDIT: edited the sequence of mappings.

deleted 13y ago
[deleted]
bkanber 13y ago
From the article: > The reason is that Linux is smart and it does not duplicate the pages between tmpfs and its cache From you: > MongoDB touches a page in RAM which maps to a block in tmpfs These two statements sound contradictory to me.
- old-gregg 13y ago
  Not really: I said "maps", which means that it's the same page, there is no duplication. But the mere presence of tmpfs as yet another moving part adds overhead and memory consumption. The OP did mention the security angle, i.e. the database is never written to a disk, so perhaps there's some convenience there.
  - reeses 13y ago
    The security angle is a bit of a canard, though. Most compromises involve compromising running applications, not OS-level filesystem exploits. This would improve security and reduce the potential attack surface if this were used for ephemeral mongodb instances, but only in that it would prevent poor programming practices from lasting beyond a working session.
cpleppert 13y ago
tmpfs will use the swap area in low memory situations, it doesn't 'map' to it. I'm a little confused about how you are wasting RAM. tmpfs lives entirely in the page cache and mmaped files are always page cache resident as well so they always map to the same page cache. It is possible that file system overhead will be less as tmpfs is simpler but maybe you should simply change the mongodb source code to mmap the database anonymously without a file backing in the first place.

deleted 13y ago

[deleted]

bkanber 13y ago

From the article: > The reason is that Linux is smart and it does not duplicate the pages between tmpfs and its cache From you: > MongoDB touches a page in RAM which maps to a block in tmpfs These two statements sound contradictory to me.

old-gregg 13y ago
Not really: I said "maps", which means that it's the same page, there is no duplication. But the mere presence of tmpfs as yet another moving part adds overhead and memory consumption. The OP did mention the security angle, i.e. the database is never written to a disk, so perhaps there's some convenience there.
- reeses 13y ago
  The security angle is a bit of a canard, though. Most compromises involve compromising running applications, not OS-level filesystem exploits. This would improve security and reduce the potential attack surface if this were used for ephemeral mongodb instances, but only in that it would prevent poor programming practices from lasting beyond a working session.

cpleppert 13y ago

tmpfs will use the swap area in low memory situations, it doesn't 'map' to it. I'm a little confused about how you are wasting RAM. tmpfs lives entirely in the page cache and mmaped files are always page cache resident as well so they always map to the same page cache. It is possible that file system overhead will be less as tmpfs is simpler but maybe you should simply change the mongodb source code to mmap the database anonymously without a file backing in the first place.