вывод perl-скрипта, который вызывает «sudo lsof | grep username | wc -l», отличается в cron и вручную

Производительность обычно ограничивается одним из этих:

1. Пропускная способность сети. Вы можете использовать sudo iftop, чтобы увидеть, используется ли ваше сетевое соединение на 100%.
2. Задержка сети. Если серверу на другом конце требуется много времени для ответа, вы не увидите 100% использования пропускной способности.
3. Дисковый ввод-вывод. Вы можете использовать iostat -dkx 1, чтобы увидеть, используется ли ввод-вывод любого из ваших дисков на 100%.
4. ЦП. Вы можете использовать top, если ваши процессоры загружены на 100%. Нажмите 1, чтобы просмотреть отдельные потоки ЦП. Если один из них равен 100%, то у вас есть однопоточная программа, которая ограничена этим.

GNU Parallel хорошо справляется с параллельным выполнением заданий, чтобы использовать больше пропускной способности, дискового ввода-вывода и ЦП.

Но и у него есть свои ограничения.

GNU Parallel обычно кэширует вывод в /tmp. Это означает, что ваш дисковый ввод-вывод на /tmpможет быть узким местом.

К счастью, имея дело с CSV, вы редко заботитесь о порядке строк. :Это нормально, если строки смешиваются, если это полные строки.

Если вы используете --line-bufferиз версии >20170822, тогда GNU Parallel не буферизует вывод на диск -, а только одну полную строку в памяти. Для этого требуется немного больше ресурсов ЦП, поэтому проверьте, использует ли parallel100% ЦП. Если он использует меньше, значит, вы не попали в это узкое место.

$ cat vins.csv | parallel --line-buffer curl -s --data "format=csv" \
 --data "data={1}" https://vpic.nhtsa.dot.gov/api/vehicles/DecodeVINValuesBatch/ \
  >> /nas/BIGDATA/kemri/nhtsa_vin_data.csv

Вы можете увидеть, есть ли локальное узкое место,:

$ seq 1000 | parallel --line-buffer 'yes {} | head -c 1G' | pv >> /nas/BIGDATA/test

На моем паршивом ноутбуке скорость составляет около 100 Мбайт/с. Так что мой паршивый ноутбук сможет работать с 1 Гбит/с от dot.gov.