reduce startup time by skipping update mappings step #145743
Labels
Team:Core
Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc
Comments
|
Pinging @elastic/kibana-operations (Team:Operations) |
spalger
added
Team:Core
|
Pinging @elastic/kibana-core (Team:Core) |
This was referenced Nov 28, 2022
gsoldevila
added a commit
that referenced
this issue
Nov 28, 2022
…145604) 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_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", } } } ' ```
gsoldevila
added a commit
to gsoldevila/kibana
that referenced
this issue
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
referenced
this issue
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-->
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reduce startup time by not running "patching migrations" every time kibana is started.
We will do this by comparing the md5sums of the fields for each of the saved object types. If the md5sums match we will not perform the
UPDATE_TARGET_MAPPINGSstep and the associatedupdateAndPickupMappingsaction. (We will still run theOUTDATED_DOCUMENTS_*steps because sometimes documents can be outdated even when mappings weren't changed.)The text was updated successfully, but these errors were encountered: