[Bugs] [Bug 1200457] gluster performance issue as data is added to volume. tar extraction of files goes from 1-minute on empty volume to 20-minutes on volume with 40TB.

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1200457



--- Comment #17 from Manoj Pillai <mpillai at redhat.com> ---
Created attachment 1190117
  --> https://bugzilla.redhat.com/attachment.cgi?id=1190117&action=edit
small-file performance over multiple iterations

Each iteration here is creating and writing the same no. of files, and
reporting the aggregate throughput for that iteration. So iteration 1 writes
128K files. Iteration 2 adds another 128K files on top of that and so on. sync
is performed between iterations. Ideally, the throughput reported in each
iteration should be the same.

1. Gluster-HDD is for a single-brick gluster volume on a hard disk, fuse
mounted on clients.
2. kNFS-HDD is the same brick filesystem in 1., but this time kernel NFS
exported and nfs mounted on the clients.
3. Gluster-NVMeSSD is a single-brick gluster volume, like in 1., but this time
created on an NVMe SSD (note that the throughput is much higher in this case,
and is shown by the secondary Y axis).

The Gluster-HDD line shows the severe performance degradation that has been
reported in this bz -- throughput in iteration 8 is less than 1/4th the
throughput in iteration 1.

The kNFS-HDD and Gluster-NVMeSSD do not show this degradation, though there is
a  slight drop in the case of kNFS.

To me these results suggest that:
(1) the performance degradation we are seeing in gluster is due to increased
seeks, likely due to fragmentation or sub-optimal allocation. The seek
hypothesis would explain why the degradation is not seen in the SSD case.

(2) The fragmentation or sub-optimal allocation is primarily due to the extra
metadata that gluster is maintaining. This would explain why it is not seen in
the kNFS case.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.