2011-12-09 10 views
7

Ho un'app C (VStudio 2010, win7 64bit) in esecuzione su una macchina con due chip xeon, ovvero 12 core fisici e 24 logici e 192 gig di ram. MODIFICA: il SO è win7 (cioè Windows 7, 64 bit).Ottimizzazione di enormi scritture su disco

L'app dispone di 24 thread (ogni thread ha il proprio nucleo logico) che esegue calcoli e riempie una parte diversa di una massiccia struttura a C. La struttura, quando tutti i fili sono finiti (e i fili sono tutti perfettamente bilanciati e quindi completi allo stesso tempo), è di circa 60 gigabyte.

(Ho il controllo sulla configurazione hardware, quindi sto per utilizzare 6 unità 2tb con RAID 0, il che significa che i limiti fisici di scrittura saranno approssimativamente 6 volte la velocità di scrittura sequenziale media, o circa 2 gig/secondo .)

Qual è il modo più efficiente per ottenere questo su disco? Ovviamente, il tempo di I/o sminuisce il tempo di elaborazione. Dalla mia ricerca su questo argomento, sembra come scrivere() (al contrario di fwrite()) è la strada da percorrere. Ma quali altre ottimizzazioni posso fare sul lato software, in termini di impostazione delle dimensioni del buffer, ecc. Sarebbe più efficiente?

+0

Si prega di aggiungere un tag su quale lingua si desidera scrivere in. Che aiuta gli altri a trovare facilmente questa domanda. – Buddha

+0

Quanto dura il calcolo? –

+0

Vedo un tag 'mmap'. È disponibile per il tuo sistema? –

risposta

6

È difficile giudicare la cosa migliore per la vostra situazione.

La prima ottimizzazione da effettuare è preallocare il file. In questo modo il tuo file system non ha bisogno di continuare ad estendere le sue dimensioni. Questo dovrebbe ottimizzare alcune operazioni del disco. Tuttavia, evitare di scrivere zeri reali sul disco. Basta impostare la lunghezza.

Quindi è possibile scegliere tra mmap e write. Questo dipende anche dal sistema operativo che usi. Su un Unix proverei sia mmap che pwrite. pwrite è utile perché ognuno dei tuoi thread può scrivere nel file nella posizione del file desiderata senza combattere gli offset di file.

mmap potrebbe essere buono perché invece di effettuare copie nella cache di file, i thread dovrebbero scrivere direttamente nella cache di file. 60 GB è probabilmente troppo grande per mmap l'intero file, quindi ogni thread avrà probabilmente bisogno della propria finestra mmap sul file che può muoversi.

In Windows, probabilmente, si vorrebbe provare a utilizzare un IO asincrono sovrapposto. Ciò può essere fatto solo con le chiamate API Win32.

+1

Windows ha l'equivalente di mmap (CreateFileMapping, MapViewOfFile) ed è probabile che sia valido per gli stessi motivi elencati da Zan. –

+1

E per gli stessi motivi (è quello che il sistema operativo utilizza) i file mappati offrono buone prestazioni anche su Windows. Inoltre Windows può mappare un file su un'unità di rete. Unix non era abituato a fare mmap su nfs - è cambiato? –

8

mmap() o boost mmap è quasi sempre l'approccio migliore. Il sistema operativo è più intelligente di te, lascia che si preoccupi di cosa memorizzare nella cache!

Non hai detto quale sistema operativo, ma su Linux lo madvise o suggerimenti di boost equivalenti possono davvero migliorare le prestazioni.

+1

+1, sempre, lascia che qualcun altro abbia il maggior numero di dettagli possibile! –