SGE - QSUB nie przesyła zadań w trybie synchronizacji

Question

Mam skrypt perla, który przygotowuje pliki do wprowadzenia do programu binarnego i przekazuje wykonanie programu binarnego do systemu kolejkowania SGE w wersji 6.2u2.

Zadania są przesyłane z opcją -sync y, aby umożliwić nadrzędnemu skryptowi perla monitorowanie stanu przesyłanych zadań za pomocą funkcji waitpid.

Jest to również bardzo przydatne, ponieważ wysłanie SIGTERM-a do nadrzędnego skryptu perl propaguje ten sygnał do każdego z dzieci, które następnie przekazują ten sygnał do qsub, tym samym kończąc z wdzięcznością wszystkie powiązane przesłane zadania.

Dlatego bardzo ważne jest, aby móc składać oferty z tą opcją -sync y.

Niestety, wciąż otrzymuję następujący błąd:

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

zauważą niewłaściwa pisownia "containes. To jest literówka, która jest NOT. Pokazuje tylko, jak słabo zachowany jest ten obszar kodu/komunikatu błędu.

Próby, które spowodowały ten błąd, nie generują nawet plików STDOUT i STDERR *.e{JOBID} i *.o{JOBID}. Zgłoszenie całkowicie się nie udaje.

Wyszukiwanie google dla tego komunikatu o błędzie powoduje tylko nierozwiązane posty na niejasnej tablicy ogłoszeń.

Błąd ten nie występuje nawet niezawodnie. Mogę ponownie uruchomić skrypt i te same zadania niekoniecznie wygenerują błąd. Wydaje się również, że nie ma znaczenia, z którego węzła próbuję przesłać zadania.

Mam nadzieję, że ktoś tutaj może to zrozumieć.

odpowiedzi na którekolwiek z tych pytań byłoby zatem rozwiązać mój problem:

1. Czy ten błąd utrzymują się w nowszych wersjach SGE?
2. Czy mogę zmienić opcje wiersza poleceń dla qsub, aby tego uniknąć?
3. O czym do diabła mówi ten komunikat o błędzie?

Answer 1

Nasza strona trafiła w ten problem w SGE 6.2u5. Napisałem kilka pytań na liście mailingowej, ale nie było rozwiązania. Do teraz.

Okazuje się, że komunikat o błędzie jest fałszywy. Odkryłem to czytając dzienniki zmian w repozytorium open-core Univa github. Później zobaczyłem problem opisany w Informacjach o wydaniu Son Of Gridengine v8.0.0c.

Oto związanych commity w repo github:

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

Jaki komunikat o błędzie powinny powiedzieć jest to, że już z maksymalnej liczby z qsub sync -y miejsc pracy w systemie. Ten parametr jest znany jako MAX_DYN_EC. Domyślną w naszej wersji było 99, a zmiany Powyższe zwiększenie że domyślnie 1000.

Definicja MAX_DYN_EC (od (5) stronie sge_conf człowieka) jest:

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.

Można sprawdzić, ile dynamicznych klientów wydarzenie za pomocą następującego polecenia:

$ qconf -secl | grep qsub | wc -l 

dodaliśmy MAX_DYN_EC=1000 do qmaster_params poprzez qconf -mconf. Przetestowałem przesyłanie setek zadań qsub -sync y, a my już nie trafiliśmy na błąd range_list. Przed zmianą MAX_DYN_EC spowodowałoby to niezawodny błąd.

Answer 2

Znalazłem rozwiązanie tego problemu - lub przynajmniej obejście tego problemu.

Mój cel polegał na tym, aby poszczególne instancje qsub pozostały na pierwszym planie, ponieważ zadanie, które wysłano, było nadal w kolejce lub uruchomione. Zostało to osiągnięte dzięki opcji -sync, ale spowodowało strasznie nieprzewidywalny błąd, który opisałem w moim pytaniu.

Rozwiązaniem tego problemu było użycie polecenia qrsh z opcją now -n. Powoduje to, że zadanie zachowuje się podobnie do zadania qsub -sync, ponieważ mój skrypt może domyślnie monitorować, czy przesłane zadanie jest uruchomione przy użyciu waitpid w instancji qrsh.

Jedynym zastrzeżeniem tego rozwiązania jest to, że kolejka, na której pracujesz, nie może rozróżniać między węzłami interaktywnymi (oferowanymi przez qrsh) i nieinteraktywnymi węzłami (dostępnymi pod adresem qsub). Jeżeli istnieje rozróżnienie (prawdopodobnie jest mniej węzłów interaktywnych niż nieinteraktywnych), to obejście może nie pomóc.

Jednakże, ponieważ nie znalazłem nic, co byłoby nawet tak bliskie rozwiązaniu problemu qsub -sync, który jest tak funkcjonalny jak ten, niech ten wpis wychodzi poza interwale do jakiejkolwiek krnąbrnej duszy złapanej w mojej podobnej sytuacji.