Should I set a MaxMetaspaceSize?
Answer from @eckes comments:
i would set a maximum which is large enough to not trigger in normal situations. The reason I say this is, that a system might act very erratic and hard to control if native memory gets exhausted or wild swapping happens. Much worse than a OOM or Java freeze. For example using 2GB (epecting a system to have 2gb buffers free at minimum)
Just to air the opposite opinion, the case can be made to ALWAYS set the MaxMetaspaceSize. Grouping the world's entire set of applications into 10 (binary - think about it) groups allows a discussion of why. Remember though, setting the limit only controls when Garbage Collection (GC) of that space will occur.
Group 01: Applications with all Non-Dynamic Classes
This group puts you into the stabilized band referred to above. In this case, the size to set is fairly easy to determine (just as MaxPermSize was) and there won't be much, if any, GC anyway.
Group 10: Applications with Dynamic Classes
Given the proliferation of highly powerful third party libraries, isn't almost every application in this group anyway? Often you don't care if the library is Scala/Groovy/etc, it just does exactly what you want so it is used. What is the value of filling up Metaspace with the litter of dead (dynamic) classes? When GC does come, it will be expensive. I would rather limit the size, make GC more frequent (but less pause time for each), and more easily run multiple applications on the same hardware without having concerns about their individual metaspaces running into one another.
As I commented on the previous answer the reasons for setting a limit on those memory pools is different.
If your users previously increased the MaxPermSize above the default that probably was either to avoid Full GCs / concurrent mode failures with CMS or because their applications genuinely needed a lot of perm gen space.
Decreasing the the metaspace limit from its effectively infinite default would serve an entirely different purpose: Avoiding unbounded metaspace growth.
The thing is that that's just an upper limit. The actually committed, i.e. current metaspace size will be smaller. In fact, there is a setting called MaxMetaspaceFreeRatio (default 70%) which means that the actual metaspace size will never exceed 230% of its occupancy.
And for it to grow it first would have to fill up, forcing a garbage collection (metaspace full) in an attempt to free objects and only when it cannot meet its MinMetaspaceFreeRatio (default 40%) goal it would expand the current metaspace to no more than 230% of the occupancy after the GC cycle.
So in practice the actual metaspace size should stabilize within a band close relative to its actual need unless the application is continuously leaking classloaders/classes or generating an enormous amount of dynamic code.
TL;DR: There may be reasons to restrict metaspace size, but they likely are different to the original reasons for setting the perm gen sizes. Therefore the need should be re-evaluated.