Skip to content

Conversation

yarikoptic
Copy link
Contributor

In my case I kept finding celery running at 100% and doing nothing. py-spy pointed to the close_open_fds and then ulimit inside the container showed gory detail of

❯ docker run -it --rm --entrypoint bash dandiarchive/dandiarchive-api -c "ulimit -n"
1073741816

situation is not unique to me. See more at

I verified that with this fix my celery container gets unstuck and proceeds to report useful errors ;)

In my case I kept finding celery running at 100% and doing nothing.  py-spy
pointed to the close_open_fds and then ulimit inside the container showed gory
detail of

    ❯ docker run -it --rm --entrypoint bash dandiarchive/dandiarchive-api -c "ulimit -n"
    1073741816

situation is not unique to me. See more at

dandi/dandi-cli#1488
@yarikoptic
Copy link
Contributor Author

hm, why pre-commit.ci is even configured if there is no .pre-commit-config.yaml?

@auvipy auvipy self-requested a review March 5, 2025 06:29
Copy link
Member

@auvipy auvipy left a comment

Choose a reason for hiding this comment

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

lets ignore the pre commit. can you elaborate more on the change please? also should we also consider adding some tests to verify the proposed changes?

@yarikoptic
Copy link
Contributor Author

I would be happy to elaborate! ATM I can only reiterate what tried to describe in original description -- on some systems ulimit would return HUGE number for maximal number of open descriptiors, which would be infeasible to loop through. So, billiard should not try to loop through all the possible billion of them.

@auvipy
Copy link
Member

auvipy commented Mar 14, 2025

May be we can add some unit tests for the suggested changes as well

@yarikoptic
Copy link
Contributor Author

sorry -- too busy ATM, feel welcome to contribute some by directly pushing to my branch for this PR, I did

image

@auvipy auvipy requested a review from Copilot May 21, 2025 05:47
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

The PR adds logic to cap and warn about excessively high file descriptor limits returned by get_fdmax, preventing performance issues when iterating open descriptors.

  • Capture os.sysconf('SC_OPEN_MAX') into fdmax and handle errors uniformly
  • Introduce a threshold (100k) to cap fdmax to a sensible default (either the passed default or 10 000) and emit a warning
  • Import warnings and emit a deprecation-style warning instead of returning an oversized limit
Comments suppressed due to low confidence (1)

billiard/compat.py:118

  • Consider adding unit tests for the new high-value cap branch to verify that large fdmax values produce the expected warning and capped return value.
    if fdmax >= 1e5:

Comment on lines +118 to +124
if fdmax >= 1e5:
# limiting value is ad-hoc and already more than sensible
if default:
fdmax_limited = default
msg = "the default"
else:
fdmax_limited = 10000
Copy link

Copilot AI May 21, 2025

Choose a reason for hiding this comment

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

The magic numbers 1e5 and 10000 should be extracted to named constants for clarity and easier future tuning.

Suggested change
if fdmax >= 1e5:
# limiting value is ad-hoc and already more than sensible
if default:
fdmax_limited = default
msg = "the default"
else:
fdmax_limited = 10000
if fdmax >= FD_MAX_LIMIT_THRESHOLD:
# limiting value is ad-hoc and already more than sensible
if default:
fdmax_limited = default
msg = "the default"
else:
fdmax_limited = FD_MAX_DEFAULT_LIMIT

Copilot uses AI. Check for mistakes.

auvipy and others added 2 commits May 21, 2025 05:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants