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)

Reply via email to