Scheduler should not be considered idle while a client submits new work
Đá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
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- python
- Lĩnh vực
- distributed-systems
Hướng nghiên cứu
Bắt đầu tại Scheduler.update_graph và theo dõi cách scheduler xử lý idle-timeout trong quá trình gửi graph. Sau đó, kiểm tra cách các lần gửi từ client đến được scheduler; công việc được xem là hoàn tất khi scheduler không bị coi là đang idle trong lúc update_graph hoặc một lần gửi đang hoạt động vẫn còn diễn ra, và hành vi liên quan được bao phủ bởi các bài kiểm thử.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Describe the issue:
I have seen several instances where a cluster with an idle timeout shut down because it took an excessive amount of time for the client to submit new work. In these cases, the scheduler should not have shut down because but rather anticipated that new work will arrive shortly.
As far as I can tell, we can address this in two steps:
- We should not consider the scheduler idle while
Scheduler.update_graphexecutes. This method is the main entry point for submitting new work to the cluster and it can take a while when encountering large or complex task graphs, resulting in a cluster shutting down while the scheduler is already preparing future work. - We should not consider the scheduler idle while a client submits new work. This is more complex. One possible solution would be for the client to announce to the scheduler that it starts submitting work. The scheduler will then have to ensure that it doesn't block being idle longer than necessary, i.e., handling submission attempts and client timeouts.
- Ngôn ngữ chính
- Python
- Star
- 1.7k
- Fork
- 781
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc 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 dask/distributed
-
needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
dask/distributed#9366 ·
-
Scipy's spmatrix deprecation keeps the Upstream nightly red after #9351 — all 14 test_serialize_scipy_sparse cases failCó thể đã có người làm Có pull request liên kết đang mở hoặc đã được merge. Đang mởneeds triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
dask/distributed#9353 · 1 bình luận ·
-
documentation
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 82/100
dask/distributed#8304 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
dask/distributed#4816 · 2 bình luận ·
-
Client.scheduler_info needs better documentationCó thể đã có người làm @nil68657 đã nhận 14 ngày trước. Đang mởdocumentation good first issue
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
dask/distributed#2378 · 2 bình luận ·
Tất cả issue của dask/distributed
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
nansencenter/geodataset#39 ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
awslabs/visual-asset-management-system#804 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
follow-up
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
Maintainer thường phản hồi trong vòng 1 ngày
-
[18.0] werkzeug: AttributeErrorĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
odoo/odoo#297927 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
link-rot
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 67/100