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

Autoscaler is too slow (or run too seldom) #658

Closed
lechbaczynski opened this issue Sep 3, 2019 · 9 comments
Closed

Autoscaler is too slow (or run too seldom) #658

lechbaczynski opened this issue Sep 3, 2019 · 9 comments

Comments

@lechbaczynski
Copy link

lechbaczynski commented Sep 3, 2019

  • Horizon Version: 3.3.2
  • Laravel Version: 5.8.34
  • PHP Version: 7.2.19
  • Redis Driver & Version: predis 1.1.1
  • Database Driver & Version: mysql

Description:

Supervisor with 6 queues and 1800 processes (3 other supervisors running too, but with not much workers and jobs).
Starts with 300 processes, then the numbers go down.

There is a lot of jobs in one queue, yet the number of workers rises very slowly. It may take over half an hour to an hour to rise. Although all other queues are empty.
(in the image below there were some jobs in other queues, but even if other queues are empty, the number of workers rises slowly - here it rose to 1300, but it took long time)

image

Steps To Reproduce:

Make a supervisor like

'supervisor-1' => [
                'connection' => 'redis',
                'queue' => [
                    'one', 'two', 'three',
                    'four', 'five', 'six'
                ],
                'balance' => 'auto',
                'processes' => 1800, // even multiply of number of queues
                'min_processes' => 2,
                'tries' => 5,
                'timeout' => 550,
                'memory' => 512,
            ],

The number of workers will decrease from 300.
Add 100.000 jobs in one queue, and make each job run for random(5,200) seconds.
The queue workers number will rise slowly.

@driesvints
Copy link
Member

Not sure what's going on here. Maybe @themsaid can help?

@lechbaczynski
Copy link
Author

Video with one queue, number of workers and tasks. Other queues were rather empty at that time (animated GIF)
workersrisingslowly

@lechbaczynski
Copy link
Author

lechbaczynski commented Sep 4, 2019

Another strange thing: 5 queues, 2000 processes, min_processes 50.

            'processes' => 2000, // even multiply of number of queues
            'min_processes' => 50,

3 queues basically idle, two have thousands of jobs.
The number of processes in the bigger queue grow, but in the smaller shrinks - although it is still not using those 2000 allowed processes, only about 800. Shouldn't the number of processes in the smaller queue rise too?

Images in chronological order

11 41

11 42

11 46

@SDekkers
Copy link
Contributor

SDekkers commented Sep 4, 2019

The function scale() in AutoScale.php is limited to 1 process increase or decrease per 3 seconds, perhaps for these amounts of processes it should be in increments of a bit more..

@tomswinkels
Copy link
Contributor

I have ask the same thing in #622

@LasseRafn
Copy link
Contributor

Percentage increase/decrease maybe an idea? Example: 5% If only 5 processes it would simply be rounded up to 1 (leading back to default) but if 1000 processes, it would work in intervals of 50.

@themsaid
Copy link
Member

themsaid commented Dec 6, 2019

Scaling happens every 3 seconds and each time it starts/ends 1 process, is that what you call slow? Not sure what expectation you have.

@taylorotwell
Copy link
Member

It's unclear whether there is anything actionable in this issue. It is basically "I don't like the way autoscaling works". If anyone has a better solution it can be PR'd at any time.

@trevorgehman
Copy link
Contributor

What about being able to set the scale amount and/or the time between checking whether to scale in the config?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants