Выполнение набора заданий GNU Parallel на нескольких узлах в кластере и наблюдение, что все потоки, по-видимому, спят на узлах (включая локальный узел, вызвавший команду).После дальнейшей проверки выяснилось, что GNU Parallel , по-видимому, удаляет некоторые аргументы, когда запускает функцию, назначенную заданию .Проверка parallel --version подтверждает, что это GNU-версия параллели (версия 20160222).
Данный код выглядит как
bcpexport() {
filename=$1
TO_SERVER_ODBCDSN=$2
DB=$3
TABLE=$4
USER=$5
PASSWORD=$6
RECOMMEDED_IMPORT_MODE=$7
DELIMITER=$8
<do some stuff to the given file arg $1 to BCP copy file contents to some MSSQL Server, function ends with...>
/opt/mssql-tools/bin/bcp "$TABLE" in "$filename" \
$TO_SERVER_ODBCDSN \
-U $USER -P $PASSWORD \
-d $DB \
$RECOMMEDED_IMPORT_MODE \
-t "\t" \
-e "$(dirname $filename)/bcperrors/$(basename $filename).bcperror.log"
}
export -f bcpexport
parallel -q -j $parallelization_pernode --sshloginfile $basedir/src/parallel-nodes.txt --env bcpexport \
bcpexport {} "$TO_SERVER_ODBCDSN" $DB $TABLE $USER $PASSWORD $RECOMMEDED_IMPORT_MODE $DELIMITER \
::: $DATAFILES/$TARGET_GLOB
, который использует Microsoft BCP (https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-migrate-bcp?view=sql-server-2017) для копирования данных TSV в БД MSSQL-сервера путем распределения заданий по набору узлов.
Спящие процессы :
При просмотре запущенных процессовчерез узлы через clustershell (https://clustershell.readthedocs.io/en/latest/tools/clush.html)
clush -b -w mapr001,mapr005,mapr006 "ps -aux | grep bcp"
, увидев несколько спящих процессов (обратите внимание на S, см. https://askubuntu.com/a/360253/760862), как показано ниже (добавлены новые строки для удобства чтения)
me 135296 14,5 0,0 77596 6940? S 00:32 0:01
/ opt / mssql-tools / bin / bcp TABLENAME в /path/to/tsv/1_16_0.tsv-D -S MyMSSQLServer -U myusername -P -d myDB -c -t \ t -e / path / to / logfile
Обратите внимание, что пароль arg -P пуст. Это не происходит при локальном запуске одной и той же функции . Эти потоки кажутся спящими вечно (я предполагаю, что MSSQL Server ожидает пароль, нотак как пусто, ни один никогда не дается и поэтому нет ответа).
Нечетные аргументы :
Я также вижу некоторые процессы вида
меня 11055 12,6 0,0 119640 1816?S 00:46 0:08
/ bin / bash -c bcpexport () {filename = $ 1;TO_SERVER_ODBCDSN = $ 2;DB = $ 3;Таблица = $ 4;USER = $ 5;ПАРОЛЬ = $ 6;RECOMMEDED_IMPORT_MODE = $ 7;DELIMITER = $ 8;некоторые вещи из функции;/ opt / mssql-tools / bin / bcp "$ TABLE" в "$ filename" $ TO_SERVER_ODBCDSN -U $ USER -P $ PASSWORD -d $ DB $ RECOMMEDED_IMPORT_MODE -t "\ t" -e "$ (dirname $ filename)/ bcperrors / $ (basename $ filename) .bcperror.log "};
export -f bcpexport> / dev / null;
bcpexport /mapr/uceramapr.cluster.local//etl/ucera_internal/internal_etl/hph_clarity/version-2/stages/storage/CLARITY_TDL/tsv/1_27_0.tsv -D \ -S \ myODBCDSN myDB TABLENAME myuser mypassword -c \ t
, который отображается для отображения(очень плохо знаком с использованием GNU Parallel) GNU Parallel берет экспортированную функцию из назначенного задания и применяет аргументы.Тем не менее, вы можете видеть, что вызов функции, которую параллельно назначает как задание, показанное в конце, имеет аргументы -D\ -S\ myODBCDSN, которые изначально были в переменной $TO_SERVER_ODBCDSN (именно поэтому он был в кавычках в parallelи почему parallel использует опцию -q).Но теперь, вместо того, чтобы передавать как одиночные кавычки, являются строкой, кажется проходящим каждый фрагмент строки, как если бы он был разделен пробелами (несмотря на параметр -q).IDK, как это способствует общей проблеме (опять же, очень плохо знакомой с Parallel), но это, конечно, не выглядит правильно.
Это все очень странно для меня, любые советы или предложения по отладке будут оценены.
ОБНОВЛЕНИЕ : Дальнейшая отладка того, почему эти потоки спят, предполагает, что они могут на самом деле выполняют свою намеченную работу (что может означать, что проблема может исходить от самого ППГ (см. https://stackoverflow.com/a/52748660/8236733)). с https://unix.stackexchange.com/a/47259/260742 и https://unix.stackexchange.com/a/36200/260742)
Процесс в состоянии S обычно находится в системе блокировкивызов, например чтение или запись в файл или сеть, или ожидание завершения другой вызываемой программы.
Ваш процесс будет в состоянии S, когда он выполняет операции чтения и, возможно, записи, которые блокируют. Может такжепроисходит во время ожидания на семафорах или других примитивах синхронизации ... Это все нормально и ожидаемо, и обычно это не проблема ... вы не хотите, чтобы он тратил ЦП, ожидая ввода пользователя.
Однако здесь строго используется слово «может», поскольку это не объясняет отсутствующий аргумент $ PASSWORD в потоках при проверке ps или почему потоки, кажется, никогда не возвращаются.В любом случае, если основная причина окажется очень отличной от моих первоначальных подозрений, обновите заголовок и вопрос, чтобы попытаться быть более полезными для тех, у кого может быть та же проблема.