dbus_heartbeat_cb :DBUS :WARN :Health status is unhealthy. Not sending heartbeat
messages make me suspect that the box is low on available memory and is thrashing.
When this happens again please collect resident and virt size of the ganesha.nfsd process and the overall memory consumption on the machine.
NFSv4 runs over TCP, so jumbo frames should make no difference at all, unless one of the machines (or one of the switches between them) had a badly configured MTU. If all the MTUs were the same (1500 is default for non-jumbo ethernet), then turning on jumbo frames won't make a difference, since TCP streams across multiple frames when packets are sent that are larger than the MTU.
The most likely scenarios are:
1) one machine has a lower MTU than the other, and when (rare) packets are sent that are over that machines MTU, they are silently dropped. TCP will resend them over and over forever, and they will continue to be dropped.
2) A switch in the network has a lower MTU than the machines, and does not properly fragment large frames. In this case, it's the switch that drops the frames, and again, TCP will resend forever.
Configuring jumbo frames would fix this by causing them to go through the entire network and set all the MTUs to the new, large value.
What's the next step here?