HDDS-14874. Make Ratis append-entries.compose.enabled false by default.#9963
HDDS-14874. Make Ratis append-entries.compose.enabled false by default.#9963ss77892 wants to merge 2 commits intoapache:masterfrom
Conversation
adoroszlai
left a comment
adoroszlai
left a comment
There was a problem hiding this comment.
Thanks @ss77892 for the patch.
| ScmConfigKeys.OZONE_SCM_HA_RAFT_LOG_APPEND_ENTRIES_COMPOSE_ENABLED, | ||
| OMConfigKeys.OZONE_OM_RATIS_LOG_APPEND_ENTRIES_COMPOSE_ENABLED, |
There was a problem hiding this comment.
Not adding to ozone-default.xml implies that the properties are undocumented. But the corresponding datanode config is documented. I think we should make all 3 documented or undocumented consistently.
If you wish to not document them, then the constants can be moved to the place of usage (RatisUtil and OzoneManagerRatisServer) for simplicity, then the exclusion is unnecessary. In that case the datanode-specific config should also be moved to XceiverServerRatis from DatanodeRatisServerConfig.
| properties.setBoolean( | ||
| "raft.server.log.append-entries.compose.enabled", | ||
| ozoneConf.getBoolean( | ||
| ScmConfigKeys.OZONE_SCM_HA_RAFT_LOG_APPEND_ENTRIES_COMPOSE_ENABLED, | ||
| ScmConfigKeys. | ||
| OZONE_SCM_HA_RAFT_LOG_APPEND_ENTRIES_COMPOSE_ENABLED_DEFAULT)); |
There was a problem hiding this comment.
Ideally we should use the type-safe API (Log.setAppendEntriesComposeEnabled). I understand that this will be available only in Ratis 3.2.2 and later, but the same applies to the behavioral change triggered by this config. So I think we can wait with until then.
2 participants
What changes were proposed in this pull request?
HDDS-14874. Make Ratis append-entries.compose.enabled false by default.
Please describe your PR in detail:
RATIS-2235 has introduced performance degradation in Ozone. That was addressed in RATIS-2387, which made the previous logic optional. We should explicitly set append-entries.compose.enabled to false to restore the old behavior.
What is the link to the Apache JIRA
https://issues.apache.org/jira/browse/HDDS-14874
How was this patch tested?
UTs.
Performance comparison of large file writes on 3 container-based nodes:
40GB file upload.
Before patch:
Run 1: Upload: 189.79s ( 215.81 MB/s)
Run 2: Upload: 178.98s ( 228.84 MB/s)
Run 3: Upload: 173.18s ( 236.51 MB/s)
After patch:
Run 1: Upload: 121.48s ( 337.16 MB/s)
Run 2: Upload: 122.66s ( 333.93 MB/s)
Run 3: Upload: 106.20s ( 385.67 MB/s)