thanks for sharing the log project. It is a 2 CPU box. We can look at a larger CPU config, but fwiw we have used that box config for roughly 18 months, wasn't til 0.48.x that we ran into this issue.
Hi!
We're having this same issue too. Before we never had problem with high CPU usage, but when we upgraded to 0.48.x it started to make our UI irresponsive and slow. Then goes down.
wha tis even odder is it is just stuck at 40% now, constant, no variability in it at all.
Is the spike when the sync happens?
we are running Metabase 0.48.3 and we are facing High CPU spikes unexplained , when can we expected the fix for high CPU spikes. ??
We’re working on this as well, but as you can see from our questions, there are no answers. It’s very hard to fix issues that we can’t see
let us know what details you want to fix this issue from us, will try to provide you logs and details.
What Metabase is doing when cpu spikes, what database it is, what process it’s running and what data types do you have, logs as well
thanks for continuing to look into this issue. We did provide logs earlier and you indicated that syncs were overlapping on a 2 cpu box so we upgraded to a 4 cpu box but experience the same issues. we have multiple databases in our warehouse and there does not appear to be any one particularly database which causes the CPU spike, it seems entirely random. our processing ETL has not changed in the last 3 months so it isn't how the data loading is working. Also we were running on 47.8 prior to the 48.3 upgrade so whatever delta happened between those two release versions is where the problem resides. This is our CPU history for the last 6 weeks, until the 48.x upgrade on 1/13/2024 there was never anything remotely resembling what is happening now. The one thing we can say for sure is that by rebooting the metabase process twice a day, 1am and 1pm EST, we do not experience any CPU spike.
we're launching a new version today with some changes, can you check it out?
sure, we'll give it a try. may be Wed evening before we know more about behavior.
Has anyone checked High CPU utilization issue with Metabase 0.48.4 ??
I have upgraded but the problems still persist. Especially with dashboards in which calculations are carried out via custom collums and a date filter is also set, for example. Simple dashboards with normal queries do not have the problem and run without CPU spikes
the problem we fixed (still haven't got the confirmation it's fixed) is that on syncs the CPU was skyrocketing. The problem you might be seeing is Big custom columns expressions use a lot of CPU resources (e.g. CASE) · Issue #33498 · metabase/metabase · GitHub, which is simply a consequence of Metabase building massive strings in custom columns (please confirm)
That is correct. The problems with my queries seem to be related to large queries. However, since the problems have also existed since the update to 0.48, I suspected a connection. Until the update, the queries ran on one CPU in a reasonable time. I have since upgraded to 4 CPUs, but this has not helped.
1 Like
please post the questions here so we can see where the problem is
fwiw we upgraded to 48.4 but the CPU spike occurred within 24 hours. what we find interesting is once the CPU gets pegged (this is now a 4 CPU box) it never drops back down without rebooting the instance.
Can you post what process starts when there's a spike? that doesn't seem to be normal. Do you know if there's any other process running on your host?
there are no other processes running on this box, it only services Metabase (it is the only non-Ubuntu core process running on the box). It was a 2 CPU box that was fine for years, then 0.48.3 and now CPU spikes. We upgraded to a 4 CPU box, still has issues. The only resolution is to reboot the box, we have it setup to do so twice a day so that it does not have a run away process. We can try to get the process that is the issue but to do so means to impact our users which we'd prefer not to do. We'll see what we can do to get more details. this is 6 weeks of CPU history, 0.48.3 upgrade happened on 1/13. anyway, we'll see if we can get any more details for you.
