corretto uso parallelo di xargs

Sto usando xargsper chiamare uno script Python per elaborare circa 30 milioni di piccoli file. Spero di usare xargsper parallelizzare il processo. Il comando che sto usando è:

find ./data -name "*.json" -print0 |
  xargs -0 -I{} -P 40 python Convert.py {} > log.txt

Fondamentalmente, Convert.pyleggerà in un piccolo file json (4kb) , eseguirà alcune elaborazioni e scriverà in un altro file da 4kb. Sono in esecuzione su un server con 40 core della CPU. E nessun altro processo ad alta intensità di CPU è in esecuzione su questo server.

Monitorando htop (a proposito, c'è qualche altro buon modo per monitorare le prestazioni della CPU?), Trovo che -P 40non sia veloce come previsto. A volte tutti i core si congelano e diminuiscono quasi a zero per 3-4 secondi, quindi si ripristinano al 60-70%. Quindi provo a ridurre il numero di processi paralleli a -P 20-30, ma non è ancora molto veloce. Il comportamento ideale dovrebbe essere l'accelerazione lineare. Qualche suggerimento per l'uso parallelo di xargs?

xargs parallelism

— Yan Zhu
fonte

Molto probabilmente sei colpito dall'I / O: il sistema non è in grado di leggere i file abbastanza velocemente. Prova a iniziare più di 40: In questo modo andrà bene se alcuni dei processi devono attendere l'I / O.

— Ole Tange,

Che tipo di elaborazione fa lo script? Qualche database / rete / io coinvolto? Quanto dura?

— Fox,

Io secondo @OleTange. Questo è il comportamento previsto se si eseguono tutti i processi quanti sono i core e le attività sono legate all'IO. Prima i core attenderanno su IO il loro compito (sleep), quindi elaboreranno e quindi ripeteranno. Se si aggiungono più processi, i processi aggiuntivi che attualmente non sono in esecuzione su un core fisico avranno dato il via a operazioni parallele di IO, che al termine elimineranno o almeno ridurranno i periodi di sospensione sui core.

— PSkocik,

1- Hai l'hyperthreading abilitato? 2- in quello che hai lassù, log.txt viene effettivamente sovrascritto con ogni chiamata a convert.py ... non sono sicuro se questo è il comportamento previsto o meno.

— Bichoy,

xargs -Pe si >sta aprendo per le condizioni di gara a causa del problema della mezza linea gnu.org/software/parallel/… L' uso di GNU Parallel invece non avrà questo problema.

— Ole Tange,

Risposte:

Sarei disposto a scommettere che il tuo problema è Python . Non hai detto che tipo di elaborazione viene eseguita su ciascun file, ma supponendo che tu stia semplicemente eseguendo l'elaborazione in memoria dei dati, il tempo di esecuzione sarà dominato avviando 30 milioni di macchine virtuali Python (interpreti).

Se riesci a ristrutturare il tuo programma Python per prendere un elenco di file, anziché solo uno, otterrai un enorme miglioramento delle prestazioni. È quindi possibile utilizzare ancora xargs per migliorare ulteriormente le prestazioni. Ad esempio, 40 processi, ognuno dei quali elabora 1000 file:

find ./data -name "*.json" -print0 |
  xargs -0 -L1000 -P 40 python Convert.py

Questo non vuol dire che python sia un linguaggio cattivo / lento; non è ottimizzato per i tempi di avvio. Lo vedrai con qualsiasi linguaggio basato su macchina virtuale o interpretato. Java, per esempio, sarebbe anche peggio. Se il tuo programma fosse scritto in C, ci sarebbe comunque un costo per l'avvio di un processo di sistema operativo separato per gestire ogni file, ma sarebbe molto meno.

Da lì puoi armeggiare -Pper vedere se riesci a spremere un po 'più di velocità, forse aumentando il numero di processi per sfruttare i processori inattivi mentre i dati vengono letti / scritti.

— James Scriven
fonte

Quindi, in primo luogo, considerare i vincoli:

Qual è il vincolo per ogni lavoro? Se si tratta di I / O, probabilmente è possibile cavarsela con più lavori per core della CPU fino a raggiungere il limite di I / O, ma se è intensivo per la CPU, sarà peggio che inutile eseguire più lavori contemporaneamente rispetto ai core della CPU.

La mia comprensione di queste cose è che GNU Parallel ti darebbe un migliore controllo sulla coda di lavori ecc.

Vedi GNU parallel vs & (intendo lo sfondo) vs xargs -P per una spiegazione più dettagliata di come i due differiscono.

— Stefano
fonte

Come altri hanno già detto, controlla se sei associato a I / O. Inoltre, la pagina man di xargs suggerisce di usare -ncon -P, non menzionate il numero di Convert.pyprocessi che vedete in esecuzione in parallelo.

Come suggerimento, se sei associato a I / O, potresti provare a utilizzare un dispositivo a blocchi SSD o provare a eseguire l'elaborazione in un tmpfs (ovviamente, in questo caso dovresti controllare la memoria sufficiente, evitando lo scambio a causa di tmpfs pressione (penso), e il sovraccarico di copiarvi i dati in primo luogo).

— Spuk
fonte