elementsd shutdown seems unnecessarily slow for long-running nodes
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Bắt đầu bằng cách xác định luồng tắt đang tự dỡ chỉ mục block và giải phóng các mục của nó, sau đó so sánh với hành vi khi tiến trình thoát. Nếu có thể, hãy tái hiện việc tắt sau khi một node chạy trong thời gian dài, đồng thời kiểm tra các test case tạo và hủy nhiều chỉ mục block. Được xem là hoàn tất khi tránh được công việc tắt không cần thiết mà vẫn duy trì việc xóa sạch ở những nơi các bài kiểm thử yêu cầu.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
I'm curious if other people are finding that elementsd shutdown takes forever when the node has been running for a very long time, or if this is somehow unique to my machine. It's possible this issue is somehow specific to mac or non-linux platforms; it's also possible it's been made worse by my memory-reducing fix.
What appears to be happening: during shutdown we manually unload the block index, and deallocate the entries, one at a time. This seems basically pointless -- all we're doing is manually freeing memory that will be freed anyway when the process exits. This does not seem to be slow if we've just started, but takes forever when run on a process that's been around for a long time. What I suspect is happening is that the block index has been paged out to disk, and in clearing it we're paging it in, a bit at a time, as we access the entries in random order. Even at SSD speeds, paging in multiple gigabytes using random reads is going to take ages.
(The more problematic possibility is some kind of leak, but I don't see the process having particularly excessive memory usage -- any more than usual -- so I don't think this is it.)
If possible, it would be nice to stop wasting all this effort on shutdown. Assuming it's in fact wasted, one possible catch is the use of the same codepaths in test cases -- we may still need to cleanly delete objects there, if we have to create and destroy multiple block indices before ending the process.
- Ngôn ngữ chính
- C++
- Star
- 1.2k
- Fork
- 418
- Merge trung bình
- 1 ngày 12 giờ
- Pull request đã merge (30 ngày)
- 13
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của ElementsProject/elements
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 58/100
ElementsProject/elements#1555 ·
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
ElementsProject/elements#1521 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 32/100
ElementsProject/elements#1516 · 5 bình luận ·
-
Compilation error on WSL Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
ElementsProject/elements#1502 · 1 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 38/100
ElementsProject/elements#1500 · 2 bình luận ·
Tất cả issue của ElementsProject/elements
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
flutter-webrtc/flutter-webrtc#2206 ·
-
litertlm-android AAR ships no consumer ProGuard rules → "mid == null" SIGABRT in minified apps Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
google-ai-edge/LiteRT-LM#3739 ·
-
Component: GLib
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
brave/brave-browser#59300 ·
-
Mute ydb/tests/functional/dstool/test_canonical_requests.py.Test.test_group_take_snapshot in main Đang mởai_reviewed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
ydb-platform/ydb#53974 · 3 bình luận ·