☰

GNU parallel не обрабатывает все файлы

tag-icon • tag-icon linux memory java gnu-parallel
GNU parallel не обрабатывает все файлы

Я использую GNU parallel для обработки BAM-файлов для маркировки дубликатов с помощью инструмента picard на основе Java. Причина использования утилиты parallel в том, что инструмент picard не является многопоточным, а набор данных очень большой. Поэтому я использую следующую команду с GNU parallel:

ls *.bam | sed 's/.bam.*//' | parallel --eta -j 12 "java -jar picard.jar MarkDuplicates I={}.bam O=/bam1/{}.bam M=/bam1/{}_dup_matrices.txt"

Ожидание Поскольку мой сервер имеет 40 потоков и 126 ГБ оперативной памяти, я надеялся, что указанная выше команда обработает все bam-файлы, имеющиеся в текущем каталоге, обрабатывая по 12 bam-файлов за раз.

Фактический выход В итоге я получаю только 4 или 5 обработанных BAM-файлов, в то время как в текущем каталоге их около 15. Я также получаю ошибку переполнения памяти (хотя я проверил распределение памяти с помощью команды, ulimitи оно показывает неограниченное).

Можно ли использовать параллельную утилиту GNU таким образом, чтобы она автоматически обрабатывала все файлы, имеющиеся в текущем каталоге, без проблем с памятью?

EDIT-1: Я добавляю вывод ulimit -aздесь:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 514974
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 514974
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

решение1

javaчасто резервирует гораздо больше памяти, чем использует. 10x не редкость. Так что если предположить, что picardна самом деле используется 3 ГБ, но резервируется 30 ГБ, то вы сможете запустить только 4 задания параллельно, прежде чем закончится память — если только вы не добавите пространство подкачки.

То, что javaон сохраняет память, не означает, что он когда-либо к ней прикасается.

Я предлагаю вам добавить 1 ТБ пространства подкачки.

Вы также можете попросить ядро ​​Linux перераспределить память. Но у меня был плохой опыт с неожиданными сбоями сервера при этом, поэтому я бы не рекомендовал это решение.

Но тыможетиспользуйте zswap. Таким образом, если что-то будет записано в swap, ядро ​​сначала попытается сжать это и сохранить в RAM. Только если это не удастся, память будет записана на диск. В сочетании с 1 ТБ (медленным) swap-пространством на диске это работает довольно эффективно.

Связанный контент