Hi Greg,
The most important thing is to pick an explicit memory allocation that is appropriate to the machine but as large as possible. On your machine, you could probably allocate 650 or 700 MB to Mango before the operating system starts waking up the oom-killer to take it back.
There were some memory leaks in the past, true, but there's nothing to do in preparation for the bugs that have already been fixed.
There are other things, but they are sometimes subtle and certainly numerous. For instance, the persistent's minimum overlap when synchronizing blocks of data setting can speed up synchronizations significantly (the receiver must be using NoSQL though) which will make the memory in use there available to other uses faster.
Or, scheduling a bunch of meta points on the same cron pattern with a statistics call ( .past(DAY) for instance) would be a bad idea faster when memory is less available. The same could be said for a bunch of reports scheduled for the same instant.
Usually for memory I find it's easier to unwind the problem than presage where it could go wrong. This way, if there is no problem, there is no unwinding necessary.
With some of the ways users can cause massive memory usage in short order by certain large requests (which should have seen improvement in 3.6.3, much larger REST requests should be possible with much smaller memory footprints, and 3.6.4 should improve this some more), an important variable is the access control.
