Leggendo file enormi (fino a 32 GB) in multithreading env?

2

Obiettivo: 1) enorme file letto in blocchi ogni 1 MB di lunghezza, 2) ognuno viene compresso e scritto in un altro file di output.

Nota: sono limitato a% solo in% co_de.

Esiste uno schema noto su come parallelizzare il processo di lettura dei file? Anche se dovrei usare .Net 3.5 manualmente.

P.S. Non sto chiedendo il codice, sto cercando un bel concetto.

UPD :

Ciò di cui non mi rendo conto in modo particolare è che il modo corretto per garantire che la coda con dati grezzi non possa crescere senza limiti? Quando cerco di immaginare una soluzione futura, non vedo il posto adatto per controllare una tale condizione e non realizzo del tutto supsend / resume dell'operazione di lettura dei file. Sarebbe bello avere qualche suggerimento.

    
posta Sereja Bogolubov 10.05.2018 - 17:50
fonte

2 risposte

3

L'accesso a un file da più thread per la lettura di blocchi da 1 MB è banale, basta determinare la lunghezza del file e il numero di blocchi in anticipo. Accodare i blocchi e lasciarli elaborare in parallelo da un dato numero massimo di thread. Ogni thread quindi apre il file in modo non bloccante, fa cercare un file nella posizione di inizio del blocco desiderato e legge il blocco. Lo stesso thread quindi può anche eseguire l'elaborazione.

Solo la scrittura risultato dovrà avvenire in sequenza (presumo non si può determinare facilmente la posizione file di output per un pezzo compresso prima dell'elaborazione precedente del blocco precedente non è stata completata): ogni volta che un filo è pronto con il suo pezzo, esso aspetta che il chunk precedente sia completato e scritto su disco, quindi il thread corrente può scrivere anche il chunk compresso (e rilasciare il mem usato).

Tuttavia, dovrai verificare quanti thread paralleli raggiungerai le massime prestazioni, questo dipende totalmente dal tuo sistema, dal tipo di dispositivo di archiviazione, dalla velocità del canale I / O, dalle CPU e dal numero di core, file system della velocità di memoria coinvolti e alcuni altri fattori.

Se sei sfortunato, potrebbe risultare che il numero ottimale di thread è solo uno , e altri possono rallentare il processo. Potrebbe essere più alto, o corso (guardare in questo vecchio Dr. Dobbs articolo , dove filettatura a più la lettura su un singolo file era ottimale per 2-4 thread, a seconda dell'hardware utilizzato). Ma l'unico modo affidabile per scoprirlo è fare alcuni test e misurarli da soli.

    
risposta data 10.05.2018 - 19:05
fonte
2

Non vorrei concentrarmi su schemi generici, ma piuttosto chiediti cosa stai facendo qui e dove puoi aspettarti il "dolore". Non mi aspetto alcun guadagno dall'usare più thread per leggere il file (al contrario, mi aspetto che le prestazioni ne risentano se si dovesse seguire quella strada). Tuttavia, più thread potrebbero farti ottenere qualcosa con la parte zippata.

Considerando che potresti avere a che fare con un disco rigido, non vuoi che più thread competano per le teste di lettura di quel dispositivo. Quindi, per prima cosa, proverei ad avere un thread in grado di leggere blocchi di 1 MB in sequenza e passare ogni blocco a una nuova attività zip. Le attività zip devono comprimere un oggetto di memoria e memorizzarlo in una coda da cui il thread di scrittura legge. Dovrai limitare la dimensione della coda in base alla memoria disponibile. Il thread di scrittura deve comunicare con il thread di lettura, se entrambi utilizzano lo stesso dispositivo non devono competere ma si concedono reciprocamente un tempo esclusivo con il dispositivo in modo alternato.

Il numero di thread per lo zipping dovrebbe essere limitato, ci sarà un ottimo che puoi trovare provando diversi numeri (e sarà correlato al numero di core della tua macchina). I thread di lettura e scrittura dovrebbero dormire per un paio di ms quando sono inattivi e vedere se c'è qualcosa da fare di nuovo o, se si vuole essere veramente fantasiosi, essere segnalati dai provider / consumatori di lavoro.

    
risposta data 10.05.2018 - 19:09
fonte

Leggi altre domande sui tag