YAU.POC/yau-plant-assistant
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Refresh pre-aggregations daily, not every ten minutes

Browse source 
lin001 is 2 vCPU with 3.8 GiB and no swap, shared with 27 other containers.
Cube was rebuilding three pre-aggregations over static fixture data on 10, 10
and 30 minute keys, and its own log shows what that cost:

    "Previous interval #19593 was not finished with 30000 interval"
    "Interval #19594 finished after 00:02:50"

A refresh taking 2m50s scheduled every 30 seconds, at interval #19594 -
overlapping and never catching up, for days. Every rebuild produced a
byte-identical result, because the fixtures do not change.

24 hours until imh makes the data genuinely live, at which point these get
tuned deliberately rather than left at a number that was never chosen. Cube
also suggests fewer partitions via rollup_lambda; that is a modelling change,
not a demo-day one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Claude 2026-08-28 10:53:42 +10:00
parent 16c4bba3bd
commit 156d2a6d43
3 changed files with 15 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
cube/model/alarms.yml
View file

@ -157,7 +157,11 @@ cubes:
granularity: hour granularity: hour
partition_granularity: month partition_granularity: month
refresh_key: refresh_key:
every: 10 minutes # 24h, not minutes: the fixtures are static, so a shorter
# interval rebuilds a byte-identical result on a 2-vCPU host
# and was a standing CPU load for no gain. Tune this back
# deliberately when imh makes the data genuinely live.
every: 24 hours
build_range_start: build_range_start:
sql: "SELECT now() - interval '180 days'" sql: "SELECT now() - interval '180 days'"
build_range_end: build_range_end:

6
cube/model/operations.yml
View file

@ -165,7 +165,11 @@ cubes:
granularity: day granularity: day
partition_granularity: month partition_granularity: month
refresh_key: refresh_key:
every: 30 minutes # 24h, not minutes: the fixtures are static, so a shorter
# interval rebuilds a byte-identical result on a 2-vCPU host
# and was a standing CPU load for no gain. Tune this back
# deliberately when imh makes the data genuinely live.
every: 24 hours
build_range_start: build_range_start:
sql: "SELECT now() - interval '365 days'" sql: "SELECT now() - interval '365 days'"
build_range_end: build_range_end:

6
cube/model/process_values.yml
View file

@ -201,7 +201,11 @@ cubes:
granularity: hour granularity: hour
partition_granularity: month partition_granularity: month
refresh_key: refresh_key:
every: 10 minutes # 24h, not minutes: the fixtures are static, so a shorter
# interval rebuilds a byte-identical result on a 2-vCPU host
# and was a standing CPU load for no gain. Tune this back
# deliberately when imh makes the data genuinely live.
every: 24 hours
build_range_start: build_range_start:
sql: "SELECT now() - interval '180 days'" sql: "SELECT now() - interval '180 days'"
build_range_end: build_range_end: