mirror of
https://github.com/kvcache-ai/Mooncake.git
synced 2026-11-05 01:17:55 +00:00
[GH-ISSUE #221] We found that deleting slices leads to poor performance。delete slice 有性能问题 #94
Labels
No labels
ascend
auto-closed
bug
bug
CI/Build
Common
documentation
enhancement
feature request
good first issue
help wanted
high priority
MetaX
nightly-failure
pull-request
PyTorch Backend
question
RFC
Roadmap
stale
Store
Tests
Transfer Engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
kvcache-ai/Mooncake#94
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @a4zhangfei on GitHub (Apr 9, 2025).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/221
github.com/kvcache-ai/Mooncake@5ed7331871原本有内存泄漏的问题,后面有PR修复了,升级之后不会内存泄漏了,但是会导致性能变差,(500ms)怀疑是 delete 导致,注释掉下面的就没问题
@xiaguan commented on GitHub (Apr 9, 2025):
Is there a reproducible case available? Or, could you share how you identified this performance issue?
@xiaguan commented on GitHub (Apr 9, 2025):
By the way, pr #220 fixed a known long-tail issue, which might resemble the problem you described. You might want to try updating and see if it helps?
@a4zhangfei commented on GitHub (Apr 9, 2025):
@xiaguan
thanks for your reply. However, update to the latest code did not resolve the performance issue.
we use it transfer kv data from prefill instance to decode instance layer-wise.
P/D instance TP4,slice_count: 2w~3w / layer, too many slices cause performance issues with delete.
@xiaguan commented on GitHub (Apr 9, 2025):
You could also check here
github.com/kvcache-ai/Mooncake@b31b8b84b9/mooncake-transfer-engine/src/transport/rdma_transport/rdma_transport.cpp (L215C1-L222C75)@alogfans commented on GitHub (Apr 10, 2025):
@a4zhangfei In the previous patch, the delete operations are internally executed in the transfer engine's worker thread. So we moved them back the call of freeBatchID. We also use a thread-local Slice cache to reduce the call of new/delete.
@ShangmingCai commented on GitHub (Apr 10, 2025):
Closed as fixed.