Reduce startup time by skipping update mappings step when possible #145604
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gsoldevila
added
Team:Core
|
Pinging @elastic/kibana-core (Team:Core) |
rudolf
reviewed
Nov 17, 2022
packages/core/saved-objects/core-saved-objects-migration-server-internal/src/model/model.ts
Outdated
Show resolved
Hide resolved
gsoldevila
commented
Nov 21, 2022
| } else { | ||
| throwBadResponse(stateP, res as never); | ||
| } | ||
| } else if (stateP.controlState === 'CHECK_VERSION_INDEX_READY_ACTIONS') { |
There was a problem hiding this comment.
I created this "logic-only" step to avoid duplicating code in the model.ts.
rudolf
reviewed
Nov 24, 2022
There was a problem hiding this comment.
Looking good! We never relied on writing/reading _meta so we don't have coverage for it in src/core/server/integration_tests/saved_objects/migrations/actions/actions.test.ts
I think it'd be worth to update those tests to ensure that initAction reads the _meta and that updateTargetMappingsMeta writes the _meta.
| }; | ||
| } else { | ||
| throwBadResponse(stateP, res); | ||
| } | ||
| } else if (stateP.controlState === 'CHECK_TARGET_MAPPINGS') { | ||
| const res = resW as ResponseType<typeof stateP.controlState>; | ||
| if (Either.isLeft(res) || !res.right.match) { |
There was a problem hiding this comment.
a left response would mean something really unexpected happened like ES returning an error that we didn't know about before. I'm not sure we should just ignore that and apply new mappings in this case. In general we would call throwBadResponse for such a left.
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Public APIs missing exports
Unknown metric groupsAPI count
ESLint disabled in files
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
rudolf
approved these changes
Nov 28, 2022
💔 All backports failed
Manual backportTo create the backport manually run: Questions ?Please refer to the Backport tool documentation |
💚 All backports created successfully
Note: Successful backport PRs will be merged automatically after passing CI. Questions ?Please refer to the Backport tool documentation |
gsoldevila
added a commit
to gsoldevila/kibana
that referenced
this pull request
Nov 29, 2022
…lastic#145604) The goal of this PR is to reduce the startup times of Kibana server by improving the migration logic. Fixes elastic#145743 Related elastic#144035) The migration logic is run systematically at startup, whether the customers are upgrading or not. Historically, these steps have been very quick, but we recently found out about some customers that have more than **one million** Saved Objects stored, making the overall startup process slow, even when there are no migrations to perform. This PR specifically targets the case where there are no migrations to perform, aka a Kibana node is started against an ES cluster that is already up to date wrt stack version and list of plugins. In this scenario, we aim at skipping the `UPDATE_TARGET_MAPPINGS` step of the migration logic, which internally runs the `updateAndPickupMappings` method, which turns out to be expensive if the system indices contain lots of SO. I locally tested the following scenarios too: - **Fresh install.** The step is not even run, as the `.kibana` index did not exist ✅ - **Stack version + list of plugins up to date.** Simply restarting Kibana after the fresh install. The step is run and leads to `DONE`, as the md5 hashes match those stored in `.kibana._mapping._meta` ✅ - **Faking re-enabling an old plugin.** I manually removed one of the MD5 hashes from the stored .kibana._mapping._meta through `curl`, and then restarted Kibana. The step is run and leads to `UPDATE_TARGET_MAPPINGS` as it used to before the PR ✅ - **Faking updating a plugin.** Same as the previous one, but altering an existing md5 stored in the metas. ✅ And that is the curl command used to tamper with the stored _meta: ```bash curl -X PUT "kibana:changeme@localhost:9200/.kibana/_mapping?pretty" -H 'Content-Type: application/json' -d' { "_meta": { "migrationMappingPropertyHashes": { "references": "7997cf5a56cc02bdc9c93361bde732b0", } } } ' ``` (cherry picked from commit b1e18a0) # Conflicts: # packages/core/saved-objects/core-saved-objects-migration-server-internal/src/actions/index.ts
gsoldevila
added a commit
that referenced
this pull request
Nov 30, 2022
…ble (#145604) (#146637) # Backport This will backport the following commits from `main` to `8.6`: - [Reduce startup time by skipping update mappings step when possible (#145604)](#145604) <!--- Backport version: 8.9.7 --> ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport) <!--BACKPORT [{"author":{"name":"Gerard Soldevila","email":"gerard.soldevila@elastic.co"},"sourceCommit":{"committedDate":"2022-11-28T14:34:58Z","message":"Reduce startup time by skipping update mappings step when possible (#145604)\n\nThe goal of this PR is to reduce the startup times of Kibana server by\r\nimproving the migration logic.\r\n\r\nFixes https://github.com/elastic/kibana/issues/145743\r\nRelated https://github.com/elastic/kibana/issues/144035)\r\n\r\nThe migration logic is run systematically at startup, whether the\r\ncustomers are upgrading or not.\r\nHistorically, these steps have been very quick, but we recently found\r\nout about some customers that have more than **one million** Saved\r\nObjects stored, making the overall startup process slow, even when there\r\nare no migrations to perform.\r\n\r\nThis PR specifically targets the case where there are no migrations to\r\nperform, aka a Kibana node is started against an ES cluster that is\r\nalready up to date wrt stack version and list of plugins.\r\n\r\nIn this scenario, we aim at skipping the `UPDATE_TARGET_MAPPINGS` step\r\nof the migration logic, which internally runs the\r\n`updateAndPickupMappings` method, which turns out to be expensive if the\r\nsystem indices contain lots of SO.\r\n\r\n\r\nI locally tested the following scenarios too:\r\n\r\n- **Fresh install.** The step is not even run, as the `.kibana` index\r\ndid not exist ✅\r\n- **Stack version + list of plugins up to date.** Simply restarting\r\nKibana after the fresh install. The step is run and leads to `DONE`, as\r\nthe md5 hashes match those stored in `.kibana._mapping._meta` ✅\r\n- **Faking re-enabling an old plugin.** I manually removed one of the\r\nMD5 hashes from the stored .kibana._mapping._meta through `curl`, and\r\nthen restarted Kibana. The step is run and leads to\r\n`UPDATE_TARGET_MAPPINGS` as it used to before the PR ✅\r\n- **Faking updating a plugin.** Same as the previous one, but altering\r\nan existing md5 stored in the metas. ✅\r\n\r\nAnd that is the curl command used to tamper with the stored _meta:\r\n```bash\r\ncurl -X PUT \"kibana:changeme@localhost:9200/.kibana/_mapping?pretty\" -H 'Content-Type: application/json' -d'\r\n{\r\n \"_meta\": {\r\n \"migrationMappingPropertyHashes\": {\r\n \"references\": \"7997cf5a56cc02bdc9c93361bde732b0\",\r\n }\r\n }\r\n}\r\n'\r\n```","sha":"b1e18a0414ed99456706119d15173b687c6e7366","branchLabelMapping":{"^v8.7.0$":"main","^v(\\d+).(\\d+).\\d+$":"$1.$2"}},"sourcePullRequest":{"labels":["Team:Core","enhancement","release_note:skip","Feature:Migrations","backport:prev-minor","v8.7.0"],"number":145604,"url":"https://github.com/elastic/kibana/pull/145604","mergeCommit":{"message":"Reduce startup time by skipping update mappings step when possible (#145604)\n\nThe goal of this PR is to reduce the startup times of Kibana server by\r\nimproving the migration logic.\r\n\r\nFixes https://github.com/elastic/kibana/issues/145743\r\nRelated https://github.com/elastic/kibana/issues/144035)\r\n\r\nThe migration logic is run systematically at startup, whether the\r\ncustomers are upgrading or not.\r\nHistorically, these steps have been very quick, but we recently found\r\nout about some customers that have more than **one million** Saved\r\nObjects stored, making the overall startup process slow, even when there\r\nare no migrations to perform.\r\n\r\nThis PR specifically targets the case where there are no migrations to\r\nperform, aka a Kibana node is started against an ES cluster that is\r\nalready up to date wrt stack version and list of plugins.\r\n\r\nIn this scenario, we aim at skipping the `UPDATE_TARGET_MAPPINGS` step\r\nof the migration logic, which internally runs the\r\n`updateAndPickupMappings` method, which turns out to be expensive if the\r\nsystem indices contain lots of SO.\r\n\r\n\r\nI locally tested the following scenarios too:\r\n\r\n- **Fresh install.** The step is not even run, as the `.kibana` index\r\ndid not exist ✅\r\n- **Stack version + list of plugins up to date.** Simply restarting\r\nKibana after the fresh install. The step is run and leads to `DONE`, as\r\nthe md5 hashes match those stored in `.kibana._mapping._meta` ✅\r\n- **Faking re-enabling an old plugin.** I manually removed one of the\r\nMD5 hashes from the stored .kibana._mapping._meta through `curl`, and\r\nthen restarted Kibana. The step is run and leads to\r\n`UPDATE_TARGET_MAPPINGS` as it used to before the PR ✅\r\n- **Faking updating a plugin.** Same as the previous one, but altering\r\nan existing md5 stored in the metas. ✅\r\n\r\nAnd that is the curl command used to tamper with the stored _meta:\r\n```bash\r\ncurl -X PUT \"kibana:changeme@localhost:9200/.kibana/_mapping?pretty\" -H 'Content-Type: application/json' -d'\r\n{\r\n \"_meta\": {\r\n \"migrationMappingPropertyHashes\": {\r\n \"references\": \"7997cf5a56cc02bdc9c93361bde732b0\",\r\n }\r\n }\r\n}\r\n'\r\n```","sha":"b1e18a0414ed99456706119d15173b687c6e7366"}},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[{"branch":"main","label":"v8.7.0","labelRegex":"^v8.7.0$","isSourceBranch":true,"state":"MERGED","url":"https://github.com/elastic/kibana/pull/145604","number":145604,"mergeCommit":{"message":"Reduce startup time by skipping update mappings step when possible (#145604)\n\nThe goal of this PR is to reduce the startup times of Kibana server by\r\nimproving the migration logic.\r\n\r\nFixes https://github.com/elastic/kibana/issues/145743\r\nRelated https://github.com/elastic/kibana/issues/144035)\r\n\r\nThe migration logic is run systematically at startup, whether the\r\ncustomers are upgrading or not.\r\nHistorically, these steps have been very quick, but we recently found\r\nout about some customers that have more than **one million** Saved\r\nObjects stored, making the overall startup process slow, even when there\r\nare no migrations to perform.\r\n\r\nThis PR specifically targets the case where there are no migrations to\r\nperform, aka a Kibana node is started against an ES cluster that is\r\nalready up to date wrt stack version and list of plugins.\r\n\r\nIn this scenario, we aim at skipping the `UPDATE_TARGET_MAPPINGS` step\r\nof the migration logic, which internally runs the\r\n`updateAndPickupMappings` method, which turns out to be expensive if the\r\nsystem indices contain lots of SO.\r\n\r\n\r\nI locally tested the following scenarios too:\r\n\r\n- **Fresh install.** The step is not even run, as the `.kibana` index\r\ndid not exist ✅\r\n- **Stack version + list of plugins up to date.** Simply restarting\r\nKibana after the fresh install. The step is run and leads to `DONE`, as\r\nthe md5 hashes match those stored in `.kibana._mapping._meta` ✅\r\n- **Faking re-enabling an old plugin.** I manually removed one of the\r\nMD5 hashes from the stored .kibana._mapping._meta through `curl`, and\r\nthen restarted Kibana. The step is run and leads to\r\n`UPDATE_TARGET_MAPPINGS` as it used to before the PR ✅\r\n- **Faking updating a plugin.** Same as the previous one, but altering\r\nan existing md5 stored in the metas. ✅\r\n\r\nAnd that is the curl command used to tamper with the stored _meta:\r\n```bash\r\ncurl -X PUT \"kibana:changeme@localhost:9200/.kibana/_mapping?pretty\" -H 'Content-Type: application/json' -d'\r\n{\r\n \"_meta\": {\r\n \"migrationMappingPropertyHashes\": {\r\n \"references\": \"7997cf5a56cc02bdc9c93361bde732b0\",\r\n }\r\n }\r\n}\r\n'\r\n```","sha":"b1e18a0414ed99456706119d15173b687c6e7366"}}]}] BACKPORT-->
rudolf
added
the
Epic:ScaleMigrations
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The goal of this PR is to reduce the startup times of Kibana server by improving the migration logic.
Fixes #145743
Related #144035)
The migration logic is run systematically at startup, whether the customers are upgrading or not.
Historically, these steps have been very quick, but we recently found out about some customers that have more than one million Saved Objects stored, making the overall startup process slow, even when there are no migrations to perform.
This PR specifically targets the case where there are no migrations to perform, aka a Kibana node is started against an ES cluster that is already up to date wrt stack version and list of plugins.
In this scenario, we aim at skipping the
UPDATE_TARGET_MAPPINGSstep of the migration logic, which internally runs theupdateAndPickupMappingsmethod, which turns out to be expensive if the system indices contain lots of SO.I locally tested the following scenarios too:
.kibanaindex did not exist ✅DONE, as the md5 hashes match those stored in.kibana._mapping._meta✅curl, and then restarted Kibana. The step is run and leads toUPDATE_TARGET_MAPPINGSas it used to before the PR ✅And that is the curl command used to tamper with the stored _meta: