microsoft / microsoft/demikernel

[catnip] Catnip runs out of memory at higher loads

Open
#862 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug confirmed
Dominant language
Rust
Stars
1.2k
Forks
151
PR merge metrics
No merged PRs in 30d

Description

Description

Catnip panics with failed to clone mbuf every time at higher loads with multiple connections. The reason is that the DPDK mempool runs out of free memory to clone mbufs from. This has been verified using rte_mempool_avail_count(). It was tested using a custom example static page HTTP server and the Caladan client generator at 150K requests per second over 100 connections (this number is specific to my testing, but there is always a threshold value above which it runs out of memory). This issue was not occurring on commit 803c363a765ae14f3eff2a9de021eabf23f8d10c dated 30th September 2022.

The pattern stays similar every time:

The server works fine (the free memory in the mempool stays around the same) for a short while.
The free memory then starts decreasing. The decreases are always in big jumps and then they start rising slowly for a while (presumably due to free()s) before a big decrease again (another big allocation), with a net negative differential.
This continues until the mempool is out of memory and the server panics.

Note: This issue does not happen for a lesser number of connections. A possible reason could be the O(N) time complexity of wait_any(), which leads to a higher time interval between calls to poll() as the number of connections, and consequently the number of QTokens passed to wait_any(), increases, leading to a backlog of arrivals at the NIC that are polled all at once, which requires a large allocation of DPDK memory. This still does not explain why it did not occur in the aforementioned commit, so something elsewhere was probably modified that causes this memory leak.

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 failure with the custom example static page HTTP server and Caladan client generator at higher connection loads, while monitoring DPDK's mempool with rte_mempool_avail_count(). Read wait_any() and poll() first, then compare behavior with commit 803c363a765ae14f3eff2a9de021eabf23f8d10c. Done means the server no longer exhausts mbuf memory and panic under the reported load.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.