-
-
Notifications
You must be signed in to change notification settings - Fork 200
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
Unexpected behavior with max_threads = 1 #208
Comments
@reczy wow, I think you've uncovered a big performance problem that I think should be a quick fix. The explanation: Every time a thread completes a job, it creates a new job thread ( good_job/lib/good_job/scheduler.rb Lines 160 to 167 in b950c61
That happens within the active job thread. Which means that the code within good_job/lib/good_job/scheduler.rb Line 144 in b950c61
I will change |
The fix for this is released in |
Happy to help - Thank you for being so responsive. Confirmed that it's working as expected with |
Hi @bensheldon,
With
max_threads = 1
, good_job appears to be behaving unexpectedly.Even with many pending jobs, good_job will perform 1 job, then wait the full polling period, then perform 1 job, and so on. Changing to
max_threads = 2
and restarting the server leads to the expected behavior of performing all the jobs in quick succession (without waiting the full polling period between each perform).GoodJob version "1.7.0"
Postgres version 12.5
If it's at all helpful, with the above procedure, good_job does actually successfully complete about 20-25% of the jobs by the time all 1000 jobs are enqueued (meaning, it completes them very quickly without waiting for the next poll), then starts the unexpected behavior I described above.
Let me know if I can provide any additional information to be helpful.
The text was updated successfully, but these errors were encountered: