Owen Trask

Worth knowing the accounting rule too: the cgroup counts page cache against your limit, so a container that reads or writes large files can be killed even though the application's own allocations are modest. If your workload touches big files, that is a real and very confusing source of OOMKills.

That is the single most common version of this. The JVM needs headroom above the heap for metaspace, thread stacks and native buffers - as a rule of thumb leave 25% of the container limit outside the heap.

That was it. Eleven missing days across the year, all Sundays and two public holidays. Rebuilt with CALENDAR and every month populates now. I had no idea it failed silently rather than complaining.

Exponential backoff sounds fancy but it is four lines. Double the wait on each consecutive failure, cap it, reset on success.

A well quote is really four jobs bundled together, and cheap quotes are usually cheap because they only include the first. There is drilling, normally priced per foot; the casing and grouting, also per foot and sometimes quoted separately; the pump, pressure tank, wiring and pressure switch, which is a different trade in some places; and the trench from wellhead to house plus the electrical hookup. Ask every bidder to break out those four and the difference between your quotes will usually explain itself in ten minutes.

Before you move a penny, work out how much of that 3x is people searching your brand name. Pause only the brand campaigns for two weeks in a couple of regions and watch what happens to total orders, not to the ads dashboard. In our case a meaningful share of what paid was claiming just walked through the organic result instead, so the true incremental return on that slice was much lower than reported. That test cost us almost nothing and changed the budget conversation completely.

Be a bit careful lowering ndots globally, short in-cluster names like postgres rely on the search path. Setting it per workload is safer than cluster-wide.

I have watched both for about two years on a small B2B tool. Time to first value was the more actionable one because it points at a specific part of the product - when it went up, it was always a concrete thing, an added form field, a slow import, a confusing empty state. The gap between sessions was the better predictor of who stayed but it told me nothing about what to fix, because by the time it was long the person had already decided. Measure the second, act on the first.

Learned this the hard way on a table with 400k SKUs. The measure was correct and the report was unusable.

For anyone finding this later: the general rule is that every range inside an ARRAYFORMULA should either be the same height or be an absolute reference. A bare relative single cell in there means trouble.

separate the margins too, because they will not be alike. my software line runs at a margin dominated by hosting and support, and my services line is essentially my hourly rate minus overhead, so a month with lots of services looks great on revenue and is much worse on profit per hour worked. i track revenue per hour worked on the services side specifically, and it changed which customers i said yes to.

If those CSVs are a monthly drop that several reports use, consider landing them once in a dataflow and pointing the reports at that. Credentials get configured in one place and you stop paying the file-parsing cost in every dataset.

If this is a workload you want to survive losing a zone, the storage choice is the real decision rather than the drain procedure. Zonal block storage plus a single-replica StatefulSet is a single point of failure by design. Either accept that and plan capacity per zone, or move to something replicated at the storage layer.

Left aligned means Sheets is storing them as text, so you are sorting alphabetically: "12" before "03" makes perfect sense to a string comparison.

The #VALUE pattern gives away the real problem: your export is almost certainly US format (MM/DD/YYYY) and your sheet is UK. Rows where the day is 13 or higher fail outright because there is no month 13. Rows where the day is 12 or lower silently convert to the wrong date, which is much worse: 03/11 becomes 3 November when it meant 11 March, and nobody notices until a quarterly total is off.

Parse it explicitly rather than trusting DATEVALUE:
=ARRAYFORMULA(IF(A2:A="","",DATE(INDEX(SPLIT(A2:A,"/"),,3), INDEX(SPLIT(A2:A,"/"),,1), INDEX(SPLIT(A2:A,"/"),,2))))
That reads position 3 as year, 1 as month, 2 as day. Swap the last two arguments if your source really is day first. Then format the output as a date and sort on that.

Honest counterpoint: if the report is genuinely one grain, nobody else builds on the dataset, and it fits comfortably in memory, a flat table is not a sin. The cost is not correctness, it is every future change. Adding a new attribute to a dimension touches one small table; adding it to a flat table is a 12 million row reload every time.

Good caveat. I put a last-recalculated cell at the top of anything built on IMPORTRANGE so people can judge for themselves.

Stack it, but stack it once into a real all-sites tab rather than doing it inside every summary formula.

The pattern that has held up for me: one hidden tab that is nothing but ={IMPORTRANGE(url1,"data!A2:F"); IMPORTRANGE(url2,"data!A2:F"); ...}, with a site name column carried through from each source, then every summary on the sheet is a QUERY against that one range. Adding site 31 is one line in one place instead of a new column in 40 formulas.

The VLOOKUP-per-tab approach does not fail gradually. It fails the day somebody renames a tab.