2010-08-09 11 views
14

Nella mia azienda stiamo attualmente ricercando varie strategie per accelerare le nostre build CI. Abbiamo profilato le nostre build e determinato che siamo vincolati da un collo di bottiglia di I/O. Abbiamo parecchie opzioni per affrontarlo nel prossimo futuro (~ 1-2 mesi), ma mi piacerebbe vedere un miglioramento ora.È ragionevole usare un ramdisk su un server di build?

Ho proposto di utilizzare un ramdisk come posizione di checkout e buildfile. Gli output ed i log di build verrebbero ovviamente memorizzati sul disco fisico.

È una cosa sensata da fare o ci sono degli svantaggi significativi in ​​questo approccio? Non sto cercando risposte che riguardino il lato hardware delle cose, ma piuttosto che l'interazione tra sistemi di compilazione comuni (ad es. MSBuild) e un ramdisk causeranno problemi e se ci sono altri rischi di cui devo essere a conoscenza.

+0

Una semplice nota: presumo che stiate parlando di build notturne qui? nel qual caso, ovviamente, è necessario spremere il massimo di build da zero e test. Se fossero build giornalieri, suggerisco di mantenere il tempo di costruzione intorno a un massimo di 5 Mn in modo che gli sviluppatori possano ottenere un rapido feedback su potenziali problemi a ogni commit: in questo caso, è la maggior parte del tempo utile per fare la compilazione * incremental *, cioè, basta fare un aggiornamento svn (hg/git/etc.), e usare Make (o Ant, Nant, ecc.) per ri -compila cosa è cambiato. Con un buon Makefile scritto, potrebbe anche velocizzare le cose in modo drammatico. Solo il mio 0,02 € :-) –

+0

Sto parlando di CI qui (costruire dopo ogni commit). Approfittiamo già di build incrementali per questo, ma grazie. –

+1

@Christophe Muller, facendo una dichiarazione generale che una build dovrebbe essere "massimo di 5 Mn" è davvero ridicola senza conoscere l'ambiente, le dimensioni e i requisiti della build. Abbiamo un prodotto che gira su un server CI e costruisce in meno di due minuti, compresi compilazione e packaging. Abbiamo un altro prodotto che include diverse soluzioni .NET, diversi servizi Windows nativi, più progetti Adobe Flex, test unitari, copertura del codice, packaging e distribuzione automatizzata su un rack di test. L'intero processo (non tutto viene eseguito ad ogni check-in) è di oltre due ore e mezzo * ore *. –

risposta

8

Fintanto che si dispone di memoria sufficiente, è una cosa molto sensata da fare.

L'unico vero inconveniente è, naturalmente, la tua build viene persa in caso di spegnimento/interruzione di corrente che di solito non è una grande preoccupazione per le build CI.

2

Ho appena eseguito alcuni test sul mio "build server" (in realtà uno script PowerShell) che controlla 3600 file da Subversion, li compila (DOT.NET) ed esegue alcuni Test unità.

Sul mio disco rigido normale (non super veloce) il processo dura 35 secondi.

L'utilizzo dello strumento Dataram RamDisk con l'impostazione FAT32 predefinita su Windows 7 richiede 45 sec.

La riformattazione con NTFS porta a 30 secondi.

Ma l'utilizzo di un SSD (nel mio caso un OCZ Vertex 2) richiede solo 27 secondi.

Ho eseguito diversi test ma i tempi sono sempre gli stessi.

Cosa possiamo imparare da questo?

Un disco Ram non è sempre più veloce, assicurarsi di testare prodotti diversi con diverse impostazioni .

Un disco a stato solido può persino essere più veloce di un disco RAM, il che mi ha sorpreso.

+0

Ho un disco ram DataRam e un SSD e il disco eseguito è molto più veloce. Qualcosa sembra strano se vedi che il ramdisk impiega più tempo del ssd. Oltre a ciò, questa build è già piuttosto veloce e la maggior parte delle volte non è probabilmente vincolata all'I/O. 35 secondi è veramente veloce per un checkout/build. La nostra build è molto più grande: abbiamo superato il limite di un'ora con i test unitari prima di ottimizzarlo e portarlo a dieci minuti. –

+0

Interessante, mi aspettavo che RamDisk fosse molto più veloce di un HD o SSD, quindi sono rimasto deluso dai miei risultati. Sto ancora aggiungendo altri progetti e test al mio processo di compilazione e riprenderò i miei test più tardi. Se hai già abbastanza RAM, un disco RAM è anche più economico e non consuma l'SSD. Grazie per il tuo contributo Samuel. –

+5

Non sembra giusto. A corto di cache niente è più veloce della RAM; nemmeno un SSD. Hai per caso fatto in modo che il tuo disco RAM fosse così grande da non lasciare memoria sufficiente per il processo di compilazione per fare effettivamente il suo lavoro? Questo potrebbe aver portato a scambiare la memoria con il filesystem che ovviamente avrebbe avuto un effetto inverso. – McKrassy

Problemi correlati