Bug 1489513 - read-ahead underperforms expectations
Summary: read-ahead underperforms expectations
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: GlusterFS
Classification: Community
Component: read-ahead
Version: mainline
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Csaba Henk
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-07 15:10 UTC by Csaba Henk
Modified: 2019-06-20 05:17 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-20 05:17:10 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Csaba Henk 2017-09-07 15:10:56 UTC
The following test case -- originally used to verify the fix of bug 1393419 (read-ahead not working if open-behind is turned on) -- shows that using read-ahead we get
worse performance than without it, in a scenario (sequential reading of a large file) that is typically expected to be benefited by read-ahead.

# Test setup

Reading a 2Gb sparse file. For each setup (ie. with or without
patch https://review.gluster.org/15811) and setting (of referred vol options)
we did alltogether 200 iteations, on 2 VM-s (100 + 100, ie. one VM with the
patch, one without, and switching after first 100 which has the patched setup).

read-ahead-page-count open-behind without patch (MiB/s) with patch (MiB/s)
1                     on          128.08                98.56
4                     on          128.98                88.71
16                    on          127.64                81.55
1                     off         108.55                108.52
4                     off         98.67                 99.93
16                    off         94.03                 94.99

# Results with read-ahead off

Note that the patch changes xlator order even in this case.

  • xlator order without patch:
     1. debug/io-stats
     2. performance/io-threads
     3. performance/md-cache
     4. performance/open-behind
     5. performance/quick-read
     6. performance/io-cache
     7. performance/readdir-ahead
     8. performance/write-behind
     9. cluster/distribute
    10. protocol/client
  • xlator order with patch:
     1. debug/io-stats
     2. performance/io-threads
     3. performance/md-cache
     4. performance/quick-read
     5. performance/io-cache
     6. performance/readdir-ahead
     7. performance/open-behind
     8. performance/write-behind
     9. cluster/distribute
    10. protocol/client

However, the above order change does not seem to make a difference.

open-behind without patch (MiB/s) with patch (MiB/s)
on          132.87                133.51
off         139.70                139.77

# Conclusion

Performance ordering of settings (approximate MiB/s):

  • no o/b & no r/a: 139
  • o/b only: 133
  • o/b only (r/a formally on but effectively disabled by o/b): 128
  • r/a only: 108
  • o/b & r/a (both working due to patch): 98

Comment 1 Amar Tumballi 2019-06-20 05:17:10 UTC
read-ahead is proven to not perform as good as kernel read-ahead and there is a bug to disable it by default. (ref: bz1676479)


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