CapordiaXác định điều mà lịch phải bảo vệ
Hãy bắt đầu từ quyết định không thể chờ thêm: một buổi duyệt kết quả, một lần bàn giao cho nhóm khác hoặc thời điểm kết thúc kỳ thuê. Với mỗi dự án, hãy nêu rõ người có thẩm quyền chấp nhận kết quả của dự án đó. Một hạn bàn giao không chỉ đơn thuần là ngày kết thúc tính toán: việc rà soát lại và thu hồi tệp cũng phải có chỗ trong đó.
Sau đó, hãy phân biệt thời gian sẵn có của máy và của con người. Đôi khi một phép tính có thể chạy tiếp vào ban đêm, nhưng nhóm của bạn có thể cần có mặt cho lần chạy đầu tiên hoặc một lần xác nhận. Hãy ghi rõ ràng buộc này thay vì coi mọi giờ của gói là giờ làm việc có thể hoán đổi cho nhau. Lịch là một thỏa thuận nội bộ cần được xác nhận, không phải một cam kết cung cấp của Capordia.
Thu thập một ước tính sử dụng được, kèm nguồn gốc của nó
Đối với mỗi công việc, hãy ghi lại các đầu vào dự kiến, thời điểm chúng thực sự sẵn sàng, số lượng card đồng thời, bộ nhớ mỗi card và nhu cầu truyền tải. Thêm ước tính thời gian chiếm dụng tài nguyên từ lúc bắt đầu nạp đến khi giải phóng. Tách riêng các công việc chuẩn bị có thể làm trước thời gian chiếm dụng đó: điều này tránh việc giữ một card trong lúc chờ thủ tục hành chính.
Hãy nêu rõ ước tính đến từ một thử nghiệm tương đương, một phép ngoại suy hay chỉ là một giả định đơn thuần. Một khoảng thời gian cũ chỉ tương đương nếu dữ liệu, phiên bản, cấu hình và tài nguyên sử dụng đủ gần nhau. Khi không có số liệu đo đạc, hãy đánh dấu một khoảng giá trị cần xác nhận; đừng hiển thị độ chính xác đến từng phút vì điều đó gợi ý rằng đã có đo lường. Hãy dành một thử nghiệm đánh giá nhỏ khi kết quả của nó làm thay đổi lựa chọn lịch trình.
Chuyển từ tổng khối lượng sang các khung giờ khả thi
Hãy cộng các thời gian chiếm dụng dự kiến để phát hiện tình trạng quá tải rõ ràng, rồi đặt từng công việc lên một trục thời gian. Một xử lý không thể chia nhỏ kéo dài bốn giờ không lọt vào hai khoảng trống hai giờ, trừ khi đã xác nhận được việc ngắt và tiếp tục. Hai công việc đồng thời đòi cùng một đĩa hoặc cùng một người cũng có thể cản trở nhau ngay cả khi vẫn còn một card trống.
Tài liệu Slurm cho thấy vì sao việc lấp đầy khung giờ phụ thuộc vào thời lượng và tài nguyên yêu cầu: một tác vụ ít ưu tiên hơn có thể khởi chạy nếu nó không làm trễ thời điểm khởi chạy dự kiến của một tác vụ ưu tiên hơn. Logic này giúp đọc bản kế hoạch của bạn; nó không báo trước sự hiện diện của Slurm trong một dịch vụ Capordia. Mọi việc sử dụng một bộ lập lịch đều giả định cấu hình thực tế của nó và một chính sách do đội của bạn quyết định.
Ví dụ giả định: ba dự án trong hai ngày
Đội giả định « Bureau des tracés » có, cho bài tập này, một card khả dụng duy nhất từ 9 giờ đến 17 giờ trong hai ngày J1 và J2. Không có xử lý nào chia sẻ card và mỗi lần chiếm dụng đều gồm nạp, tính toán và xuất. Các thời lượng sau đây là những giả định mang tính minh họa: chúng không đến từ một GPU trong danh mục hay một phép đo chuẩn. Phần chuẩn bị chung chiếm một giờ vào đầu J1.
Atlas cần bốn giờ và phải được nộp trước J2 lúc 13 giờ. Balise cần ba giờ; đầu vào của nó đến vào J1 lúc 11 giờ và thời hạn nộp dự kiến là J1 lúc 18 giờ. Cadastre cần năm giờ; nó sẵn sàng vào J2 lúc 9 giờ và phải được nộp trước 18 giờ. Nhu cầu là 4 + 3 + 5 = 12 giờ. Với một giờ chung và ba giờ để trống, kế hoạch sử dụng hết mười sáu giờ mở.
| Khung giờ | Thời gian chiếm dụng dự kiến | Thời lượng | Điều kiện |
|---|---|---|---|
| J1, 9 giờ–10 giờ | Chuẩn bị và kiểm tra chung | 1 giờ | Đầu vào và phiên bản sẵn sàng |
| J1, 10 giờ–14 giờ | Atlas | 4 giờ | Công việc sẵn sàng lúc 10 giờ |
| J1, 14 giờ–17 giờ | Balise | 3 giờ | Đầu vào nhận được lúc 11 giờ |
| J2, 9 giờ–14 giờ | Cadastre | 5 giờ | Đầu vào nhận được lúc 9 giờ |
| J2, 14 giờ–17 giờ | Dự phòng chưa phân bổ | 3 giờ | Biên dự phòng chỉ có vào J2 |
Đặt biên dự phòng trước rủi ro mà nó phải hấp thụ
Ba giờ trống chiếm 25% trong mười hai giờ công việc. Tuy nhiên tỷ lệ này không đủ để bảo đảm cho Balise: biên dự phòng của nó nằm vào ngày hôm sau thời hạn nộp. Nếu Atlas mất năm giờ thay vì bốn, Balise không thể hoàn thành trước 17 giờ trong khung giờ được phép. Kế hoạch đứng vững trên giấy nhưng ngày đầu tiên vẫn mong manh. Cách đọc này hữu ích hơn một tỷ lệ lấp đầy trung bình đơn thuần.
Đội sau đó có thể chuyển Atlas một phần hoặc toàn bộ sang một khung giờ khác chỉ khi các ràng buộc của nó cho phép, xin thêm một khung giờ hoặc giảm một phạm vi đã được chấp nhận. Một card thứ hai là một phương án cần xem xét, không phải kết luận tự động: nó phải sẵn có, tương thích và đi kèm các tài nguyên máy chủ cần thiết. Nếu không có giải pháp nào được xác nhận, người phụ trách thay đổi cam kết của dự án trước khi khởi chạy, thay vì gọi « biên dự phòng » cho một khoản dự trữ không dùng được.
Phân xử một xung đột bằng một quy tắc đã công bố
Hãy chuẩn bị cơ chế phân xử trước khi hai người phụ trách cùng đòi một khung thời gian. Một quy tắc đơn giản có thể ưu tiên trước hết một hạn chót bên ngoài đã được xác nhận, rồi đến một công việc đã sẵn sàng đầu vào, rồi đến thời điểm yêu cầu được đưa ra. Hãy nêu rõ ai có thể miễn trừ quy tắc này và nhóm nào sẽ chịu phần lùi lại. Một trường hợp khẩn cấp phải có hệ quả rõ ràng đối với kế hoạch, chứ không được trở thành một ưu tiên thường trực mới cho người yêu cầu.
Hãy giữ lại lịch trình tham chiếu và lý do của các thay đổi: đầu vào đến muộn, thời lượng thực tế dài hơn hoặc phạm vi tăng lên. Hướng dẫn về hàng đợi công việc giải quyết việc quyết định lần chạy tiếp theo; còn lịch trình thì bảo vệ hạn chót của nhiều dự án. Sự gắn kết giữa hai thứ cho phép giải thích vì sao một GPU tạm thời rảnh không nhất thiết là sẵn sàng cho một tác vụ xử lý dài bổ sung.
Kiểm tra kế hoạch và điều chỉnh với những sai lệch đúng
Hãy đọc lại một ngày bằng cách đi từng khung thời gian một. Mỗi lần khởi chạy phải có sẵn đầu vào, quyền truy cập, dung lượng bộ nhớ và người phụ trách. Hãy kiểm soát khâu bàn giao cuối cùng và thời gian đọc lại trước khi nộp. Sau đó mô phỏng độ trễ hợp lý nhất và kiểm tra xem biên dự phòng nào thực sự hấp thụ được nó. Nếu chỉ một sai lệch cũng khiến bỏ lỡ một hạn chót quan trọng, hãy trình bày kế hoạch như một phương án có điều kiện.
Sau một lần thực thi thực tế, hãy phân tách thời gian chờ trước khi khởi chạy, thời gian GPU bận và thời gian đến khi kết quả được chấp nhận. Hãy chỉnh sửa ước lượng tiếp theo dựa trên cách phân tách này. Một độ trễ truyền tải không tự nó biện minh cho một GPU mạnh hơn; một khâu chuẩn bị thủ công bị bỏ sót không thể khắc phục bằng cách tăng biên dự phòng cho tính toán. Việc theo dõi phải giúp loại bỏ nguyên nhân của sai lệch, chứ không phải tìm người chịu trách nhiệm từ một con số tổng hợp tách rời.
Gắn lịch với gói mà không nhầm lẫn các đơn vị
Một ngày tám giờ trong ví dụ này là khung tổ chức, không phải mức giá tám giờ. Danh mục Capordia cung cấp các khoảng thời gian cố định 3, 7 hoặc 30 ngày và giá theo trọn gói. Hãy kiểm tra riêng thời hạn thuê, số lượng card trong gói và lịch làm việc. Thêm một card không xóa bỏ khâu chuẩn bị cũng như bước xác nhận của con người.
Sản phẩm hữu ích là một lịch đã được phê duyệt kèm các giả định, phần dự phòng đã đặt và các quyết định khi có sai lệch. Vẫn cần xác nhận với nguồn lực thực tế được cung cấp và một thử nghiệm đại diện. Đừng biến mười sáu giờ của bài tập hay tỷ lệ dự phòng của nó thành thời hạn được bảo đảm hoặc quy tắc định cỡ phổ quát.
Câu hỏi để quyết định
Tôi có thể chia số giờ dự kiến cho số GPU không?
Chỉ khi các công việc có thể tiến hành song song và các nguồn lực khác cho phép. Một xử lý không thể chia nhỏ, một phụ thuộc hoặc một bước rà soát lại có thể giới hạn lịch. Hãy làm rõ những ràng buộc này trước khi quy đổi tổng số giờ thành số card.
Cần dự phòng bao nhiêu?
Mức dự phòng phụ thuộc vào các sai lệch có thể xảy ra và vị trí của chúng trong lịch. Ba giờ trong ví dụ là giả định và không bảo vệ được mọi mốc thời hạn. Hãy đặt dự phòng trước thời điểm bàn giao mà nó cần bảo đảm, rồi biện minh bằng những quan sát của bạn.
Lịch trình có thay thế việc nhận máy không?
Không. Lịch trình giả định rằng tài nguyên và ứng dụng đã sẵn sàng sử dụng. Việc nhận máy phải xác minh giả định này trước khi coi các khung giờ là khả dụng. Nếu một điều kiện vẫn chưa rõ, lịch phải giữ trạng thái tạm thời và một phương án dự phòng.