Forza la directory sempre nella cache

Ho testato diversi metodi per migliorare il tempo necessario per compilare il mio intero progetto c ++. Attualmente ci vogliono circa 5 minuti. Ho sperimentato con distcc, ccache e altri. Di recente, ho scoperto che se copio il mio intero progetto su un'unità RAM, e poi compilo da lì, riduce il tempo di compilazione fino al 30% del suo originale - solo 1,5 minuti.

Ovviamente, lavorare dall'unità RAM non è pratico. Quindi, qualcuno conosce un modo in cui posso forzare il sistema operativo a mantenere sempre nella cache una determinata directory ? Voglio ancora che la directory venga sincronizzata su disco come al solito, ma voglio sempre anche una copia dei dati in memoria. È possibile?

EDIT: Come possibile soluzione, abbiamo appena pensato di avviare un demone che viene eseguito rsyncogni 10 secondi circa per sincronizzare l'unità disco con un'unità RAM. Quindi eseguiamo la compilation dall'unità RAM. È rsyncvelocissimo, ma funzionerebbe davvero? Sicuramente il sistema operativo potrebbe fare di meglio ....

Il modo ovvio per mantenere un mucchio di file nella cache è di accedervi spesso. Linux è abbastanza bravo nell'arbitrare tra scambio e memorizzazione nella cache, quindi sospetto che la differenza di velocità che osservi non sia in realtà dovuta al fatto che il sistema operativo non tiene le cose nella cache, ma a qualche altra differenza tra l'uso di tmpfs e altri tuoi tentativi.

Prova ad osservare cosa sta facendo IO in ogni caso. Lo strumento di base è quello iotop. Altri strumenti possono essere utili; vedi la ripartizione del carico IO del disco Linux, per percorso del file system e / o processo? , Quale programma in Linux può misurare l'I / O nel tempo? e altri thread in Server Fault.

Ecco alcune ipotesi su cosa potrebbe accadere. Se prendi le misure, mostrale in modo che possiamo confermare o confutare queste ipotesi.

• Se i tempi di accesso ai file sono attivati, il sistema operativo potrebbe perdere parecchio tempo a scrivere questi tempi di accesso. I tempi di accesso sono inutili per un albero della compilation, quindi assicurati che siano disattivati ​​con l' noatimeopzione mount. La tua soluzione tmpfs + rsync non legge mai dal disco rigido, quindi non deve mai perdere altro tempo a scrivere atimes.
• Se le scritture si stanno sincronizzando , sia perché il compilatore chiama sync()o perché il kernel scarica frequentemente i suoi buffer di output, le scritture impiegheranno più tempo su un disco rigido che su tmpfs.

Linux per impostazione predefinita usa la RAM come cache del disco. Come dimostrazione, prova a eseguire time find /some/dir/containing/a/lot/of/files > /dev/nulldue volte, la seconda volta è molto più veloce in quanto tutti gli inode del disco vengono memorizzati nella cache. Il punto qui è come utilizzare questa funzionalità del kernel e fermare il tentativo di sostituirla.

Il punto è cambiare il swappiness. Consideriamo tre tipi principali di utilizzo della memoria: programmi attivi, programmi inattivi e cache del disco. Ovviamente la memoria utilizzata dai programmi attivi non dovrebbe essere scambiata e la scelta tra due altri è abbastanza arbitraria. Desideri passare rapidamente da un programma all'altro o accedere rapidamente ai file? Una bassa swapiness preferisce mantenere i programmi in memoria (anche se non utilizzati per lungo tempo) e una elevata swapiness preferisce mantenere più cache del disco (scambiando programmi inutilizzati). (la scala di scambio va da 0 a 100 e il valore predefinito è 60)

La mia soluzione al tuo problema è di cambiare lo swappiness su molto alto (90-95 per non dire 100) e caricare la cache:

echo 95 | sudo tee /proc/sys/vm/swappiness > /dev/null # once after reboot
find /your/source/directory -type f -exec cat {} \; > /dev/null

Come indovinate, è necessario disporre di memoria sufficiente per contenere nella cache tutti i file di origine e file oggetto, nonché il compilatore, i file di intestazioni inclusi, le librerie collegate, l'IDE e altri programmi utilizzati.

Forzare la cache non è il modo giusto per farlo. Meglio mantenere le fonti sul disco rigido e compilarle su tmpfs. Molti sistemi di build, come qmake e CMake, supportano build out-of-source.

Il inosyncdemone sembra fare esattamente quello che vuoi se hai intenzione di risincronizzare su un ramdisk. Invece di risincronizzare ogni 10 secondi circa, usa la funzione di inotify di Linux per risincronizzare quando un file cambia. L'ho trovato nel repository Debian come inosyncpacchetto, oppure la sua fonte è disponibile su http://bb.xnull.de/projects/inosync/ .

Questa cosa sembra funzionare per me se voglio mantenere determinati file o tutti i file in una determinata directory nella cache.

vmtouch sembra fare la cosa giusta. Esempio 5 potrebbe esserci quello che ti serve.

vmtouch -dl /whatever/directory/

Avevo bisogno di eseguirlo come root con sudo

Data la memoria sufficiente, il tuo build fuori dal ramdisk non ha I / O. Questo può accelerare tutto ciò che legge o scrive file. L'I / O è una delle operazioni più lente. Anche se tutto viene memorizzato nella cache prima della compilazione, si hanno ancora gli I / O per la scrittura, anche se dovrebbero avere un impatto minimo.

È possibile ottenere un po 'di velocità pre-caricando tutti i file nella cache, ma il tempo impiegato dovrebbe essere incluso nei tempi di compilazione totali. Questo potrebbe non darti molto vantaggio.

Creazione dell'oggetto e file intermedi nella RAM anziché nel disco. Fare build incrementali può farti ottenere guadagni significativi su build frequenti. Sulla maggior parte dei progetti faccio una build pulita giornaliera e build incrementali in mezzo. Le build di integrazione sono sempre build pulite, ma provo a limitarle a meno di una al giorno.

È possibile ottenere alcune prestazioni utilizzando una partizione ext2 con atime disattivato. Il tuo sorgente dovrebbe essere nel controllo di versione su un file system journaled come ext3 / 4.

Come affermato in precedenza, il modo più ovvio è leggere tutta la struttura delle directory e i contenuti dei file di ciò che si desidera memorizzare nella cache.

Puoi automatizzarlo scrivendo uno script per monitorare l'output di vmstat 1(usa qualsiasi strumento equivalente per il tuo sistema operativo) e mantenere una somma del numero di blocchi scritti e letti. Una volta che la somma supera una soglia di tua scelta, leggi tutti i file che intendi memorizzare nella cache, reimposta la somma, quindi continua a monitorare l'output di vmstat. Per leggere rapidamente i file: se il tuo albero contiene molti file, evita find ... -exec catinvece di provare find ... -print0 | xargs -0 cato un programma personalizzato che non eseguirà cat per ogni file.

Il monitoraggio dell'IO del disco è preferibile all'uso di un intervallo fisso perché segnala di rileggere i dati più o meno frequentemente a seconda del carico dell'IO del disco.

Ho usato questo metodo automatizzato con successo su sistemi in cui avevo bisogno che alcune letture dei file di indice fossero sempre veloci, evitando l'I / O del disco rigido. Ho anche usato strace per creare un elenco di tutti i file a cui accedo quando eseguo l'accesso in modo da poter tenere tutto caldo nella cache per accessi veloci.

Questa potrebbe non essere la migliore soluzione possibile, ma mi andava bene.