Making a bundled Redis instance reachable via TCP

Use the following settings if you want to make one of the Redis instances
managed by omnibus-gitlab reachable via TCP.

redis['port']=6379redis['bind']='127.0.0.1'

Setting up a Redis-only server

If you'd like to setup a seperate Redis server (e.g. in the case of scaling
issues) for use with GitLab you can do so using GitLab Omnibus.

Note: Redis does not require authentication by default. See
Redis Security documentation for more
information. We recommend using a combination of a Redis password and tight
firewall rules to secure your Redis service.

Download/install GitLab Omnibus using steps 1 and 2 from
GitLab downloads. Do not complete other
steps on the download page.

Create/edit /etc/gitlab/gitlab.rb and use the following configuration.
Be sure to change the external_url to match your eventual GitLab front-end
URL:

Note: The redis_master_role['enable'] option is only available as of
GitLab 8.14, see gitlab_rails.rb
to understand which services are automatically disabled via that option.

Run sudo gitlab-ctl reconfigure to install and configure Redis.

Increasing the number of Redis connections beyond the default

By default Redis will only accept 10,000 client connections. If you need
more that 10,000 connections set the 'maxclients' attribute to suite your needs.
Be advised that adjusting the maxclients attribute means that you will also need
to take into account your systems settings for fs.file-max (i.e. "sysctl -w fs.file-max=20000")

redis['maxclients']=20000

Tuning the TCP stack for Redis

The following settings are to enable a more performant Redis server instance. 'tcp_timeout' is
a value set in seconds that the Redis server waits before terminating an IDLE TCP connection.
The 'tcp_keepalive' is a tunable setting in seconds to TCP ACKs to clients in absence of
communication.

redis['tcp_timeout']="60"redis['tcp_keepalive']="300"

Running with multiple Redis instances

GitLab includes support for running with separate redis instances for different persistence classes, currently: cache, queues, and shared_state.

Create a dedicated instance for each persistence class as per the instructions in [Setting up a Redis-only server][]

Set the appropriate variable in /etc/gitlab/gitlab.rb for each instance you are using:

Redis Sentinel

Setting the Redis Cache instance as an LRU

Using multiple Redis instances allows you to configure Redis as a Least
Recently Used cache. Note you should only
do this for the Redis cache class; the Redis queues and shared state cache
should never be configured as an LRU, since they contain data (e.g. Sidekiq
jobs) that is expected to be persistent.