Копирование одного файла на несколько удаленных хостов параллельно через SFTP

нет ничего плохого в использовании ввода-вывода.

чтобы доказать это, давайте попробуем упрощенную версию вашего скрипта-нет парамико, просто чистый Python.

import asyncio, functools, sys, time

START_TIME = time.monotonic()

def log(msg):
    print('{:>7.3f} {}'.format(time.monotonic() - START_TIME, msg))

def dummy(thread_id):
    log('Thread {} started'.format(thread_id))
    time.sleep(1)
    log('Thread {} finished'.format(thread_id))

loop = asyncio.get_event_loop()
tasks = []
for i in range(0, int(sys.argv[1])):
    task = loop.run_in_executor(None, functools.partial(dummy, thread_id=i))
    tasks.append(task)
loop.run_until_complete(asyncio.gather(*tasks))
loop.close()

С двумя потоками, это будет печать:

$ python3 async.py 2
  0.001 Thread 0 started
  0.002 Thread 1 started       <-- 2 tasks are executed concurrently
  1.003 Thread 0 finished
  1.003 Thread 1 finished      <-- Total time is 1 second

этот параллелизм масштабируется до 5 потоков:

$ python3 async.py 5
  0.001 Thread 0 started
  ...
  0.003 Thread 4 started       <-- 5 tasks are executed concurrently
  1.002 Thread 0 finished
  ...
  1.005 Thread 4 finished      <-- Total time is still 1 second

если мы добавим еще один поток, мы достигнем предела пула потоков:

$ python3 async.py 6
  0.001 Thread 0 started
  0.001 Thread 1 started
  0.002 Thread 2 started
  0.003 Thread 3 started
  0.003 Thread 4 started       <-- 5 tasks are executed concurrently
  1.002 Thread 0 finished
  1.003 Thread 5 started       <-- 6th task is executed after 1 second
  1.003 Thread 1 finished
  1.004 Thread 2 finished
  1.004 Thread 3 finished
  1.004 Thread 4 finished      <-- 5 task are completed after 1 second
  2.005 Thread 5 finished      <-- 6th task is completed after 2 seconds

все идет как ожидалось, и общее время растет по 1 секунде на каждые 5 предметов. Магическое число 5 задокументировано в ThreadPoolExecutor docs:

изменено в версии 3.5: If max_workers is None или не задано, по умолчанию будет указано количество процессоров на машине, умноженное на 5, предполагая, что ThreadPoolExecutor часто используется для перекрытия ввода-вывода вместо работы процессора, и количество работников должно быть выше, чем количество работников для ProcessPoolExecutor.

как сторонняя библиотека может заблокировать мой ThreadPoolExecutor?

• библиотека использует какой-то глобальный замок. Это означает, что библиотека не поддерживает многопоточность. Попробуйте использовать ProcessPoolExecutor, но с осторожностью: библиотека может содержать другие анти-шаблоны, такие как использование того же жесткого временного имени файла.

• функция выполняется в течение длительного времени и не освобождает GIL. Это может укажите ошибку в коде расширения C, но самой популярной причиной проведения GIL является выполнение некоторых вычислений с интенсивным процессором. Опять же, вы можете попробовать ProcessPoolExecutor, так как он не зависит от GIL.

ничего из этого не должно произойти с библиотекой, такой как paramiko.

как сторонняя библиотека может заблокировать мой ProcessPoolExecutor?

обычно не может. Ваши задачи выполняются в отдельных процессах. Если вы видите, что две задачи ProcessPoolExecutor занимает в два раза больше времени, подозревая узкое место ресурса (например, потребляя 100% пропускной способности сети).