Daojiang Yan created KUDU-3778:
----------------------------------
Summary: Speed up log block manager startup by replaying small
container metadata files from memory
Key: KUDU-3778
URL: https://issues.apache.org/jira/browse/KUDU-3778
Project: Kudu
Issue Type: Improvement
Reporter: Daojiang Yan
Assignee: Daojiang Yan
Fix For: Backlog
*Description*
On startup,LogBlockContainerNativeMeta::ProcessRecords() replays each
container's. metadata file through ReadablePBContainerFile::ReadNextPB(), which
issues two preadv() syscalls per record (one for the length+checksum prefix,
one for the body+checksum). The total number of read syscalls during the
"Reading filesystem" phase is therefore O(total records across all containers).
On a tserver with many containers each holding many records, this turns startup
into a long stream of tiny sequential reads against the kernel.
*Proposal*
Add an opt-in fast path: when a metadata file's payload fits in a configurable
budget, read it once into a faststring and let ReadablePBContainerFile parse it
through an in-memory RandomAccessFile shim (MemoryReadableFile). This collapses
the per-record preadv() pair into a single bulk read per container, so the
syscall count during startup drops from O(records) to O(containers). Any I/O
error during preload, or an oversized file, transparently falls back to the
existing streaming path, so the optimization can only help and never widen the
failure envelope of startup.
The fast path is gated by --log_container_metadata_inmem_replay_threshold_bytes
(default 64 MiB; runtime/advanced/experimental). Set to 0 to disable. Only
applies to --block_manager=log with native metadata; encrypted metadata files
are intentionally left on the streaming path.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)