Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DAOS-16645 cart: Bump file descriptor limit #15224

Merged
merged 29 commits into from
Oct 21, 2024
Merged

Conversation

jolivier23
Copy link
Contributor

With tcp provider, using many sockets can cause significant file descriptor usage. Bump the soft limit, if possible and warn if it appears insufficient.

Required-githooks: true

Before requesting gatekeeper:

  • Two review approvals and any prior change requests have been resolved.
  • Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
  • Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
  • Commit messages follows the guidelines outlined here.
  • Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

  • You are the appropriate gatekeeper to be landing the patch.
  • The PR has 2 reviews by people familiar with the code, including appropriate owners.
  • Githooks were used. If not, request that user install them and check copyright dates.
  • Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
  • All builds have passed. Check non-required builds for any new compiler warnings.
  • Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
  • If applicable, the PR has addressed any potential version compatibility issues.
  • Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
  • Extra checks if forced landing is requested
    • Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
    • No new NLT or valgrind warnings. Check the classic view.
    • Quick-build or Quick-functional is not used.
  • Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

With tcp provider, using many sockets can cause significant
file descriptor usage.  Bump the soft limit, if possible
and warn if it appears insufficient.

Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
@jolivier23 jolivier23 requested review from a team as code owners September 30, 2024 19:49
Copy link

github-actions bot commented Sep 30, 2024

Ticket title is 'Automatically bump soft file descriptor limit for tcp provider'
Status is 'In Review'
Labels: 'google-cloud-daos'
https://daosio.atlassian.net/browse/DAOS-16645

Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>

