Updated by bmbouter almost 5 years ago
h2. Symptoms No signs of `pulp.server.maintenance.monthly` in the logs for the last 30 days. If task is triggered manually, it works properly and orphaned applicability profiles got cleaned up. h2. Impact Having a lot of orphaned applicability profiles triggers a lot of no-op applicability tasks, it can slow down the whole system if there are too many of those tasks. E.g. A repo with many bound consumers (30K unique profiles) will trigger 3K tasks. h2. Root Cause Pulp users Celery's periodic tasks feature It would be useful to make the period for its dispatching. The monthly maintenance is dispatched every 30 days. Unfortunately Celery measues this as 30 days since the pulp_celerybeat process started. See "the celery docs":http://docs.celeryproject.org/en/v4.0.2/userguide/periodic-tasks.html#beat-entries This means that if you restart your pulp_celerybeat every now and then, you'll end up with a lot of orphaned applicability profiles. h2. Resolution The recommendation is to use cron to run a script monthly like: <pre> from pulp.server.maintenance.monthly import queue_monthly_maintenance queue_monthly_maintenance.apply_async() </pre> task configurable.