You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original install method (e.g. download page, yum, from source, etc.): apt package from elastic repo
Description of the problem including expected versus actual behavior:
I've seen a number of comments about the time and system resources required for kibana to do the optimization steps on first start, and again at each plugin install. We use ansible to deploy all of our infrastructure and we have it all tied into CI that does at least one full deploy for every Pull Request and Merge into our git repo.
After upgrading from kibana3 to kibana5 I noticed a massive spike in the time it took in both local dev and in CI to do deploys. I narrowed it down to the fact that we're using smallish VMs ( 2 cpu, 2-4gb memory ) and the optimize steps takes 20+ minutes ( I've seen it take 40+ on local vagrant VMs ) per run, which if there's several plugins being installed can really add up.
Our deploy stalls at this step for two reasons ... one, we wait until kibana is listening on port 5601 before moving to the next task, when I disable that pause it stalls here because the optimize step takes up all my cpu and memory and swaps like crazy.
For now I've feature flagged starting and enabling plugins so that it simply does not get started and therefore we don't have to wait for the optimize steps to run, however that also means I've disabled the tests that ensure kibana is actually running and listening correctly.
I understand this step is needed, but it is really painful and is hurting our Productivity and/or our Test Coverage.
I'm not sure if this is actually a feature request, or a bug report, or just me griping somewhere.
The text was updated successfully, but these errors were encountered:
The "optimize" step is endlessly frustrating and crazy-CPU intensive, and we need to fix it. It's not an easy project, but it is underway. I recommend following along with issues #10908 and #9675.
One of the core goals of the new build system is removing the transpilation step entirely, so plugins are built in advance and installing them is essentially just an unzip, which should bring your Kibana startup time down by several orders of magnitude.
I'm going to close this in favor of #10908, but please feel free to join us there with any thoughts you have.
Kibana version: 5.4.1
Server OS version: ubuntu xenial
Original install method (e.g. download page, yum, from source, etc.): apt package from elastic repo
Description of the problem including expected versus actual behavior:
I've seen a number of comments about the time and system resources required for kibana to do the optimization steps on first start, and again at each plugin install. We use ansible to deploy all of our infrastructure and we have it all tied into CI that does at least one full deploy for every Pull Request and Merge into our git repo.
After upgrading from kibana3 to kibana5 I noticed a massive spike in the time it took in both local dev and in CI to do deploys. I narrowed it down to the fact that we're using smallish VMs ( 2 cpu, 2-4gb memory ) and the optimize steps takes 20+ minutes ( I've seen it take 40+ on local vagrant VMs ) per run, which if there's several plugins being installed can really add up.
Our deploy stalls at this step for two reasons ... one, we wait until kibana is listening on port 5601 before moving to the next task, when I disable that pause it stalls here because the optimize step takes up all my cpu and memory and swaps like crazy.
For now I've feature flagged starting and enabling plugins so that it simply does not get started and therefore we don't have to wait for the optimize steps to run, however that also means I've disabled the tests that ensure kibana is actually running and listening correctly.
I understand this step is needed, but it is really painful and is hurting our Productivity and/or our Test Coverage.
I'm not sure if this is actually a feature request, or a bug report, or just me griping somewhere.
The text was updated successfully, but these errors were encountered: