Skip to content

Remove autoscale force_scale methods#6085

Merged
auvipy merged 2 commits into
celery:masterfrom
nadflinn:remove_force_scale_from_autoscale
Jun 13, 2020
Merged

Remove autoscale force_scale methods#6085
auvipy merged 2 commits into
celery:masterfrom
nadflinn:remove_force_scale_from_autoscale

Conversation

@nadflinn

Copy link
Copy Markdown
Contributor

Note: Before submitting this pull request, please review our contributing
guidelines
.

Description

A semi-related follow up to #6069

I noticed that there are two methods: force_scale_up and force_scale_down which are used in the pool_grow and pool_shrink remote control commands but I don't think they really work and am proposing that they be removed.

As an example, if you have an autoscale range of 6,3 and you have 4 tasks being worked on (and thus 4 processes running) and you try to force_scale_up a process will be added for a short period of time until this check runs again, at which point the lack of tasks to sustain the 5 processes will bump the process count down to 4 processes and we are back where we started.

Same goes for scaling down. Only in this case when you try to scale down you get a Value Error here because there are 4 tasks running and thus can't shrink the pool.

It seems like force_scale_up and force_scale_down are in conflict with the basic purpose and functioning of autoscale. There shouldn't be any forcing up and forcing down when the purpose of autoscale is to vary the process count based on the workload. And given that the workload does indeed drive the process pool size, any attempts to force up or force down don't work anyways.

I'm interested in any thoughts on this as I may be missing something here.

In order to reproduce this behavior:

In tasks.py:

from celery import Celery
import time

app = Celery('tasks', broker='redis://localhost', include=['tasks'])

@app.task
def my_task(item_id):
    print("Processing item {}".format(item_id))
    time.sleep(10000)

def send_tasks():
    for i in range(4):
        my_task.apply_async((i,))

In one window run your worker:
celery worker -A tasks --autoscale=6,3 --loglevel=DEBUG

Then from another window, to run 4 long running tasks:
python3 -c"from tasks import send_tasks;send_tasks()"

Then to bump up a process run:
celery -A tasks control pool_grow 1

Within 30 seconds (or whatever you have set for AUTOSCALE_KEEPALIVE) the 5 processes will bump back down to 4.

Then to bump down run the following:
celery -A tasks control pool_shrink 1

and in the worker window you'll see:
Autoscaler won't scale down: all processes busy.

@nadflinn

nadflinn commented May 13, 2020

Copy link
Copy Markdown
Contributor Author

@auvipy another autoscale PR for your review whenever you have a chance. Thank you!

@auvipy auvipy added this to the 4.4.x milestone May 13, 2020

@auvipy auvipy left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

besides the unit test, it would be great if you could also add some integration tests in the suits. as this has not change much for long so extra integration and intensive unit tests would be very helpful for the long term. also I suggest you try the PR in stagging and share with your work-mates

Comment thread celery/worker/control.py
"""Grow pool by n processes/threads."""
if state.consumer.controller.autoscaler:
state.consumer.controller.autoscaler.force_scale_up(n)
return nok("pool_grow is not supported with autoscale. Adjust autoscale range instead.")

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

what does nok actually do?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

@nadflinn

Copy link
Copy Markdown
Contributor Author

I'll hold off for now on this and revisit.

@lgtm-com

lgtm-com Bot commented May 16, 2020

Copy link
Copy Markdown

This pull request introduces 1 alert and fixes 3 when merging 7641f04 into 3508e1f - view on LGTM.com

new alerts:

  • 1 for Module is imported with 'import' and 'import from'

fixed alerts:

  • 2 for Module is imported with 'import' and 'import from'
  • 1 for Non-exception in 'except' clause

@auvipy

auvipy commented May 17, 2020

Copy link
Copy Markdown
Member

I have told several people to check this. in the meantime, if you can fix the flake8 error

@nadflinn
nadflinn force-pushed the remove_force_scale_from_autoscale branch from 7641f04 to 79a38e4 Compare June 12, 2020 22:19
@lgtm-com

lgtm-com Bot commented Jun 12, 2020

Copy link
Copy Markdown

This pull request introduces 5 alerts and fixes 2 when merging 79a38e4 into bf6139b - view on LGTM.com

new alerts:

  • 4 for Module is imported with 'import' and 'import from'
  • 1 for Non-exception in 'except' clause

fixed alerts:

  • 1 for Non-exception in 'except' clause
  • 1 for Module is imported with 'import' and 'import from'

@auvipy

auvipy commented Jun 13, 2020

Copy link
Copy Markdown
Member

can you check the py2.7 unit test failure

@auvipy auvipy closed this Jun 13, 2020
@auvipy auvipy reopened this Jun 13, 2020
@nadflinn

Copy link
Copy Markdown
Contributor Author

Im not able to reproduce locally. I'll try again this weekend.

@auvipy

auvipy commented Jun 13, 2020

Copy link
Copy Markdown
Member

its passing