-
Notifications
You must be signed in to change notification settings - Fork 659
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
Scaling delayed or doesn't happen at all #667
Comments
I'm not sure myself. @themsaid maybe? |
A little update - today I tested it with a vanilla installation of Laravel 6.1 and Horizon 3.4. All fresh files, nothing from my work project that could potentially influence it in subtle ways. Same problem. I forgot to mention before that it's all running in Docker, specifically Laradock. @driesvints You labelled the issue as needs more info. What kind of information should I provide? |
@rafalglowacz it's just that I don't know if this is a bug or not. I needs to be investigated more before we label it as a bug. |
I've investigated the issue, here are my findings. The problem is in the } elseif ($timeToClearAll == 0 &&
$supervisor->options->autoScaling()) {
return [$queue => $supervisor->options->minProcesses];
} If return [$queue => ($size * $this->metrics->runtimeForQueue($queue))]; The time to clear the queue depends on the runtime metric for the queue, but the metric will be empty until the first job finishes. As a result A potential solutionThis could probably be fixed by sending information about queue sizes to } elseif ($timeToClearAll == 0 &&
$supervisor->options->autoScaling()) {
return [
$queue => $sizes[$queue] > 0
? $supervisor->options->maxProcesses
: $supervisor->options->minProcesses
];
} I'm not sure if scaling towards maximum could result in creating too many workers. It will get corrected as soon as at least one job finishes. What do you guys think? Here's a full AutoScaler.php needed to test this potential fix: |
We are seeing the same behaviour with following setup: If we have a queue with 0 minProcesses, that queue will never scale, it just stays like that forever. In some cases it indeed starts scaling, but only if we restart horizon and in 'bootup' (when several processes are initially spawned) the first job is processed - after that it works, but like Rafal mentioned, only when the first job completed scaling works when you initially have 0 processes. This is indeed quite problematic for us, as we would like to separate multiple responsibilities into different queues/supervisors (especially dedicated batch-supervisors) where 'standby' processes are a waste of resources, and immediate response to pending jobs is not a requirement in any case. |
@driesvints is it intended to stay labelled as 'needs more info' ? We're able to reproduce this every time (as described by rafal and myself), and as the option exists for having minProcesses to be set to 0 i would tend to declare this as a bug. |
@graemlourens unfortunately I don't have time to deep dive into this atm. If you really believe this is a bug then the best thing you can do atm is send in a PR to fix the broken behavior and let it be reviewed by Taylor. |
A fix is proposed in #718 |
@themsaid thank you very much for that PR. We tried out the changes and they work as intended. Hopefully this will get merged soon. I would still however have classified this as a bug, and not an enhancement. |
PR was merged. Thanks for reporting. |
Description:
When Horizon is freshly started and all workers have been scaled down then scaling only happens after the first job finishes (which might be a long time) or, if minProcesses is set to 0, it never happens, no jobs get processed. I thought I was doing something wrong but I asked a colleague to check it for me and he got the same results.
Steps To Reproduce:
myqueue
to scale down to the min number (for instancewatch 'ps faux | grep horizon'
)myqueue
- make it run for half a minute or so in order to see what happens nextmyqueue
The text was updated successfully, but these errors were encountered: