VictoriaMetrics/VictoriaMetrics · error

too big data size: %d; it mustn't exceed %d bytes

Error message

too big data size: %d; it mustn't exceed %d bytes

What it means

Returned by vmselectRequestCtx.readDataBufBytes when the 8-byte size header was read successfully but declares a data size larger than the caller's maxDataSize limit (e.g. maxSearchQuerySize = 5MiB). This is a deliberate guard against oversized/allocation-bombing packets; the server refuses to allocate the buffer and aborts the request.

Source

Thrown at lib/vmselectapi/server.go:397

		return fmt.Errorf("cannot unmarshal SearchQuery: %w", err)
	}
	if len(tail) > 0 {
		return fmt.Errorf("unexpected non-zero tail left after unmarshaling SearchQuery: (len=%d) %q", len(tail), tail)
	}
	return nil
}

func (ctx *vmselectRequestCtx) readDataBufBytes(maxDataSize int) error {
	ctx.sizeBuf = bytesutil.ResizeNoCopyMayOverallocate(ctx.sizeBuf, 8)
	if _, err := io.ReadFull(ctx.bc, ctx.sizeBuf); err != nil {
		if err == io.EOF {
			return err
		}
		return fmt.Errorf("cannot read data size: %w", err)
	}
	dataSize := encoding.UnmarshalUint64(ctx.sizeBuf)
	if dataSize > uint64(maxDataSize) {
		return fmt.Errorf("too big data size: %d; it mustn't exceed %d bytes", dataSize, maxDataSize)
	}
	ctx.dataBuf = bytesutil.ResizeNoCopyMayOverallocate(ctx.dataBuf, int(dataSize))
	if dataSize == 0 {
		return nil
	}
	if n, err := io.ReadFull(ctx.bc, ctx.dataBuf); err != nil {
		return fmt.Errorf("cannot read data with size %d: %w; read only %d bytes", dataSize, err, n)
	}
	return nil
}

func (ctx *vmselectRequestCtx) readBool() (bool, error) {
	ctx.dataBuf = bytesutil.ResizeNoCopyMayOverallocate(ctx.dataBuf, 1)
	if _, err := io.ReadFull(ctx.bc, ctx.dataBuf); err != nil {
		if err == io.EOF {
			return false, err
		}
		return false, fmt.Errorf("cannot read bool: %w", err)

View on GitHub (pinned to 5079fb58f1)

Solutions

  1. Fix client-side stream desync: a bogus huge size usually means a previous packet was written with the wrong length; re-align the protocol framing.
  2. Reduce request size (split large label-value or metadata requests into batches).
  3. Check for byte-order bugs in the client's size encoding (big-endian vs little-endian produces huge values).
  4. If legitimately larger packets are needed, raise the max size (maxSearchQuerySize) and rebuild, understanding the memory trade-off.
  5. Investigate the sending client for corruption or malicious traffic; consider network ACLs.

Example fix

// before: big-endian size confuses server
binary.BigEndian.PutUint64(hdr, uint64(len(payload)))
// after
var hdr [8]byte
binary.LittleEndian.PutUint64(hdr[:], uint64(len(payload)))
conn.Write(hdr[:])
conn.Write(payload)
Defensive patterns

Strategy: validation

Validate before calling

// client side: enforce the same limits as the server
const maxSearchQuerySize = 5 * 1024 * 1024
if uint64(len(payload)) > maxSearchQuerySize {
    return fmt.Errorf("payload %d exceeds server limit %d", len(payload), maxSearchQuerySize)
}

Try / catch

if err := ctx.readDataBufBytes(max); err != nil {
    if strings.Contains(err.Error(), "too big data size") {
        return ErrPacketTooLarge // permanent; do not retry identical request
    }
    return err
}

Prevention

When it happens

Trigger: A client sends a length-prefixed packet whose declared dataSize exceeds the endpoint's limit: a SearchQuery packet >5MiB, or oversized packets for processRequest, processRegisterMetricNames, processLabelValues, processTagValueSuffixes, processTSDBStatus.

Common situations: Corrupted/garbage size header (e.g. desynced stream reading payload bytes as a size); runaway client buffers serialized whole; adversarial clients sending huge declared sizes; version mismatches with larger packet formats.

Related errors


AI-assisted analysis of VictoriaMetrics/VictoriaMetrics@5079fb58f1 (2026-09-03). Data as JSON: /api/errors/1e7bb26b986fc4ed. Report an issue: GitHub.