Is it possible that having only 16MB of /tmp available could cause trouble for some software?
Yes, if some piece of software wants to write to /tmp and it or some other piece of software has already filled the partition. Generally this would indicate either poor configuration of the system, a legitimate limitation on available resources, or misbehavior on the part of some other piece of software -- in any case, the software looking to write is very unlikely to try and find a solution itself and will throw an error.
Some software will assume it can write large files to /tmp, which to be fair, is a fair assumption. This issue would fall under the "poor configuration" umbrella of mistakes.
The first question you should ask yourself is, "What benefits are there for me in using RAM for /tmp?" The most obvious potential benefit is that accessing RAM is much faster than accessing a disk. However, this apparently obvious potential benefit is unlikely to be all that beneficial in reality because:
The system caches frequently accessed files in RAM anyway. Reducing the amount of RAM available for this cache so that you can put /tmp there is a bit daft, since it means infrequently used files in /tmp will have supplanted frequently used files in the cache.
Applications are already free to stash things in RAM, which in general is easier than stashing them in a file, so if they put something into a tmp file, it is very unlikely to be something which would benefit from being in RAM. If you look at what's actually in your /tmp, it is probably mostly sockets and fifos or little bits of IPC data. Accessing them via a RAM based file system is sort of conceptually tidier, but I doubt it makes any real difference.
That being the case, why would /tmp be implemented in RAM?
It simplifies the implementation of a preferred property of /tmp, namely that it is erased at shutdown.
It may slightly reduce wear and tear on the hardware. This is much more significant in contexts that only have cheap, limited lifetime flash for storage, or no writable storage at all (e.g., embedded systems).
Presuming /tmp isn't being abused, using RAM exploits the usually enormous memory capacity of modern hardware -- i.e., this stuff might as well be in RAM, presuming it's the kind of stuff it's supposed to be.
16 MB could be enough, but it still is not that much if some process goes haywire -- and /tmp must be writable by anyone. However, if some process goes haywire writing stuff to /tmp, will it be better if it eventually fills a harddrive or more quickly waves a red flag because it exhausted a RAM partition?
If you have confidence in the software you are using, the latter makes more sense, so you could go for the RAM partition. You should examine a bit your actual /tmp usage first in case anything unusual is going on (e.g. du -h /tmp). You could come up with a "normal threshold" and check that with a cron job to alert someone and/or do some emergency cleaning when it is exceeded.
Unfortunately, some apps may occasionally dump stuff in /tmp that doesn't get removed if they fail suddenly, and on a server -- which doesn't shut down often -- that could get left there indefinitely. This could happen very innocuously, I think, e.g., when someone logs in and makes use of something, then the connection is arbitrarily closed or abandoned.
So the non-RAM /tmp is safer. Abuse could go unnoticed for longer, but only because it is not as significant as it would be with RAM. Furthermore, if something really does cause a problem, there will be a smoking gun left on disk indicating the source of the problem.
tmpfs? It can even use swap. But if the VPS is tight on memory, harddisk may still be the best option regardless. – frostschutz Sep 30 '13 at 22:17