Bug 1635980 - Low Random write IOPS in VM workloads
Summary: Low Random write IOPS in VM workloads
Alias: None
Product: GlusterFS
Classification: Community
Component: replicate
Version: 4.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: bugs@gluster.org
QA Contact:
: 1635976 (view as bug list)
Depends On: 1630368 1635972
Blocks: 1630688 1635976
TreeView+ depends on / blocked
Reported: 2018-10-04 07:22 UTC by Pranith Kumar K
Modified: 2018-11-29 15:25 UTC (History)
20 users (show)

Fixed In Version: glusterfs-4.1.6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1635972
Last Closed: 2018-11-29 15:25:05 UTC
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:

Attachments (Terms of Use)

Comment 1 Pranith Kumar K 2018-10-04 07:23:32 UTC
Description of problem:
To get the baseline Random write IOPS of SSD gluster volume, that is added as a storage domain in RHHI so as to provide block storage to VM provisioned, is mounted on of the hosts and a fio random write run is executed over it. Later, the same volume was added as a storage domain and added as a block device to the Virtual Machine(VM) running on top of RHHI and the same fio random write test is executed within the VM. Following are the results:

1. Baseline Random Write IOPS: 6456
2. Virtual Machine Random Write IOPS: 602

Comment 2 Worker Ant 2018-10-04 07:32:27 UTC
REVIEW: https://review.gluster.org/21340 (cluster/afr: Make data eager-lock decision based on number of locks) posted (#1) for review on release-4.1 by Pranith Kumar Karampuri

Comment 3 Worker Ant 2018-10-05 14:39:44 UTC
COMMIT: https://review.gluster.org/21340 committed in release-4.1 by "Shyamsundar Ranganathan" <srangana@redhat.com> with a commit message- cluster/afr: Make data eager-lock decision based on number of locks

For both Virt and block workloads the file is opened multiple times
leading to dynamically setting eager-lock to off for the workload.
Instead of depending on the number-of-open-fds, if we change the
logic to depend on number of inodelks, then it will give better
performance than the earlier logic. When there is an eager-lock
and number of inodelks is more than 1 we know that there is a
conflicting lock, so depend on that information to decide whether
to keep the current transaction go through delayed-post-op or not.

Locks xlator doesn't have implementation to query number of locks in
fxattrop in releases older than 3.10 so to keep things backward
compatible in 3.12, data transactions will use new logic where as
fxattrop transactions will use old logic. I am planning to send one
more patch which makes metadata domain locks also depend on

Profile info for a dd of 500MB to a file with another fd opened
on the file using exec 250>filename

Without this patch:
 0.14      67.41 us      16.72 us    3870.82 us  892 FINODELK
 0.59     279.87 us      95.71 us    2085.89 us  898 FXATTROP
 3.46     366.43 us      81.75 us    6952.79 us 4000 WRITE
95.79  148733.99 us   50568.12 us  919127.86 us  273 FSYNC

With this patch:
 0.00      51.01 us      38.07 us      80.16 us    4 FINODELK
 0.00     235.43 us     235.43 us     235.43 us    1 TRUNCATE
 0.00     125.07 us      56.80 us     193.33 us    2 GETXATTR
 0.00     135.86 us      62.13 us     209.59 us    2  INODELK
 0.00     197.88 us     155.39 us     253.90 us    4 FXATTROP
 0.00     450.59 us     394.28 us     506.89 us    2  XATTROP
 0.00      56.96 us      19.06 us     406.59 us   23    FLUSH
37.81  273648.93 us      48.43 us 6017657.05 us   44   LOOKUP
62.18    4951.86 us      93.80 us 1143154.75 us 3999    WRITE

postgresql benchmark performance changed from ~1130 TPS to ~2300TPS
randio fio job inside Ovirt based VM went from ~600IOPs to ~2000IOPS

fixes bz#1635980
Change-Id: If7f7388d2f08cf7f17ca517a4ea222560661dc36
Signed-off-by: Pranith Kumar K <pkarampu@redhat.com>

Comment 4 Pranith Kumar K 2018-10-22 14:05:34 UTC
*** Bug 1635976 has been marked as a duplicate of this bug. ***

Comment 5 Shyamsundar 2018-11-29 15:25:05 UTC
This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-4.1.6, please open a new bug report.

glusterfs-4.1.6 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] https://lists.gluster.org/pipermail/announce/2018-November/000116.html
[2] https://www.gluster.org/pipermail/gluster-users/

Note You need to log in before you can comment on or make changes to this bug.