if (rlim.rlim_cur < MIN_TCP_FD) {
if (rlim.rlim_max < MIN_TCP_FD) {
D_ERROR("File descriptor soft limit should be at least %d\n",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since you are checking rlim_max, shoudlnt error read 'hard limit' instead of soft here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

DS_ERROR(errno,
"setrlimit() failed. Unable to bump file descriptor"
" limit to suitable value (>= %d)",
MIN_TCP_FD);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not print rlim_max instead to know what value exactly it failed on?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
DS_ERROR(errno,
"setrlimit() failed. Unable to bump file descriptor"
" limit to value >= %d, limit is %lu",
MIN_TCP_FD, rlim.rlim_max);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

goto next; missing here? ele on error you will print d_info below:)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, good catch. I added the print later.

@mchaarawi
Copy link
Contributor

I thought we had some documentation that recommends setting the nopen files to 1048576 somewhere.

@jolivier23
Copy link
Contributor Author

I thought we had some documentation that recommends setting the nopen files to 1048576 somewhere.

you might be right and I can change it to a minimum of 1048576 if we want that. I just think we should bump it automatically if we can regardless.

Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
@jolivier23
Copy link
Contributor Author

I thought we had some documentation that recommends setting the nopen files to 1048576 somewhere.

you might be right and I can change it to a minimum of 1048576 if we want that. I just think we should bump it automatically if we can regardless.

Looks like we don't or at least I can't find it anywhere.

@mchaarawi
Copy link
Contributor

I thought we had some documentation that recommends setting the nopen files to 1048576 somewhere.

you might be right and I can change it to a minimum of 1048576 if we want that. I just think we should bump it automatically if we can regardless.

Looks like we don't or at least I can't find it anywhere.

yea i couldn't find it either but i know it was a requirement for using tcp on boro for example

frostedcmos
frostedcmos previously approved these changes Sep 30, 2024
@jolivier23
Copy link
Contributor Author

I thought we had some documentation that recommends setting the nopen files to 1048576 somewhere.

you might be right and I can change it to a minimum of 1048576 if we want that. I just think we should bump it automatically if we can regardless.

Looks like we don't or at least I can't find it anywhere.

yea i couldn't find it either but i know it was a requirement for using tcp on boro for example

We've been using 131072 in our documentation for parallelstore. Should be sufficient for most cases as with our largest instance and dfuse with 8 eq would only use around 3500 fds for sockets. Anyway, I think it's a reasonable minimum and this patch will set it higher if allowed.

Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
@mchaarawi mchaarawi requested a review from soumagne October 1, 2024 13:57
@mchaarawi
Copy link
Contributor

I thought we had some documentation that recommends setting the nopen files to 1048576 somewhere.

you might be right and I can change it to a minimum of 1048576 if we want that. I just think we should bump it automatically if we can regardless.

Looks like we don't or at least I can't find it anywhere.

yea i couldn't find it either but i know it was a requirement for using tcp on boro for example

We've been using 131072 in our documentation for parallelstore. Should be sufficient for most cases as with our largest instance and dfuse with 8 eq would only use around 3500 fds for sockets. Anyway, I think it's a reasonable minimum and this patch will set it higher if allowed.

fine with me. ill defer my +1 to @soumagne

Copy link
Collaborator

@soumagne soumagne left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minus the comments that I had, the PR looks good to me overall.

@@ -492,10 +492,14 @@ check_grpid(crt_group_id_t grpid)
return rc;
}

#define MIN_TCP_FD 131072
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please prefix internal macros with CRT_

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

src/cart/crt_init.c Show resolved Hide resolved
/* Bump file descriptor limit if low and if possible */
rc = getrlimit(RLIMIT_NOFILE, &rlim);
if (rc != 0) {
DS_WARN(errno, "getrlimit() failed. Unable to check file descriptor limit");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this a warn ? to me it sounds like it should be an error with appropriate errno checking ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done. Looking at the man page, it doesn't look like it should ever fail in our case.

if (rlim.rlim_cur < MIN_TCP_FD) {
if (rlim.rlim_max < MIN_TCP_FD) {
D_ERROR("File descriptor hard limit should be at least %d\n",
MIN_TCP_FD);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would consider that as a warning, not as an error, if let's say someone wanted for any reason to have a lower limit...

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, this is a warning - in effect it's asking the admin to reconfigure the node but there's no error here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

src/cart/crt_init.c Outdated Show resolved Hide resolved
if (rlim.rlim_cur < MIN_TCP_FD) {
if (rlim.rlim_max < MIN_TCP_FD) {
D_ERROR("File descriptor hard limit should be at least %d\n",
MIN_TCP_FD);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, this is a warning - in effect it's asking the admin to reconfigure the node but there's no error here.

src/cart/crt_init.c Outdated Show resolved Hide resolved
Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
frostedcmos
frostedcmos previously approved these changes Oct 17, 2024
Comment on lines 1252 to 1256
# valgrind reduces the hard limit unless we bump the soft limit first
(soft, hard) = resource.getrlimit(resource.RLIMIT_NOFILE)
if soft < hard:
resource.setrlimit(resource.RLIMIT_NOFILE, (hard, hard))

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be better set after passing the command line at https://github.com/daos-stack/daos/blob/master/utils/node_local_test.py#L6530

Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
Allow-unstable-test: true

Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
Required-githooks: true

Signed-off-by: Jeff Olivier <[email protected]>
@jolivier23 jolivier23 merged commit e117a6c into master Oct 21, 2024
75 checks passed
@jolivier23 jolivier23 deleted the jvolivie/setrlimit branch October 21, 2024 17:15
jolivier23 added a commit that referenced this pull request Oct 22, 2024
With tcp provider, using many sockets can cause significant
file descriptor usage.  Bump the soft limit, if possible
and warn if it appears insufficient.
Valgrind sets hard limit to soft limit, so work around that in NLT.

Signed-off-by: Jeff Olivier <[email protected]>
jolivier23 added a commit that referenced this pull request Nov 8, 2024
With tcp provider, using many sockets can cause significant
file descriptor usage.  Bump the soft limit, if possible
and warn if it appears insufficient.
Valgrind sets hard limit to soft limit, so work around that in NLT.

Signed-off-by: Jeff Olivier <[email protected]>
jolivier23 added a commit that referenced this pull request Dec 19, 2024
With tcp provider, using many sockets can cause significant
file descriptor usage.  Bump the soft limit, if possible
and warn if it appears insufficient.
Valgrind sets hard limit to soft limit, so work around that in NLT.

Signed-off-by: Jeff Olivier <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

7 participants