Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Not a Bug
-
10.6.12, 10.6.13
-
None
-
CentOS 7, kernel 3.10
Description
Repro procedure is the same as MDEV-30567. Additional details for that in the comments.
In short, this is the performance discrepancy we're seeing in 10.6.13 (10.6.12 performs similarly but slightly worse)-
# Default (O_DIRECT)
|
# * Q0: real: 14.21 min: 14.21 max: 14.21
|
|
|
# innodb-flush-method = fsync
|
# * Q0: real: 4.94 min: 4.94 max: 4.94
|
|
|
# innodb-flush-method = O_DSYNC
|
# * Q0: real: 4.92 min: 4.92 max: 4.92
|
|
|
# innodb-flush-method = littlesync
|
# * Q0: real: 4.91 min: 4.91 max: 4.91
|
|
|
# innodb-flush-method = nosync
|
# * Q0: real: 4.95 min: 4.95 max: 4.95
|
|
|
# innodb-flush-method = O_DIRECT
|
# * Q0: real: 14.21 min: 14.21 max: 14.21
|
|
|
# innodb-flush-method = O_DIRECT_NO_FSYNC
|
# * Q0: real: 12.81 min: 12.81 max: 12.81
|
The customer for whom we are concerned about this issue for is currently using 10.4 where innodb_flush_method=fsync is the default. For 10.6 though, this changes to O_DIRECT. For now, we're advising the customer to hard-specify innodb_flush_method=fsync for 10.6. However, we know that O_DIRECT was made default in 10.6 as it generally improves over fsync, so we'd like to know if the regression we're seeing here is due to a bug that, if fixed, would make O_DIRECT the all-around ideal it is intended to be.
Attachments
Issue Links
- duplicates
-
-
- Open
-
- is blocked by
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
- mentioned in
-
Page Loading...
-
-
-
-
-
-
-
-