This assumes you have analyzed a native_stderr.log in Garbage Collection and Memory Visualizer, and one of the tuning recommedations is:

"The mean heap unusable due to fragmentation is estimated at x%, which is high. You are using the x gc policy, which is already a reasonable choice. You may be able to reduce fragmentation levels by increasing -Xloratio to increase the room available for large objects or increasing the pinned free list size with the -Xp command line parameter."

Starting by loading at least a few native_stderr.logs into Garbage Collection and Memory Visualizer to determine is fragmentation is consistently an issue, or if this tuning recommendation is a fluke. When multiple native_stderr.log have the fragmentation tuning recommendation, if it's possible to reproduce the issue that is causing fragmentation, reproduce the issue, and then adjust the X Axis in Garbage Collection and Memory Visualizer to conicide with the time frame that the issue was reproduced. If nothing jumps out at you in the Garbage Collection and Memory Visualizer, you can instead check SystemOut.log and SystemErr.log.

You want the mean heap unusable due to fragmentation to be a low number.  I like to see it under 10%.  Setting the –Xk value should help this go down.  Setting the –Xp and –Xloratio can also help this as well, but you need to be careful with these.  The –Xk value is always a safe and good thing to set as the space is going to be used anyway and it helps to minimize heap fragmentation, which is usually our biggest problem. 

If you are going to set the -Xloratio, ensure the JVM has enough heap.

If allocation from the pinned list is high, you may want to increase or set the –Xp parameter to set aside some of the heap just for pinned objects.