kvcache-ai / kvcache-ai/Mooncake

[Usage]: If sglang (client) restarts, can it use old data from the SSD?

Open
#3,817 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
6.6k
Forks
1.2k
Avg merge
3d 5h
Merged PRs (30d)
312

Description

Describe your usage question

My startup method is as follows:
mooncake_master \ --rpc_port=50054 \ --rpc_thread_num=64 \ --enable_http_metadata_server=true \ --http_metadata_server_port=8084 \ --http_metadata_server_host=0.0.0.0 \ --metrics_port=9007 \ --enable_metric_reporting=true \ --enable_offload=true \ --eviction_ratio=0.05 \ --eviction_high_watermark_ratio=0.8 \ --offload_on_evict=true \ --promotion_on_hit=true

export MOONCAKE_OFFLOAD_FILE_STORAGE_PATH=/mnt/ssd1/ymj_moon_2
export MOONCAKE_OFFLOAD_TOTAL_SIZE_LIMIT_BYTES=$ ((4096 * 1024 * 1024 * 1024))
export MOONCAKE_OFFLOAD_STORAGE_BACKEND_DESCRIPTOR=bucket_storage_backend
export MOONCAKE_OFFLOAD_BUCKET_MAX_TOTAL_SIZE= $((4096 * 1024 * 1024 * 1024))
export MOONCAKE_OFFLOAD_LOCAL_BUFFER_SIZE_BYTES=$ ((512 * 1024 * 1024))
export MOONCAKE_OFFLOAD_BUCKET_EVICTION_POLICY=lru
export MOONCAKE_OFFLOAD_ENABLE_DISK_WATERMARK_EVICTION=true
export MOONCAKE_OFFLOAD_DISK_EVICTION_HIGH_WATERMARK_RATIO=0.85
export MOONCAKE_OFFLOAD_DISK_EVICTION_LOW_WATERMARK_RATIO=0.70
export MOONCAKE_OFFLOAD_USE_URING=true
export MOONCAKE_ENABLE_SSD_OFFLOAD=1
export MC_CLIENT_METRIC_REPORT_INTERVAL=30
export MC_TE_METRIC=1
export MC_STORE_CLIENT_METRIC=1
export MC_STORE_CLIENT_METRIC_INTERVAL=30
export MC_STORE_CLIENT_METRIC_BANDWIDTH=1
export MC_TE_METRIC_INTERVAL_SECONDS=30
export MOONCAKE_MASTER=0.0.0.0:50054
export MOONCAKE_TE_META_DATA_SERVER="http://0.0.0.0:8084/metadata"
export MOONCAKE_PROTOCOL="rdma"
export MOONCAKE_DEVICE="mlx5_3"
export MOONCAKE_GLOBAL_SEGMENT_SIZE= $((16 * 1024 * 1024 * 1024))
export MC_TRANSFER_CHECK=1
export MOONCAKE_STORE_CHECKSUM=1
export MC_IB_PCI_RELAXED_ORDERING=1

sglang serve \ --trust-remote-code \ --model-path /mnt/ssd1/modelscope/DeepSeek-V4-Flash \ --tp 4 \ --moe-runner-backend marlin \ --mem-fraction-static 0.85 \ --chunked-prefill-size 4096 \ --enable-hierarchical-cache \ --hicache-ratio 1 \ --hicache-write-policy write_through_selective \ --host 0.0.0.0 \ --port 9002 \ --enable-metrics \ --enable-cache-report \ --hicache-storage-backend mooncake --hicache-mem-layout page_first_direct --hicache-io-backend direct --hicache-storage-prefetch-policy wait_complete
I ran a test with the following steps:
1.After starting mooncake and sglang, I ran a set of online Claude code datasets. After the run, the SSD stored 44GB of data.
2.I killed the sglang process to simulate an abnormal interruption. At this point, the SSD storage in the master dropped to 0. After sglang restarted, the master storage recovered to 30GB.
3.I re-ran the same dataset, but found that the prefix hit ratio showed no improvement compared to the first run.

I have two main questions about this:
1.After the first run, 44GB of data was stored in the SSD. Why did only 30GB of data get recovered after sglang restarted?
2.Why is there no improvement in the prefix hit ratio when running the dataset the second time, even though 30GB of cache data is stored in the SSD? It seems that these 30GB of data did not take effect.

Before submitting a new issue...
  • Make sure you already searched for relevant issues and read the documentation

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the restart sequence with mooncake_master and sglang serve using the listed SSD-offload settings, then inspect the master’s storage recovery and cache-hit metrics before and after the restart. Done means explaining the 44GB-to-30GB recovery difference and why the recovered data does not improve the second dataset run.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
databases, distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.