We've seen a lot of problems with the newer behavior failing to react quick enough. It CAN jump up to 64K slot table entries, but it doesn't seem to happen quick enough. We usually recommending pinning all the slot table settings to 128
and leaving them there. That ensures that it's ready for the bursts of IO.
I'm sure someone out there needs > 128, but we haven't clearly identified such a workload yet.
From: Toasters <toasters-bounces@teaparty.net> On Behalf Of
Fenn, Michael
Sent: Tuesday, July 7, 2020 9:29 AM
To: Scott Eno <cse@hey.com>; tmac <tmacmd@gmail.com>; Parisi, Justin <Justin.Parisi@netapp.com>
Cc: Toasters <toasters@teaparty.net>
Subject: Re:
|
NetApp Security WARNING: This is an external email. Do not click links or open attachments unless
you recognize the sender and know the content is safe. |
On more recent kernels, these are now sysctl parameters. You can put the following in /etc/sysctl.conf (or a new .conf file in /etc/sysctl.d) and run sysctl -w (or reboot):
sunrpc.tcp_max_slot_table_entries = 128
sunrpc.tcp_slot_table_entries = 128
sunrpc.udp_slot_table_entries = 64
That being said, you might want to check your current settings. At least on CentOS 7, sunrpc.tcp_max_slot_table_entries defaults to 65536, which is greater than the NetApp tuning, and should be more than large enough to ensure good write
performance.
Side note, hard has been the default for a while now, and intr has been ignored for over a decade, so you can skip those (though they're not harmful to provide).
Thanks,
Michael
From: Scott Eno <cse@hey.com>
Date: Tuesday, July 7, 2020 at 8:46 AM
To: tmac <tmacmd@gmail.com>, "Parisi, Justin" <justin.parisi@netapp.com>
Cc: Toasters <toasters@teaparty.net>
Subject: Re: Re:
NetApp docs talk about these settings:
udp_slot_table_entries=64
tcp_slot_table_entries=128
tcp_max_slot_table_entries=128
as being for RHEL 6.3 and above. The system I'm helping a user with is Ubuntu 18.04.3. Do these settings still apply (noting there's currently no sunrpc.co, or sunrpc.conf, under modprobe.d).
"Parisi, Justin" <justin.parisi@netapp.com> wrote: