If you want to keep GitLab's search fast when dealing with huge amount of data, you should consider enabling Elasticsearch.

GitLab leverages the search capabilities of Elasticsearch and enables it when searching in:

GitLab application

Issues

Merge requests

Milestones

Notes

Projects

Repositories

Snippets

Wiki

Once the data is added to the database or repository and Elasticsearch is enabled in the admin area the search index will be updated automatically. Elasticsearch can be installed on the same machine as GitLab, or on a separate server.

Elasticsearch is not included in the Omnibus packages. You will have to install it yourself whether you are using the Omnibus package or installed GitLab from source. Providing detailed information on installing Elasticsearch is out of the scope of this document.

You can follow the steps as described in the official web site or use the packages that are available for your OS.

In order to enable Elasticsearch you need to have access to the server that GitLab is hosted on, and an administrator account on your GitLab instance. Go to Admin > Settings and find the "Elasticsearch" section.

The following Elasticsearch settings are available:

Parameter

Description

Elasticsearch indexing

Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in Add GitLab's data to the Elasticsearch index.

Search with Elasticsearch enabled

Enables/disables using Elasticsearch in search.

Host

The TCP/IP host to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., "host1, host2").

This enqueues a number of Sidekiq jobs to index your existing repositories. You can view the jobs in the admin panel (they are placed in the elastic_batch_project_indexer) queue), or you can query indexing status using a rake task:

By default, one job is created for every 300 projects. For large numbers of projects, you may wish to increase the batch size, by setting the BATCH environment variable. You may also wish to consider throttling the elastic_batch_project_indexer queue , as this step can be I/O-intensive.

You can also run the initial indexing synchronously - this is most useful if you have a small number of projects, or need finer-grained control over indexing than Sidekiq permits:

Sometimes your repository index process gitlab:elastic:index_repositories or gitlab:elastic:index_repositories_async can get interrupted. This may happen for many reasons, but it's always safe to run the indexing job again - it will skip those repositories that have already been indexed.

As the indexer stores the last commit SHA of every indexed repository in the database, you can run the indexer with the special parameter UPDATE_INDEX and it will check every project repository again to make sure that every commit in that repository is indexed, it can be useful in case if your index is outdated:

Index all repositories using the gitlab:elastic:index_repositories Rake task (see above). You'll probably want to do this in parallel.

Enable Elasticsearch indexing.

Run indexers for database, wikis, and repositories (with the UPDATE_INDEX=1 parameter). By running the repository indexer twice you will be sure that everything is indexed because some commits could be pushed while you performed the initial indexing. The repository indexer will skip repositories and commits that are already indexed, so it will be much shorter than the first run.

If you have this exception (just like in the case above but the actual message is different) please check if you have the correct Elasticsearch version and you met the other requirements. There is also an easy way to check it automatically with sudo gitlab-rake gitlab:check command.