pingcap/tidb · critical

Out Of Global Analyze Memory Limit!

Error message

Out Of Global Analyze Memory Limit!

What it means

Fired by the same globalPanicOnExceed action in pkg/executor/select.go, but for the tracker labeled LabelForGlobalAnalyzeMemory: TiDB's server-wide quota on memory consumed by statistics gathering (ANALYZE). When concurrent ANALYZE jobs together exceed that quota, TiDB panics the analyze task with 'Out Of Global Analyze Memory Limit!' rather than letting ANALYZE destabilize the server.

Source

Thrown at pkg/executor/select.go:182

}

// Action panics when storage usage exceeds storage quota.
func (a *globalPanicOnExceed) Action(t *memory.Tracker) {
	a.mutex.Lock()
	defer a.mutex.Unlock()
	msg := ""
	switch t.Label() {
	case memory.LabelForGlobalStorage:
		msg = globalPanicStorageExceed
	case memory.LabelForGlobalMemory:
		msg = globalPanicMemoryExceed
	case memory.LabelForGlobalAnalyzeMemory:
		msg = globalPanicAnalyzeMemoryExceed
	default:
		msg = "Out of Unknown Resource Quota!"
	}
	// TODO(hawkingrei): should return error instead.
	panic(msg)
}

// GetPriority get the priority of the Action
func (*globalPanicOnExceed) GetPriority() int64 {
	return memory.DefPanicPriority
}

// SelectLockExec represents a select lock executor.
// It is built from the "SELECT .. FOR UPDATE" or the "SELECT .. LOCK IN SHARE MODE" statement.
// For "SELECT .. FOR UPDATE" statement, it locks every row key from source Executor.
// After the execution, the keys are buffered in transaction, and will be sent to KV
// when doing commit. If there is any key already locked by another transaction,
// the transaction will rollback and retry.
type SelectLockExec struct {
	exec.BaseExecutor

	Lock *ast.SelectLockInfo
	keys []kv.Key

View on GitHub (pinned to d01f9615c1)

Solutions

  1. Reduce analyze scope per run: ANALYZE with sample rate (ANALYZE TABLE t WITH 0.1 SAMPLERATE) or fewer columns instead of full ANALYZE.
  2. Serialize ANALYZE jobs (disable auto-analyze temporarily: SET GLOBAL tidb_enable_auto_analyze = OFF) so they do not stack on the quota.
  3. Raise the analyze/global memory quota (memory_usage_limit / relevant tidb_mem_quota_analyze settings) if the hardware allows.
  4. Run heavy ANALYZE off-peak, then re-enable auto-analyze.

Example fix

-- before: full analyze on a huge table trips the global analyze quota
ANALYZE TABLE orders;

-- after: sample instead of full scan
ANALYZE TABLE orders WITH 0.05 SAMPLERATE;
-- or restrict columns
ANALYZE TABLE orders INDEX o_custkey_idx;
Defensive patterns

Strategy: validation

Validate before calling

-- check analyze memory headroom and table size before launching ANALYZE
SELECT table_name, ROUND((data_length+index_length)/1024/1024) AS mb
FROM information_schema.tables
WHERE table_schema = 'mydb' ORDER BY mb DESC;

SET GLOBAL tidb_enable_auto_analyze = OFF; -- serialize with manual analyze first

Try / catch

-- the panic reaches the client as error 1105 on the ANALYZE statement;
-- retry once with a smaller sample rate
ANALYZE TABLE t; -- on 'Out Of Global Analyze Memory Limit!': ANALYZE TABLE t WITH 0.05 SAMPLERATE;

Prevention

When it happens

Trigger: Running ANALYZE (full or with high sampling) on very large tables, or several ANALYZE jobs in parallel, such that total analyze memory passes the global analyze quota; auto-analyze kicking in on big tables concurrently with manual ANALYZE.

Common situations: After ingesting a huge dataset and running ANALYZE TABLE ... ALL COLUMNS with default (near-full) sampling; enabling auto-analyze on many large tables at once; upgrading to a TiDB that added the global analyze-memory quota so previously-tolerated analyze workloads now panic; an instance already near its memory limit so the analyze quota is small.

Related errors


AI-assisted analysis of pingcap/tidb@d01f9615c1 (2026-08-15). Data as JSON: /api/errors/3f17319f0d4ee739. Report an issue: GitHub.