/admin/jobs page fails with an SQL Statement Timeout
/admin/jobs page is failing with 500 (internally caused by SQL statement timeout) on large installations like GitLab.com. This is caused because we show pagination for all builds we have in database:
-# https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/views/projects/jobs/_table.html.haml#L25 = paginate_collection(builds)
With a larger number of entries in
ci_builds table (as it is at GitLab.com) such queries are failing with a timeout, e.g.:
ActiveRecord::StatementInvalid PG::QueryCanceled: ERROR: canceling statement due to statement timeout : SELECT COUNT(*) FROM "ci_builds" WHERE "ci_builds"."type" IN ('Ci::Build')
which for GitLab.com can be found at https://sentry.gitlab.net/gitlab/gitlabcom/issues/647799/ (internal only).
Steps to reproduce
Chose any GitLab installation with a significant number of jobs stored in
ci_builds table (e.g. GitLab.com), login with an admin account and open
/admin/jobs page. There is some chance, that you will see
500 error page instead of the list of Runners or at least it will take a lot of time to load.
What is the current bug behavior?
GitLab sometimes returns 500 page, caused by a SQL Statement Timeout.
What is the expected correct behavior?
GitLab renders list of ci jobs.
Relevant logs and/or screenshots
Output of checks
This bug happens on GitLab.com
Results of GitLab environment info
Results of GitLab application Check
One fix could be only showing last N(1000/10000/100000) ci jobs in the table. We currently show only "1000+" text in the filters, but not limit counter in pagination.