SGE - QSUB không gửi công việc ở chế độ đồng bộ

Question

Tôi có một tập lệnh perl chuẩn bị các tệp để nhập vào chương trình nhị phân và gửi chương trình nhị phân tới hệ thống xếp hàng SGE phiên bản 6.2u2.

Các công việc được gửi với tùy chọn -sync y để cho phép tập lệnh perl mẹ có khả năng theo dõi trạng thái của công việc đã gửi với chức năng waitpid. Điều này cũng rất hữu ích vì việc gửi SIGTERM đến kịch bản lệnh perl cha mẹ truyền tín hiệu này đến từng đứa trẻ, sau đó chuyển tiếp tín hiệu này lên qsub, do đó sẽ chấm dứt một cách duyên dáng tất cả các công việc đã gửi liên quan.

Do đó, điều quan trọng là tôi có thể gửi công việc với tùy chọn -sync y này.

Thật không may, tôi tiếp tục nhận được lỗi sau:

Unable to initialize environment because of error: range_list containes no elements

Thông báo chính tả không đúng cách 'containes'. Đó là KHÔNG một lỗi đánh máy. Nó chỉ cho bạn thấy làm thế nào kém duy trì khu vực này của mã/thông báo lỗi phải được.

Nội dung gửi cố gắng tạo ra lỗi này thậm chí không tạo ra tệp STDOUT và STDERR *.e{JOBID} và *.o{JOBID}. Việc gửi hoàn toàn không thành công.

Tìm kiếm google cho thông báo lỗi này chỉ dẫn đến các bài đăng chưa được giải quyết trên bảng tin tối nghĩa.

Lỗi này thậm chí không xảy ra đáng tin cậy. Tôi có thể chạy lại tập lệnh của mình và các công việc tương tự sẽ không nhất thiết tạo ra lỗi. Nó cũng có vẻ không quan trọng mà từ đó nút tôi cố gắng để gửi công ăn việc làm.

Hy vọng của tôi là ai đó ở đây có thể tìm ra điều này.

Câu trả lời cho bất kỳ câu hỏi như vậy sẽ giải quyết vấn đề của tôi:

1. Có lỗi này tồn tại trong nhiều phiên bản gần đây của SGE?
2. Tôi có thể thay đổi các tùy chọn dòng lệnh của mình cho qsub để tránh điều này không?
3. Thông báo lỗi này là gì?

Answer 1

Trang web của chúng tôi đã gặp sự cố này trong SGE 6.2u5. Tôi đã đăng một số câu hỏi trong danh sách gửi thư nhưng không có giải pháp. Cho đến bây giờ.

Nó chỉ ra rằng thông báo lỗi là không có thật. Tôi phát hiện ra điều này bằng cách đọc qua các bản ghi thay đổi trên repo github "open-core" Univa. Sau đó tôi thấy vấn đề được đề cập trong Ghi chú Phát hành của Con trai Gridengine v8.0.0c.

Dưới đây là các cam kết liên quan trong repo github:

• https://github.com/gridengine/gridengine/commit/b449607972614e4608272d8c0fc6f109d35fbecc
• https://github.com/gridengine/gridengine/commit/a47c32f965111554ec076db1526a6ad62c5bdae5

gì được thông báo lỗi nên nói là là bạn đã đạt giới hạn về số lượng trong số qsub sync -y công việc trong hệ thống. Thông số này được gọi là MAX_DYN_EC. Giá trị mặc định trong phiên bản của chúng tôi là 99, và những thay đổi trên tăng mà mặc định 1000.

Định nghĩa của MAX_DYN_EC (từ sge_conf (5) người đàn ông) là:

Sets the max number of dynamic event clients (as used by qsub -sync y and by Grid Engine DRMAA API library sessions). The default is set to 99. The number of dynamic event clients should not be bigger than half of the number of file descriptors the system has. The number of file descriptors are shared among the connections to all exec hosts, all event clients, and file handles that the qmaster needs.

Bạn có thể kiểm tra có bao nhiêu khách hàng sự kiện động bạn sử dụng lệnh sau:

$ qconf -secl | grep qsub | wc -l 

Chúng tôi đã thêm MAX_DYN_EC=1000-qmaster_params qua qconf -mconf. Tôi đã thử nghiệm gửi hàng trăm công việc qsub -sync y và chúng tôi không còn gặp lỗi range_list nữa. Trước khi thay đổi số MAX_DYN_EC, làm như vậy sẽ kích hoạt lỗi một cách đáng tin cậy.

Answer 2

Tôi đã tìm thấy giải pháp cho vấn đề này - hoặc ít nhất là giải pháp thay thế.

Mục tiêu của tôi là nhận các trường hợp riêng lẻ qsub để duy trì ở tiền cảnh vì công việc mà nó đã gửi vẫn còn trong hàng đợi hoặc đang chạy. Điều này đã đạt được với các tùy chọn -sync nhưng dẫn đến lỗi khủng khiếp không thể đoán trước mà tôi mô tả trong câu hỏi của tôi.

Giải pháp cho vấn đề này là sử dụng lệnh qrsh với tùy chọn now -n. Điều này làm cho công việc hoạt động tương tự như qsub -sync trong đó kịch bản của tôi có thể theo dõi ngầm xem công việc đã gửi có đang chạy hay không bằng cách sử dụng waitpid trên phiên bản qrsh.

Thông báo trước cho giải pháp này là hàng đợi bạn đang hoạt động không được phân biệt giữa các nút tương tác (được cung cấp bởi qrsh) và các nút không tương tác (có thể truy cập bởi qsub). Nếu có sự khác biệt tồn tại (có khả năng có ít nút tương tác hơn là không tương tác) thì cách giải quyết này có thể không hữu ích.

Tuy nhiên, vì tôi không tìm thấy gì ngay cả với giải pháp cho sự cố qsub -sync ở bất cứ nơi nào có chức năng như vậy, hãy để bài đăng này đi qua mạng nội bộ tới bất kỳ linh hồn nào bị bắt trong tình huống tương tự của tôi.