Optimize how RecordDataRepairDetailWorker fetches project
☀ Context
In Restore missing container repositories under ex... (#390842), we introduced a worker that checks for missing container repositories with tags between Rails and the Container Registry. The worker tries to obtain a lease on the project it will work on and we fetch a project that is not yet in the container_registry_data_repair_details
table.
scope :pending_data_repair_analysis, -> do
left_outer_joins(:container_registry_data_repair_detail)
.where(container_registry_data_repair_details: { project_id: nil })
end
In !125304 (merged), we revisited the worker and added a randomization on how the worker fetches the next project. We currently have a concurrency of 4
, so making sure that the workers don't pick up the same project (and fail since they cannot get a lock on it) is important.
When we added the randomization, there was also a discussion on how to better optimize the worker.
🙌 Given suggestions on how to optimize
-
Use of Slow Iteration (!125304 (comment 1459987925))
-
Use of Background Migration to create placeholder
container_registry_data_repair_details
records and a worker to process them (!125304 (comment 1462821980))
✍ Implementation Plan
As a first step in further optimizing the worker, we will go with the Slow Iteration approach (no. 1 in the suggestions above). More information can be found here: !125304 (comment 1459987925)
Reference: https://docs.gitlab.com/ee/development/database/iterating_tables_in_batches.html#slow-iteration