Skip to content

GitLab Next

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 39,511
    • Issues 39,511
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 1,222
    • Merge requests 1,222
  • Requirements
    • Requirements
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.org
  • GitLabGitLab
  • Merge requests
  • !17253

Merged
Created Sep 19, 2019 by Yorick Peterse@yorickpeterseMaintainer5 of 5 tasks completed5/5 tasks

Disable scheduling of productivity analytics

  • Overview 4
  • Commits 1
  • Pipelines 1
  • Changes 1

What does this MR do?

This migration times out on both GitLab's staging and production environments, even when an index is added for the columns used. As we are nearing release day we have decided to turn this migration into a noop for the time being.

The background migration is not removed as some jobs may have been scheduled (especially in dev environments). Keeping this code allows those jobs to finish, and allows us to reschedule it in the future if needed.

The migration (even with the index present) timed out in deployment https://ops.gitlab.net/gitlab-com/gl-infra/deployer/-/jobs/640029:

    Caused by:
    PG::QueryCanceled: ERROR:  canceling statement due to statement timeout
    /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:78:in `block in each_batch'
    /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `step'
    /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `each_batch'
    /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:1020:in `queue_background_migration_jobs_by_range_at_intervals'
    /opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20190918104222_schedule_productivity_analytics_backfill.rb:25:in `up'
    /opt/gitlab/embedded/bin/bundle:23:in `load'
    /opt/gitlab/embedded/bin/bundle:23:in `<main>'
    Tasks: TOP => db:migrate
    (See full trace by running task with --trace)
  stderr_lines:
  - rake aborted!
  - 'StandardError: An error has occurred, all later migrations canceled:'
  - ''
  - 'PG::QueryCanceled: ERROR:  canceling statement due to statement timeout'
  - ': SELECT  "merge_request_metrics"."id" FROM "merge_request_metrics" WHERE (merged_at >= ''2019-06-19 12:29:36.376177'') AND "merge_request_metrics"."id" >= 153435 ORDER BY "merge_request_metrics"."id" ASC LIMIT 1 OFFSET 10000'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:78:in `block in each_batch'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `step'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `each_batch'
  - /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:1020:in `queue_background_migration_jobs_by_range_at_intervals'
  - /opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20190918104222_schedule_productivity_analytics_backfill.rb:25:in `up'
  - /opt/gitlab/embedded/bin/bundle:23:in `load'
  - /opt/gitlab/embedded/bin/bundle:23:in `<main>'
  - ''
  - 'Caused by:'
  - 'ActiveRecord::QueryCanceled: PG::QueryCanceled: ERROR:  canceling statement due to statement timeout'
  - ': SELECT  "merge_request_metrics"."id" FROM "merge_request_metrics" WHERE (merged_at >= ''2019-06-19 12:29:36.376177'') AND "merge_request_metrics"."id" >= 153435 ORDER BY "merge_request_metrics"."id" ASC LIMIT 1 OFFSET 10000'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:78:in `block in each_batch'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `step'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `each_batch'
  - /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:1020:in `queue_background_migration_jobs_by_range_at_intervals'
  - /opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20190918104222_schedule_productivity_analytics_backfill.rb:25:in `up'
  - /opt/gitlab/embedded/bin/bundle:23:in `load'
  - /opt/gitlab/embedded/bin/bundle:23:in `<main>'
  - ''
  - 'Caused by:'
  - 'PG::QueryCanceled: ERROR:  canceling statement due to statement timeout'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:78:in `block in each_batch'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `step'
  - /opt/gitlab/embedded/service/gitlab-rails/app/models/concerns/each_batch.rb:68:in `each_batch'
  - /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/database/migration_helpers.rb:1020:in `queue_background_migration_jobs_by_range_at_intervals'
  - /opt/gitlab/embedded/service/gitlab-rails/db/post_migrate/20190918104222_schedule_productivity_analytics_backfill.rb:25:in `up'
  - /opt/gitlab/embedded/bin/bundle:23:in `load'
  - /opt/gitlab/embedded/bin/bundle:23:in `<main>'
  - 'Tasks: TOP => db:migrate'
  - (See full trace by running task with --trace)
  stdout: |-

Per @pshutsin, the feature that wanted this data can work fine without it. Because of this we are only disabling the scheduling of the background migration, instead of also reverting the feature.

This means that for 12.4 or futures releases a better approach for scheduling should be implemented. Even once the index starts getting used by PostgreSQL (we're not sure why it did not immediately use it), the queries take around 4 seconds to run. Depending on how large the table is, this means the scheduling could take a very long time.

Related merge requests/issues:

  • !14772 (merged)
  • !15137 (merged)
  • !17054 (merged)
  • gitlab-com/gl-infra/delivery#485 (closed)

Screenshots

Does this MR meet the acceptance criteria?

Conformity

  • Code review guidelines
  • Merge request performance guidelines
  • Style guides
  • Database guides
  • Separation of EE specific content
Edited Sep 19, 2019 by Yorick Peterse
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: revert-productivity-analytics-migrations

Enable Gitpod?

To use Gitpod you must first enable the feature in the integrations section of your user preferences.

Cancel Enable Gitpod