]> Sergey Matveev's repositories - stargrave-blog.git/commit
Распределённые задачи по NFS
authorSergey Matveev <stargrave@stargrave.org>
Fri, 2 Sep 2022 13:10:04 +0000 (16:10 +0300)
committerSergey Matveev <stargrave@stargrave.org>
Fri, 2 Sep 2022 15:41:45 +0000 (18:41 +0300)
commit9c18bbe6efb16197cd494b7a4583e09328560165
tree4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent31cb6e3aff58cfbc0f8e55af8c076797a22e191f
Распределённые задачи по NFS

Есть тут множество файлов, которые надо сжать. И есть три компьютера
мощных дома и поэтому хотелось бы как-то распараллелить этот процесс.
Все они лежат в shared NFS директории, поэтому можно работать по сети.
Думал что в GNU parallel есть из коробки что-то для этого, но нет.

Помню про lockf утилиту, которая могла бы идеально подойти для этой
задачи: взяли lock -- продолжаем работать, иначе выполняем следующую
задачу. Делает lock она путём открытия файла с O_EXLOCK. Но по NFS это
не работает. Не падает, но lock не отрабатывает.

Поэтому решил применить mkdir для этой задачи. Вроде бы, говорят, что он
атомарен на NFS. Хотя даже имитация атомарности мне бы подошла. На
каждой машине делаю:

    nice parallel 'mkdir {}.lock && cpuset -l $(( {%} - 1 ))
                   zstd -v --ultra -22 --rm {}' ::: *.tar

Делать несколько zstd вместо одного zstdmt эффективнее, так как
распараллеливает работу он по достаточно большим кускам и под конец
сжатия несколько минут может оставаться работать меньшее количество
нитей, не полностью утилизируя все ядра. cpuset уже и прежде использовал
для того, чтобы процесс был прибит к конкретному ядру
(30e51579624d482c2fd13324f0e1d6a5c4db40b6). И с parallel очень приятно
завершать задачи плавно, дожидаясь окончания уже запущенных процессов:
kill -HUP `pgrep -f parallel` (f5ea219cd5f1f8361e48a31d7fc29ee5b2b0fe14).