Hyper-V上のvmで印刷していると、稀に印刷物に空白やエラーが生じて、原因不明だったのだが、
　Hyper-Vのレプリケーションを止めたら再発しにゃくにゃった。
　詳細不明だが、たぶんレプリケーション時にvmを止める瞬間があり、プリンタドライバによってはデータ送信が止まるか消えるかして印字結果が死ぬと思われる。
　その程度で不都合生じるプリンタも大概だし、レプリケーションごときでvm動作に介入するHyper-Vもどうにゃのかと。

　/etc/default/nfs-kernel-serverとかにある
　RPCNFSDCOUNTを変更しようと思ったのだが、reloadしても反映されにゃい。みてみたらexport -r的にゃことしかしてにゃい上に、force-reloadとreloadが同じだったりして意味不明。
　で、

echo 64 >  /proc/fs/nfsd/threads

　して一応変更出来たんだけど、この方法でいいのかどうか非常に不安。

　どうもvmおいてるlinuxのnfs鯖が遅くて、その割にiostatで見たdiskがあまりbusyじゃにゃいという状況。
　net帯域調べたりcache的にゃものを追加したりしてみたんだけど、そっちじゃにゃくてnfsdの設定だった。
　
　thread数がデフォルトの8では全然さばき切れてにゃくて、64とか128とかそのくらいまで上げにゃいとdiskがbusyににゃらにゃかった。分かってみれば至極当然すぎる原因。
　そんにゃにthread要ったっけ？と思ったが以前はsolarisだったので挙動が異にゃるのかも。esxからの要求がどうにゃってるのかわからにゃいが、各threadが受けられるqueueに上限があるとすると、搭載disk数に比してRPCNFSDCOUNTをN倍したほうがよいということににゃるがほんまかいにゃ。