1

NOTE: I'm aware of the question Persistent changes to /proc/sys/sunrpc/tcp_slot_table_entries and while this older question is quite similar, the selected and proposed answers do not work for us, nor do they speak specifically to Upstart.

We need a way to ensure that our tcp_slot_table_entries modifications both persist on reboot and are implemented prior to NFS Mounts being mounted.

We have a short base script that we use to test relative performance on the mount after mounting, when the OS Defaults (The Current Default is 2) are used, the average time is about 400% worse than after our custom defaults are applied.

So we make the changes, restart the system, run our tests (see horrible times) then unmount and mount the NFS, rerun the tests, and see improved times. This demonstrates that we are indeed persisting the changes on reboot, but that the changes are happening after the initial mount takes place.

In addition to attempting the answer in the related questions, we've attempted:

  • modifying the procp.conf upstart job to make the changes See Ref
  • adding a modprope.d conf script. See Ref

In all cases, this would re-apply the changes after reboot, but not prior to mounting the NFS. Finally, our management would very much prefer we implement a pure upstart solution to the challenge.

Admittedly I'm an upstart noob, so I've got an interim solution in place that adds our mount to fstab with the noauto directive, and then uses rc.local to mount it after everything is initialized.

What we are looking for is a pure upstart solution, that doesn't modify current/default upstart jobs (as they might be overwritten on upgrade). So then, that leaves us with three questions:

  1. Is it reasonably possible to implement a pure upstart job solution that modifies tcp_slot_table_entries prior to an fstab auto mount?
  2. Assuming it is, can you point us to some material/links (more specific than merely RTFM Upstart Documentation) that will assist us in sorting out the implementation details?
  3. Is there an even more elegant solution to the challenge that we have not considered?
Community
  • 1
bubba
  • 111
  • 2

1 Answers1

0

Did you ever get an answer to this anywhere?

I can't see why setting it in /etc/modprobe.d/sunrpc.conf wouldn't work. If it parses those options when the sunrpc module is loaded, which I thought was required to mount nfs volumes, then the setting should apply because it's required to be loaded before nfs volumes are mounted. Unless there is a bug in the OS you're using or some unusual behaviour coming from the filer..

zugolosian
  • 1