How to improve GlusterFS performance

Improving GlusterFS performance keeps file operations responsive and prevents small storage stalls from turning into application retries, lock contention, and cascading timeouts. Predictable latency and steady throughput are critical as volumes grow and client concurrency increases.

Performance is primarily shaped by volume layout (distribute, replicate, disperse), brick placement, and the translator stack that serves client IO through caching and queueing behaviors. Each brick is backed by a local filesystem path such as /srv/gluster/brick1, while client requests are coordinated across peers with network round-trips and background housekeeping that can amplify bottlenecks.

Tuning is workload-specific and can shift pressure between disk, network, and CPU, so baseline measurements and one-change-at-a-time testing reduce guesswork. Data movement operations (adding/removing bricks, rebalances, and heals) generate heavy background IO that can temporarily depress performance, so scheduling and verification are as important as the configuration changes themselves.

GlusterFS performance tuning checklist:

Confirm all GlusterFS peers are connected before troubleshooting performance symptoms.
```
$ sudo gluster peer status
Number of Peers: 1

Hostname: node2
Uuid: 6e9b2b3a-1b4e-46f3-9b33-2c3b2a3d7f25
State: Peer in Cluster (Connected)
```
Disconnected peers can trigger client retries and failover behavior that looks like intermittent slowness.

Review volume layout to confirm brick count and volume type match the intended performance and redundancy profile.

$ sudo gluster volume info volume1

Volume Name: volume1
Type: Distributed-Replicate
Volume ID: 9b9f2d4f-3c3a-4c3e-8c10-5b2f8b1f1e32
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: node1:/srv/gluster/brick1
Brick2: node2:/srv/gluster/brick1
Options Reconfigured:
nfs.disable: on
##### snipped #####

Review volume status to confirm bricks are online and responding.

$ sudo gluster volume status volume1
Status of volume: volume1
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick node1:/srv/gluster/brick1             49152     0          Y       1443
Brick node2:/srv/gluster/brick1             49153     0          Y       1398

Start volume profiling for a short sampling window to capture IO statistics.
```
$ sudo gluster volume profile volume1 start
Starting volume profile on volume volume1 has been successful
```
Profiling adds overhead on bricks and can distort latency under peak load, so keep sampling windows short and targeted.

Related: How to profile GlusterFS volume performance

Display profiling statistics after running a representative workload against the volume.

$ sudo gluster volume profile volume1 info
Brick: node1:/srv/gluster/brick1
----------------------------------------
Cumulative Stats:
Block Size: 512b+  Reads: 18432  Writes: 9102
Total Read: 9.0GB  Total Write: 4.4GB

Brick: node2:/srv/gluster/brick1
----------------------------------------
Cumulative Stats:
Block Size: 512b+  Reads: 18390  Writes: 9099
##### snipped #####

Look for skew between bricks, unexpectedly high write counts, or operation patterns that align with the workload bottleneck.

Stop volume profiling when sampling is complete.
```
$ sudo gluster volume profile volume1 stop
Stopping volume profile on volume volume1 has been successful
```
Leave profiling disabled during normal operations unless actively diagnosing performance.
Add bricks to increase capacity and parallelism as usage grows.

Adding bricks changes how files are distributed across the cluster, which can improve throughput by increasing the number of active spindles/SSDs and CPU paths.

Related: How to add a brick to a GlusterFS volume
Rebalance the volume after layout changes.

Rebalance can saturate disk and network IO, so schedule it during a maintenance window or low-traffic period to avoid user-visible latency spikes.

Related: How to rebalance a GlusterFS volume
Related: How to remove a brick from a GlusterFS volume

Review current volume options before making tuning changes.

$ sudo gluster volume get volume1 all
Option                                   Value
------                                   -----
cluster.lookup-unhashed                   on
diagnostics.latency-measurement           off
performance.quick-read                    on
performance.read-ahead                    on
performance.readdir-ahead                 on
performance.write-behind                  on
##### snipped #####

Apply a single tuning option change for the current workload.
```
$ sudo gluster volume set volume1 performance.readdir-ahead on
volume set: success
```
Apply one change at a time and record baseline throughput/latency before moving to the next option to avoid masking the true cause of improvements or regressions.

Related: How to set GlusterFS volume options
Confirm the updated option value from the volume configuration.
```
$ sudo gluster volume get volume1 performance.readdir-ahead
Option: performance.readdir-ahead
Value: on
```
Re-run the same benchmark or production-like workload used for the baseline and compare results against the profiling sample.

Re-check volume status to confirm all bricks remain online after tuning and layout operations.

$ sudo gluster volume status volume1
Status of volume: volume1
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick node1:/srv/gluster/brick1             49152     0          Y       1443
Brick node2:/srv/gluster/brick1             49153     0          Y       1398